I cannot submit front-end form which is embedded within an iframe.
(I have a central website storing form submissions and an iframe with the form on multiple dependent sites. I use almost empty template doing the shortcode inside)
It concerns both normal and Ajax forms. I'm pretty sure it worked some time in the past.
First I suspected that the issue may be connected with cross-site security policy applied this year in browsers but I couldn't confirm it.
Idea: what about setting session cookie in MBFS with secure param when https?
session_set_cookie_params('3600', 'mydomain.com', (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off')? true : false, true);
Well it overcame some console warnings about cookie security, but did not fix submission.
Also, when the form is set to Ajax and I look at the Chrome console it shows an error:
frontend-submission.js?ver=3.0.0:1 Uncaught TypeError: Cannot read property 'message' of undefined
at Object.<anonymous> (frontend-submission.js?ver=3.0.0:1)
at i (jquery.js?ver=1.12.4-wp:2)
at Object.fireWith [as resolveWith] (jquery.js?ver=1.12.4-wp:2)
at x (jquery.js?ver=1.12.4-wp:4)
at XMLHttpRequest.c (jquery.js?ver=1.12.4-wp:4)
marking the part
m(a.data.message as the point where bug occurs.
The same form accessed directly (not within an iframe) works perfectly.
Could you test your plugin in such use case?
By the way, I'm using Metabox All in One and it claims about the missing CSS file:
I'm using WordPress 5.5, Meta Box 5.3.3, Meta Box AIO 1.11.18 and theme Twenty Twenty. Just submit a post via a frontend submission form embedded in the
<iframe> tag but not see any issue https://www.loom.com/share/2092f9d1e9494b6c8553e42b0e1901bf.
Could you please deactivate all plugins except Meta Box, Meta Box AIO and switch to the default theme of WordPress (Twenty Twenty) then check the issue again?
Thank you for your testing.
Actually, I should have check it and mention that the iframe embedded on the host site works for me as well.
However, the story is about the iframes embedded under different domains than that where MB is installed. (Perhaps it should be something different than "localhost" to reproduce the case; I use 2 domains in Local by Flywheel app like primary-site.local and secondary-site.local.
The “Same Origin” (same site) policy of the Chrome browser limits access of windows and frames to each other.
I've tried to submit via Firefox and see it works. Could you please confirm this?
Also, it's not the Meta Box's issue itself so I mark this topic as resolved.
Did you test with a non-Ajax form as well?
I can for example add comment to the host site but I cannot submit MBFS form. It just reloads.
After investigation I found that the issue is caused by the fact that MBFS form page loading in iframe tries to set up PHP session cookie. It could be secure cookie under https - then it would be solvable in Chrome - but Safari blocks all 3-party cookies by default anyway.
I don't know if MBFS really, really needs this session cookie, however, this makes my setup impossible to implement with MB causing me to be very sad...
MBFS doesn't use cookie. It uses only PHP session (which stays in the server). So, I think it's not a problem with cookie or browser restriction.
If submitting via Ajax, there might be issue with CORS which doesn't allow to send Ajax request from a domain to another. It's a security feature for the web (you can read more about it here). If this is the case, you can set headers on the origin website to accept Ajax request from other domains.
I'll check more with that. Probably browsers have their restriction that we need to investigate.
Thank you for looking at this.
The page (being within an iframe; let's call it "primary" page) with form tries to create PHPSESSID cookie when opened on "secondary" page. As for now it works in Firefox, doesn't work in Chrome (session, when https, should be started with params: 'Secure' => 1 'SameSite' => 'None') and doesn't work in Safari (is blocking third party cookies like this one PHPSESSID by default).
As the form submission relies on this session cookie, I think nothing can be done to override Safari policy here.