Error 500 in wp-admin with the last update

Hello,

Thanks for the feedback and the error log!

I see where this error come from. I’ll add a control in the next patch in order to avoid this to happen.

However, it is not normal that you get a boolean instead of an array at this specific part of code. May I ask on which admin page this error occur? In one of the following ACF Extended module? Post Type UI, Taxonomy UI, Block Type UI, Options Page UI?

While waiting for the next patch, you can apply this hotfix:

In the file /acf-extended/includes/module-acf.php line:182, add the following code:

if(empty($item)){
    return $null;
}

So the final code should look like this:

// item
$item = $module->get_item($post_id);

if(empty($item)){
    return $null;
}

// remove unused keys
acf_extract_vars($item, array('ID', '_valid'));

I’m still curious to know why the item isn’t correctly retrieved at this point of the code tho.

Thanks and sorry for the inconvenience.

Regards.

Re,
Thank you for your response !
It occur in a classic page, construct only with acfpro blocks.
Strangely, it occur in only one page. But I can’t retrieve in the stack error log the source in my files.
Regards.

Hello,

Thanks for the details!

Did the hotfix fixed the issue? I’m kind of curious at what trigger this error. It’s probably a specific Block Type which has a specific behavior.

If you don’t mind, can you please help me to understand where it comes from? As I cannot reproduce the issue.

Can you please edit the hotfix code I shared line:182 with this one:

if(empty($item)){

    acf_log('ACFE post_id:', $post_id);
    acf_log('ACFE module:', $module->get_label());
    acf_log('ACFE item:', $item);

    return $null;

}

Then enable the WP Debug Log by adding these lines in your wp-config.php file:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This will log errors and data in your /wp-content/debug.log file when you visit your Page Admin Screen which was displaying the error before.

Can you please paste the 3 ending lines from the debug.log file here?

They should start with “ACFE post_id” “ACFE module” “ACFE item”.

Thanks in advance!

Regards.

Hello Konrad,
Thank you for your feedback, I did not have time to set up your tests, having many projects in progress.
I’ll do it as soon as I have some time, I’m as curious as you to see where it could come from.

Meanwhile, another problem has occurred with the latest update of the free version of ACF extended. I was only able to get out of it by reverting to version 0.8.8.9.

1 – the bug is only on the wp-admin side, there is a fatal error triggered when I want to see the detail of a group of ACF fields. No other impact, neither front side nor Gutenberg side for example
2 – this only does it on a dedicated server running on php 8.2, no worries on my shared 8.1
3 – the error concerned the memory allocation when launching the core wp-query class. The increase in server memory, already substantial, had not solved the problem.
The logged error :
Allowed memory size of 1073741824 bytes exhausted (tried to allocate 262144 bytes) in /home/####/wp-includes/class-wp-query.php on line 3749

4 – The error occurs with large sites as well as very small sites under construction (this morning, error with a site with 6 articles and 3 pages)
5 – My groups of fields are “clean” and assigned mainly to types of blocks, or to categories of articles. The error occurs even when keeping only groups associated with blocks.

FYI, I mainly use ACFpro (up to date), ACF extended free and ACF component fields (https://acf-component-field.gummi.io/) to build my blocks. The system had been very stable for years.

In advance, thank you.

Hello,

Thanks for the feedback!

Unfortunately the “Allowed memory size of xxxx bytes exhausted” error is kinda hard to debug. The first reason behind is, like you said, the PHP memory limit which is too low to run all the plugins and custom code at once.

Woocommerce recommends to go as high as 256MB. Going past this limit means you either have a pretty complex setup, or a lot of heavy PHP scripts.

Note that depending on your server specifications, changing the limit to 256MB doesn’t necessarly means you have so much available memory (which can be the case in some cheap managed hosting).

The second possible reason behind it is that you have PHP scripts that eat up your RAM memory, in a possible infinite loop.

In order to isolate the issue, I would recommend set the memory limit to 256MB. If the problem is still here, clone your website on staging/development environment with similar specs (you can use Duplicator for that), then disable all your plugins one-by-one (at the exception of ACF Pro & ACF Extended) until you find which one cause the issue.

If the problem persists, I would suggest switch to the native WP Twenty Twenty Two theme, to make sure you don’t have any custom code in your theme that would eat your memory.

Let me know if you found something.

Regards.

Hello Konrad,

Thank you for your response, I haven’t been notified.

The problem is persistent, and I will soon follow the method you have mentioned to me.

The thing I do not understand is that I have no problem with sites in hosted on shared servers. This bug occurs only on a dedicated server.

And once again :

• No impact on the front
• No impact on the use of my ACF blocks in Gutenberg, nor my fields in the Options pages
• It’s just the detailed view of the groups of fields that does not work and generates this error (for example: WP -Admin/Post.php?post=158984&action=edit – Post 158984 being a ACF group of fields). The page returns all the information to the ACF group, but not the ACF fields themselves, and the mentioned error is lifted. How could the themes and my blocks impact this “admin” view ACF only on this server?
• This bug appeared after version 0.8.8.9 of ACF Extended. I am solving for the moment by staying on this version, but my site devus source turning with the latest version of ACF Extended (without problems), when I export the blocks in JSON, I have a 500 error at the time of ‘Import and this operation is not quite properly done.

The PHP version does not seem to come into play. And the system has been stable for more than two years, I have built around twenty sites with it. And the problem occurs including with almost empty sites, just one or two pages.

For info, the spect of the server

WP version: 6.1.1 – Supported
WP Multisite Activated: No
Web server info: Apache
PHP version: 8.1.14
MySQL version: 10.10.2
SQL version variable: 10.10.2-Mariadb-1: 10.10.2+Maria ~ Deb11
Local php: negative_sign:
WP memory limit: 1g
WP debugging mode: no
WP language: default
MAX MAX MAX TOWN: 50 MB
Maximum PHP sending: 100m
Maximum number of nested entries: 64
PHP execution limit: 30
PHP Max Input Vars: 1000
SUHOSIN installed: no

I would come back to you later when I would have had time to duplicate the system on this same server following your instructions. But if in the meantime you had another track …

Many thanks in advance, have a nice day

Solved !

I follow your method and I found a custom function launch by the pre_get_posts filter who launch the bug.

The function “search_posts_per_page” set a configurable number of posts per pages in search result pages.

I correct this by insert this line at the top of my function :

if ( is_admin() || ! $query->is_main_query() ) return;

And that’s all ok ! I don’t understand all the reason why, but it work !

Thank you for your responses and time passed to help !

Hello,

I’m glad to hear that you managed to tackle down this issue!

In fact, pre_get_posts is a very powerful hook but also a sensitive one. This hook is executed everytime a new WP_Query or get_posts() is called, which basically means everywhere in the admin and the front-end, as those calls are part of the WordPress core.

When tweaking settings in this hook it is very important to correctly define conditions to avoid changing settings for other calls.

In the case of ACF, it does some WP_Query in the ACF UI in order to retrieve Field Groups (which is a post type) and Fields (which is an another post type). A wrongly configured pre_get_posts will affect the ACF query calls, but also other plugins/core queries, which added on top of each other were probably eating up your memory.

The conditions you added to make sure your tweaks are only applied on front-end and on the main query are indeed required. If you want to specifically target your WP search result page, you should also probably add this condition (see documentation):

if($query->is_search){
    // ...
}

In fact, right now with the conditions you added, your tweaks might be also applied to other front-end core queries such as post type archive, categories etc…

I would recommend to take a look at the pre_get_posts documentation for further details.

Hope it helps!

Have a nice day!

Regards.