-
Posts
-
Dear Support,
I’d like to re-post something I originally posted back in August of 2019; it was posted at the tail-end of someone else’s thread and I was advised to start a new thread, which I forgot to do.
It looks like the iFrames still aren’t loading… and the problem is exactly as it was five months ago. Please find below my original message. When you get the chance, please advise.
Important note: contrary to the original message, the versions of WordPress and Enfold are both presently up to date––Wordpress 5.3.2 and Enfold 4.7.2.
Many thanks!
Cheers,
Tim
Hi Rikard and Company:
I am running WordPress 5.2.2 and Enfold 4.5.7 and I can confirm the bug that phylicia refers to in the above post dated June 12th: I had two embedded iFrames (not YouTube videos) and I had to use the debug mode in order to remove the iFrames code and get the Avia Advanced Layout Builder to load again.
Is this an issue that you are working on at your end?
Cheers,
TimPS The problem does not occur when building the page, meaning, if I start fresh and add the iFrames to the page, I can see the embedded code appear in the Avia Advanced Layout Builder as I save each element. The error occurs when I ‘update’ the page and then either refresh it or return to edit the page that the spinning wheel appears. I hope that helps.
Hey Timothy,
Can you give us temporary admin access to your website in the private content box below, so that we can have a closer look? Do you have a test page? Is it a particular iframe?
Best regards,
VictoriaVictoria,
Many thanks for the reply… I completely dropped the ball on this.
Admin access below.
There are only two pages in the whole site… if you edit the home page, you’ll see immediately what I describe in the original message.
Thank you!
Cheers,
TimHi Tim,
You’re getting a 403 on the /wp-admin/admin-ajax.php request. Please disable Jetpack and see if the issue persists. Then check the ModSecurity settings on the server.
If you need further assistance please let us know.
Best regards,
VictoriaDear Victoria,
Thank you very much for taking the time to look at this. I’ll follow your leads and report back.
Cheers,
TimHi Tim,
Thanks for the update. Please let us know if you should need any further help on the topic.
Best regards,
RikardHello Support Team:
I just wanted to report back with the solution. It was an issue with WordFence code. The following is from my server support.
Note: I have deleted the personal directories indicated, but you get the idea.Hello,
The issue was caused by the following setting in the file .user.ini in /www/www:
; Wordfence WAF
auto_prepend_file = ‘/www/www/wordfence-waf.php’
; END Wordfence WAF
Settings in .user.ini files are applied recursively to all subdirectories. This setting prepends code to all PHP files from the WordFence plugin installed on the WordPress website in /www/www. As the website in the subdirectory /www/www/ is a different WordPress installation, it causes the WordFence code to block some requests.
To resolve the issue, we renamed .user.ini to php.ini. Settings in php.ini files are applied only to PHP scripts that are located in the same directory as the php.ini file. We also copied to /www/www/php.ini the settings you have in the global php.ini file.
- You must be logged in to reply to this topic.