2 months, 1 week ago goldenticketParticipant
I brought this issue up to Arindo a few weeks ago via email. Apparently it’s some webhosts, RunCloud in my case, and WP Ultimo.
The stock Nginx conf files for RunCloud are all SAMEORIGIN. I had to modify WP-Ultimo’s class-wu-site-hooks.php file to ALLOWALL to prevent the warning.
I hope this helps.
Sorry, I meant changing ALLOWALL to SAMEORIGIN fixed it for me.
FWIW, most hosting control panels have settings to change it for you. I don’t know if SiteGround offers this. In my somewhat unique case, I had to modify the code.
Seems like you might be able to modify your .htaccess file to fix it, like when you first installed WordPress: https://www.siteground.com/kb/cross-origin-resource-sharing-cors/
WordPress itself cannot modify .htaccess files as far as I know, thus you must do it yourself.
Feature suggestion: Have a drop down list in the settings of WP-Ultimo with SAMEORIGIN and ALLOWALL options that just changes the code accordingly.
Yes, I could go in and set the server settings.
However, as this is a feature it should work out of the box (unless it’s disclosed as experimental). Whether that is like you say an option, or a method in which Ultimo auto detects what the server is configured to, and sets the proper configuration…
“However, as this is a feature it should work out of the box (unless it’s disclosed as experimental). Whether that is like you say an option, or a method in which Ultimo auto detects what the server is configured to, and sets the proper configuration…”
As far as I know, and also with my conversations via chat with the team, the X-FRAME options cannot be auto-detected by WP-Ultimo. From what I see in the changelog, this has been implemented since 25/11/2018 with Version 1.9.1, “Some hosting providers add the SAMEORIGIN restriction to the template previewer, now we force the ALLOWALL header for template previews;” If this became a more recent issue, then I have no clue what’s causing it. Could be a server environment change, browser update changes, etc.
Also from my chat, they stated they were going to update the documentation explaining the aforementioned.
Since I’m not too familiar with all server environments and all hosting providers, it may be possible that there could be edge cases where such an option may not work, but it still may be useful to have the suggested feature. So, it may not work out of the box, but I guess that’s why there’s support.2 months ago Arindo DuqueKeymaster
Hey guys, sorry for the delayed response.
This is a regression issue: basically a bug we reintroduced in 1.9.12. Totally our fault. We’ll be releasing version 1.9.13 to fix that early in the morning tomorrow.
That being said, as pointed out by @goldenticket, some hosting providers are setting this header to some value before PHP starts executing (set on a server level). This is not the case for the majority of service providers, but If that value is different from the ALLOWALL we set, browsers don’t know what to do and revert back to the SAMEORIGIN default, which might cause issues.
In those cases, unless there is a setting to change the header on a server level, there isn’t much we can do on our side, so the best option is to disable the top-bar/iframe combo on template preview and revert back to going straight to the site template URL.
Since it used to work on your install before, @williambay, it is likely that you are just a victim of our regression bug.
Thanks. Updated the other day, and can confirm it fixed the problem.
You must be logged in to reply to this topic.