Cole Geissinger

@achanne this is the file that is breaking in the Yoast plugin. I can’t speak to Sitelock specifically, but we have direct access to Imperva so we were able to disallow them from caching the post-edit-17400.js file where the error is occurring.

You may be able to request Sitelock look at doing the same. The path to this file would be /wp-content/plugins/wordpress-seo/js/dist/post-edit-1740.js.
NOTE: The last numbers in the file name are specific to the version of Yoast you are running on the site so if you update to the latest version, 17.5, the file name changes to post-edit-1750.js. So Sitelock may need to ensure any future versions are disallowed from caching.

We found clearing the cache only worked temporarily as the problem would come back within ~20 minutes roughly. Our systems team added this file to no longer be cached by Imperva and so far we have been able to prevent this issue from recurring so far for our client.

We are also running on Imperva and a few days ago we cleared the cache with them to mostly success but some editors at our client’s team are still facing the same issue. We will be working closely with our systems team and Imperva to try and resolve this.

I am also having this same issue, and is actually very similar to another I experienced before with a file getting cached wrong from my client’s CDN, Imperva. However, this doesn’t appear to be the same root cause.

We have found this to be consistently broken in Chromium while on Linux and Mac but it works on Chrome and Firefox. My client is using Windows with Edge and is seeing this across the board.

Obviously, something is off so I did a comparison of the post-edit-1700.js file from Yoast directly and what is served on production (we are running v17 and I see this issue also exists in 17.4 which is -1740.js) and I found that the regex is being malformed so it no longer has white space after the astrisk. Here’s an online diff https://www.diffchecker.com/5wodZFV8, scroll down until you see highlight lines of code.

E.g. /^*-+:*$/ when it should be /^ *-+: *$/

At this time this doesn’t appear to be an issue with Yoast but something down the line causing the file to be reformatted?

Also verifying that our client’s CDN Imperva had a bad cache of the file which is why we couldn’t replicate the issue.

Clearing CDN cache then busting browser cache did the trick for us.

E.g. after clearing your CDN cache (or any cache if you are using it), then navigate to the file with a query param https://YOURSITE.com/wp-content/plugins/wordpress-seo/js/dist/yoast/search-metadata-previews-1611.js?test

Also reporting that I have this error but only on our client’s production environment. Can’t replicate locally or in dev and staging environments. Just to be sure this wasn’t a configuration error, I pulled a copy of the production database and updated URLs to test locally. Still can’t replicate outside of the production environment.

I updated Chrome (on Mac 10.15.7) to latest version, cleared cache and cookies, tried firefox, the issue still remains. The strange part was the client reported this, I couldn’t replicate at first and then it showed up for me. Some of my co-workers can’t replicate it.

This appears to be around the Snippet Preview and the meta description? This is a bit of a puzzling one..

ok, I found where the issue is within ACF Pro at least. This theme I inherited decided to load the plugin in a very strange way making upgrading difficult so the code might be a version or two behind…

Anyways, in acfpro/js/input.js:5144 within the validation_complete we have $.each( json.errors, function( k, item ){ ... }

The json.errors returns 0 causing the isArrayLike() function to result in the error. I added an if statement above that code to return the json object early if json.errors equaled 0, that fixed the problem for me. Don’t forget to minify your code or else ACF won’t load it without further customizations!

Here’s a snippet of that code – https://gist.github.com/colegeissinger/701df3e5be49fc7e5be2

Actually quick update. Doing the above will break Akismet… Having a hard time getting around that at the moment. So the work around above isn’t fool proof. Here’s some details that hopefully will lead to a fix.

https://github.com/jquery/jquery/issues/2242

Validated that changing back to jQuery 1.11.2 worked. But yes the code above will not work.

The issue is within the admin area. Add this code anywhere in your functions.php for now until ACF can get the culprit corrected.

function cg_revert_jquery_version_admin() {
	wp_deregister_script( 'jquery' );
	wp_register_script( 'jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.11.2/jquery.min.js');
	wp_enqueue_script( 'jquery' );
}
add_action( 'admin_enqueue_scripts', 'cg_revert_jquery_version_admin' );

Sorted this out. I was able to achieve this with the user role plugin and by applying the account type to that user in their profile. Example – https://cloudup.com/c7lcE3z2yta

Not fully positive if that plugin provided that area but just incase figured I’d mention it ??

You have a few things incorrectly setup for using WP_Query(), even then, pagination doesn’t work as you are calling to an undefined variable called $paged. While this is what the main query uses, your query needs to define it when passed to WP_Query().

Try out the code I have here and see if that helps. I also readjusted some things that will help solidify and secure your code you listed. Check out the second link for a diff of what I changed.
https://gist.github.com/colegeissinger/8628947
https://gist.github.com/colegeissinger/8628947/revisions

This issue is not related to this plugin, also this is a WordPress.com website which this plugin is not supported for.

Please make sure to take your issue to WordPress.com where your website is hosted as this is not the appropriate support thread. If you have access to the email for your user account setup under, I would recommend clicking the Forgot Password link on the login screen https://styledwheels.WordPress.com/wp-admin

Ok figured out this is working. Just seems to be an intense cache? Checking the database everything is setup right, but display improperly in the admin area. Adding a new term into the taxonomy I moved the term into the cache refreshes and I see it displayed now. Not sure if this is the same thing Thingkit is having… but it seems to be a server caching thing not the plugin ??

I have the same issue although I’m running 3.9-alpha. Just included this into my site through the VIP Shared Plugins repo and everything looks good, I’ll select the terms to change to a new custom taxonomy, “Terms updated” notification but the term is still in the old and nothing in the new ??

Running on VIP Quickstart on the latest version of trunk.

If the form fields are empty it returns empty as there is no text to display. Make sure you add in at least the login and logout text.

If it still doesn’t display, then this might be an issue with your theme and displaying the widgetized area. You can double check this by viewing the page source code and checking if there’s any instance of the widget in there. (Try searching for the world wpml. There should be a class called that)