ionainteractive

I can confirm what @saintefamille64 said. We have the same problem. After upgrading to 1.15.6 a JS error prevents showing the PDF in admin side or on the public site. The console error is:

Promise.withResolvers is not a function
at pdf.worker.js?ver=4.3.136:23:1431038
at pdf.worker.js?ver=4.3.136:23:1432101
at pdf.worker.js?ver=4.3.136:23:1432328
at b._onComObjOnMessage (pdf.worker.js?ver=4.3.136:23:1411925)

We have tried emptying browser cache and disabling the Autoptimize plugin (which would not affect admin side anyway), but the error persists and PDF will never display.

To continue this dialog, as this is a problem for us as well (on several AWS self-hosted production sites), I suggest you review @afragen’s comment from last month, which is right on point. (You may have already incorporated a fix.) But to reiterate, what you’re doing here is not a proper use of a transient, per the WP codex. The transient framework is not meant t reliably store data for any length of time. You should probably move your storage of the preference to a blog-level option.

Same problem as OP. Check your file /assets/integrations/shortcake/shortcake.php. That is where your plugin is injecting the deleted font-awesome.min.css into the visual editor styles.

Hear, hear! All of the “error” messages I am showing on a large network site are false positives. (Such as the email address is a different domain from the site when it isn’t.) Please provide the ability to ignore all errors or at least dismiss specific errors when we know they are incorrect or otherwise not a problem.

Following up on this original error reported by vicocotea, I believe I’m in the same use case as the OP, and the problem is likely with the way your plugin tries to detect whether Woocommerce is installed in a multi-site environment. If Woocommerce is network activated, then it will not be returned in the get_option( 'active_plugins' ) result which you depend upon in line 36 of the main plugin file. What worked for me is to change it to the following, which checks whether Woocommerce is network activated:

if ( in_array( 'woocommerce/woocommerce.php', apply_filters( 'active_plugins', get_option( 'active_plugins' ) ) )
	|| array_key_exists( 'woocommerce/woocommerce.php', maybe_unserialize( get_site_option( 'active_sitewide_plugins' ) ) ) ) {

We are having the same issue described on all our CentOS self-hosted sites. Enabling WP_DEBUG does not shed any light; apparently PHP is not throwing any errors. The action=do-core-upgrade page after entering FTP details is just blank (apart from all the admin wrappers, like top/side menu, and the static footer with the “Get Version 4.1.1” link). Do the WP devs have any suggestions?

I can confirm that for our WP installation the latest update corrects the inability to save clicks on the “Allow this sidebar to be replaced” checkboxes in theme sidebars.

Not good enough. Why isn’t this fixed yet? You’ve had at least 6 days according to this topic. AFAIK your plugin is no longer operational, not even to “pro” version subscribers. PLEASE supply a target fix date immediately!

WPEC dev team, I understand everything you have posted in this thread about the new Customer API, and I thank you for trying to come up with a workable solution to what is a mess of a technical problem. Please add high up on your to-do list thinking through exactly what happens to a customer when their anonymous user record is pruned by the cron task but they still have the cookie referencing a deleted user ID. I’m finding a mixed bag of unexpected results for our non-logged-in users who haven’t interacted with the cart in days but have remained constantly active on the site. One outcome is that while the cart gets emptied as I would expect due to inactivity, items can still be added to it under the same deleted user ID, and orphan records are created in wp_usermeta referencing the deleted user ID. Correct me if I’m wrong, but shouldn’t it do a sanity check of user ID presented in the customer cookie (e.g. does the user exist?) and recycle to a fresh customer cookie if the user ID was pruned? If you agree, this should occur on every request which involves WPEC, including AJAX calls to add an item to the cart. (I’m thinking in particular of the case of a visitor who has had a product page window open for days with items in the cart, and who eventually comes back to it after ages of inactivity expecting to maybe add another item and checkout but is surprised to find the cart emptied during the item add.)

Yep, installing this plugin update hosed my site. I had to rename the plugin folder to even get back into WP-admin. I’m on PHP 5.3.26 and nginx. Can’t determine what the root cause is, but this plugin update should be rescinded until further testing is done.

roadlittledawn (and others), take note that the plugin author has to the best of my knowledge corrected the IE JS issues. If you install the latest version of the plugin from GitHub (as of 1 Jul 2013) the plugin should work properly. In the alternative, install release version 4.1.6 and overwrite the js/input/ajax.js file with the latest version at GitHub (https://github.com/elliotcondon/acf/blob/master/js/input/ajax.js). All of these fixes should be inherited by the next release.

Okay, sorry but I’ve uncovered another JS problem. In js/input/ajax.js, on line 24 in the object definition for acf.screen you try to create a key called “return”, but that is a JS reserved word so the script doesn’t validate in IE. I suggest you strike that line and add “return” as a property using the array syntax after the object definition (being sure to remove the comma from line 23). So the block from line 13 should look like this:

acf.screen = {
		action 			:	'acf/location/match_field_groups_ajax',
		post_id			:	0,
		page_template	:	0,
		page_parent		:	0,
		page_type		:	0,
		post_category	:	0,
		post_format		:	0,
		taxonomy		:	0,
		lang			:	0,
		nonce			:	0
	};
	acf.screen['return'] = 'json';

Fried_eggz’ comment led me to look deeper, and I found there is a similar syntax error in js/input/file.js. The comma needs to be removed from the end of line 140 (“filterable: ‘all’). A trailing comma on the last item of an object definition will not validate. (It’s not like a PHP array.) If you leave the comma, some browsers may not complain, but IE will fail to show all metaboxes and throw an exception.

Hi there. Looks like this problem is back again. Your latest update (4.1.5) has an invalid syntax for the the JS object defined in line 129 of js/input/image.js. You need to remove the comma at the end of line 136. The plugin will be broken in most versions of IE until this is resolved. Thanks!

I am having the same problem as yoramzara. After recently upgrading the plugin, it seems like all of our non-Administrator users (e.g. Authors and Editors) cannot access WP-admin. After login, they are shown the “You do not have sufficient permissions to export the content of this site” warning due to the wp_die() call that you have in sre2t_admin_page(). I have disabled the plugin until the above is remedied which then allows our editors to access WP-admin.