Dmitriy

@d0153 The latest update seems to have done the trick. Thank you.

I found this thread, with a better solution than mine, which worked for me. Basically open phpmyadmin and delete a row with option name ‘_elementor_pro_api_requests_lock’ from the _options table.

• This reply was modified 1 year, 3 months ago by Dmitriy.

There are many ways, sftp etc, depending on your hosting. But the easiest probably to first lower your PHP version to 7.4 so you can access the CMS. Once back in CMS, go to Plugins-> Plugin File Editor. Make the update then change the PHP version back to 8.0.

@salesscottbevis I added the following “if” statement around line 174 and 175 of the file /wp-content/plugins/elementor-pro/license/api.php and it seems to have solved the issue in PHP 8.0. I was having the same exact problem as you after upgrading. I realize it’s not ideal to edit plugin files, but when the vendor response is lagging, bandaids like that can help get the site up, at least.

if (is_array($requests_lock)):
    $requests_lock[ $name ] = time();
    update_option( self::REQUEST_LOCK_OPTION_NAME, $requests_lock );
endif;

No, turning off object cache did not work, unfortunately.

This might work, strictly as a bandaid of course: add flush_rewrite_rules(); at the end of functions.php

That’s good news, thank you!

• This reply was modified 1 year, 5 months ago by Dmitriy.

@joshpaynedesigns negative. Was told to provide DB dump during next occurrence along with some 404 URLs. They suspected YOAST SEO plugin interference but not 100% on that yet. I’ll post here if we get a resolution.

Since this is on multiple sites, I’ll comment on 2 sites that experienced it today:

PHP 7.4 and 8.0 both affected
WP 6.2.2
TEC 6.0.13.1 (previous few versions also affected)
2 different custom themes from 2 different agencies
No additional caching installed in either case
With and without Object Cache turned on
omitting listing URLs here due to client privacy

Note that I also opened a ticket via Events Pro support and working with someone there.

So far I’ve seen this issue on WP Engine on 3 unrelated sites, but of course it is too small of a sample size to to be certain that it is a hosting conflict. Restoration usually involves anything that triggers permalink flush, easiest being pressing “Save Changes” on the Permalink Settings page. Disabling/enabling Events plugin also works, as does temporarily switching a theme. I’ve also noticed that it happens when someone is editing a new or existing event item, but I could not consistently recreate it as of yet. Each site with this problem had a custom permalink structure, though that in itself should not be a crime. What’s weird is that it breaks any permalinks that are not pages along with it, like other CPTs, native categories and other taxonomies.

@chikaibeneme, I appreciate the suggestion, but excluding .js and .css files from cache won’t do much in this case because these are front-end files and the page never gets to load them due to 404. It happened again today and the client now requested that I remove the plugin.

@jcallanan, thank you for chiming in here! I am curious if you are having this issue on WP Engine or some other host.

FYI, still an issue in 6.0.13.1

Thanks so much for the update and prompt support.

@d0153, I am running 6.2.2 with a custom theme. I found a solution (below), but it would probably be best to test the variable before passing the value to the array_search() function in the code src/Tribe/Main.php line 3535.

In case anyone runs into this, the solution is to delete “metaboxhidden_nav-menus” keys from the _usermeta table where meta_value appears empty:

SELECT?*?FROM?XXX_usermeta?where?meta_key=”metaboxhidden_nav-menus”;

Look for rows in the results where meta_value is empty and delete them.

That’s great news, thank you @tdgu!