WP 5.8.3 and Pods 2.8.8.1 Memory Timeout

What other changes have you made on this specific site other than updating WP? Are you 100% sure that only WP was updated here and not some of the other plugins?

I ask because this sort of issue is not a common issue when updating WP itself. Nothing in 5.8.3 should be interfering with Pods here so I’m eager to help you figure this out.

Do you have any other details you can share such as your Site Health info? You can get that by going to Tools > Site Health > Info tab > Click the copy button and then paste it as a reply here.

Thanks Scott,
I think I found the conflict: SEOPress Pro 5.3.1.

This host doesn’t have a commit list, but I think 2 or 3 plugins may have had updates: Elementor Pro, SEOPress Pro and WP Rocket. When I disable those three I am able to activate Pods. I can enable WP Rocket and Elementor Pro fine, but SEO Press causes the site to throw a fatal memory error.

Disabling Pods fixes it. I may try to rollback SEOPress temporarily. As an FYI, the error looks like:

`Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in site/public_html/wp-includes/class-wp-query.php on line 1073

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 1052672 bytes) in site/public_html/wp-includes/class-wp-hook.php on line 109′

Is this helpful? Thanks!
Brian

We’re seeing other people report a conflict with that version too. Their team is also familiar with this and is looking into it. When I have a moment this weekend I will also check because there hasn’t been a solution/determination made yet on the reported issue from their plugin’s side yet.

Excellent, thank you and good luck!

Hi there,

we may have found the conflict.

?Can you edit this file:
?
?wp-seopress-pro/inc/admin/redirections.php
?
And comment this line like this (line 837):
?
?//update_user_meta(get_current_user_id(), 'edit_seopress_404_per_page', '100');

?Save changes.
?
?Refresh the PODS admin page, it should work.
?
?Can you confirm please?

Thank you!
?

• This reply was modified 3 years, 2 months ago by Benjamin Denis.

We have had similar problems

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 81920 bytes) in site/public_html/wp-content/plugins/pods/classes/fields/pick.php on line 1480

@rainbowgeek I can confirm commenting out line 837 in SEO Press Pro inc/redirections.php does seem to fix the problem:

//Force WP to display 100 redirects per page
//update_user_meta(get_current_user_id(), ‘edit_seopress_404_per_page’, ‘100’);

Thank you!
Brian

• This reply was modified 3 years, 2 months ago by kinggrizzly.

Thanks for finding this, I will take a look and see why it’s appearing to do an infinite loop from this call.

Sure thing, thanks for the great tool and support!

It’s definitely in that function, that area of the code is not optimal in general but that line is definitely triggering an infinite loop because Pods has to look up Pods configurations using WP_Query and SEOPress Pro is hooking in every time to update the user meta over and over.

Pods checks to see if the user pod exists and then checks to see if the meta key being updated is a Field on that Pod. If it is, it checks to see if it needs to update the table-based storage or not.

I’m adding a tweak to totally ignore that meta key in Pods 2.8.9 but their team will definitely need to approach how they are hooking in and especially the forcing of the user meta in that hook (wrong place to do that, or wrong way to approach it).

Anyone can disable the problem by adding this snippet:

remove_filter('pre_get_posts', 'seopress_404_sort_columns_by');

You can also go to: /wp-admin/admin.php?page=seopress-pro-page

SEO > PRO > Click the Redirections / 404 tab > Disable the “404 monitoring / Redirections” at the top.

That will disable the feature that is conflicting here without changing any code.

Our next update will fix this (ETA: this month).

The code will only be loaded on our redirections post type to avoid these kind of conflict.

Great solution @rainbowgeek! Thanks for taking steps on your side too. Both of us found areas to improve from this so I’m sure it will be easier to avoid this kind of conflict on either side with other plugins doing similar things.

Absolutely!

Thank you @sc0ttkclark and @rainbowgeek!