mikehues

Hi Bernhard,

WPEngine finally confirmed that they have security measures in place that filter out <script>. It is a system wide rule that they are unable to remove. Fortunately, the plugin is working perfectly on the front end. It is only a small inconvenience to work around the error in the editor.

I appreciate all your help with this issue.

thanks,

Mike

Thanks Bernhard. I’ll pass this information along to my hosting company and see what they find.

Mike

Hi Bernhard,

In an attempt to narrow down the cause of my issue, I’ve set up a new test site. It’s a fresh install of WordPress with only JCI installed. Here are some more stats:

• WordPress 6.2
• Twenty Twenty Three 1.1
• JSON Content Importer 1.3.17
• PHP 8.0.28
• There are 2 Drop-ins and 5 Must Use Plugins listed in Site Health > Info

I created a test page that contains only a single JCI block -https://muirwooddev.wpengine.com/?page_id=5

I left the default settings of the block and enabled debug mode. I also added the word “script” to the end of the Template To Use For JSON field. The page currently works as expected. To reproduce the error, type a “>” after the word script. When the block tries to autoupdate it’s contents, the 403 error is thrown.

I will share access with you in the freshdesk-ticketsystem.

I will also notify my hosting company of the new simpler test so their support team can have another shot at debugging the issue on their end.

Thanks again for your help.

Mike

Hi Bernhard,

I shared the api url through the link you provided. The api does not require authentication.

The plugin works perfectly on my local development site. But, when I try it on the stage and production sites (which are hosted on WPEngine) I get errors when I edit the page in the block editor. However, the content is successfully pulled from the api and displayed on the front end when viewing the page.

Regarding the words “description” and “script” – as long as the template field does not contain these words, the plugin works as expected. I can pull the job titles, location info, requirements, etc from the api and everything works fine. It’s only when I add the job description to the template that I see the error in the block editor.

With further testing, I noticed that it is actually the word “script” appearing between “<” and “>” that seems to cause the error. If the template field contains “<script>” or “<br>script<br>” or “<h3>Description</h3>”, the 403 error occurs.

I hope this makes the issue more clear. Thanks for your help.

Mike

I did a few more tests with some simpler template strings.

This works:

script<br>

This throws the error:

<br>script<br>

and so does this:

<script>

So, it appears there is an issue with the template string including something that looks like a potential script tag. I hope this information is helpful.

Mike

I reached out to Imagely support through a client’s NGG Pro account. They were able to reproduce the issue and a support ticket has been opened. No ETA on fix, but hopefully it will make it into an upcoming release.

This issues persists in NextGEN Gallery 3.9.0 and beta 3.9.1

I was having the same problem. Disabling NGG’s resource manager, as suggested above, fixed the issue with the lastest versions of NGG(3.7.0) & NGG Pro(3.1.11)

great news! thanks for the heads up @madjax

I’m having the same issue using Autoptimize, Cache Enabler and The Events Calendar. Just notice the homepage being replaced by an events list a couple days ago. It was happening multiple times a day. Clearing the page or site cache only fixes the problem temporarily.

I opted to switch to another caching plugin on the production site until I can resolve this issue. But, I still have a development site where I can consistently reproduce the behavior with the following steps:

1. clear the homepage Page Cache or Site Cache
– the cache file is deleted (/wp-content/cache/cache-enabler/[site-domain]/https-index.html)
2. visit the homepage
– a new cache file is created
3. visit the default calendar list page: /events/
– no change to homepage
4. click previous arrow
– brings you to: /events/list/?eventDisplay=past
– no change to homepage
5. reload page
– homepage cache file is replaced
– visiting the homepage reveals the content is now replaced with an events list

I’ve tried playing around with cache/aggregation/optimization settings with no luck. Any additional help would be appreciated.

thanks,

Mike

perfect. thanks Ryan!

Hi Ryan,

I appreciate the quick response! This update fixed the issue in all 3 test cases. Please let me know if I can help with further testing.

thanks!

Mike

I did a little more testing.

I have another site that uses this plugin along with the underscores starter theme. I could have sworn that site was working fine in the past, but I’m now seeing the same behavior. That theme’s header.php uses the_custom_header_markup() to output the header image.

I also spun up a completely fresh site – WP 5.0.3. I installed and activated unique_headers 1.7.12. I activated the Twenty Seventeen theme which implements custom headers. I see the same behavior there.