wp_kc

Thanks.

Some additional details…

Server setup:

• Debian 9
• WordPress – Version 4.9.8
• PHP 7.0 FPM
• Advanced Custom Fields – Version 4.4.12
• Advanced Custom Fields: Flexible Content Field – Version 2.1.0 (w/valid license)
• Advanced Custom Fields: Repeater Field – Version 2.1.0 (w/valid license)

Conditions causing the bug:

• The problem occurs when trying to add a new location rule to a field group using a single flexible content field.
• The flexible content field had 12 layouts, with a total of 37 sub-fields among them.
• The field group had 6 Location rules.
• 8 ‘Hide on Screen’ items were checkmarked
• This setup had been working in the past on the same server, with the same configurations files.
• Trying to add a new location rule resulted in the last 3 layouts (along with their 7 sub-fields) being deleted. The new rule also was not saved. And the last field of the last surviving layout was deleted, as well as some settings of the second to last sub-field.

Temporary work-around:
I bumped the php.ini variable ‘max_input_vars’ up to 2000, restarted apache, reconstructed the field group and was able to save it. So too many form variables being submitted at once is definitely causing the problem. Luckily, everything that used that field group was restored to normal operation after reconstructing the field group. Then I returned ‘max_input_vars’ to its default value of 1000 and restarted apache again to prevent attackers from trying to abuse GET and POST requests.

Suggested solution:
It is my understanding that WordPress is moving toward using its REST-API for all screens in the admin area. Maybe now is a good time to start converting ACF to submit all data from the field group editor as a single JSON data string. This would avoid triggering the default 1000 input variable setting on apache.

Thanks for your response. It sounds like I need to upgrade!

• This reply was modified 7 years, 11 months ago by wp_kc.

I don’t know why it is not working then. When I do everything you recommended, the image urls show up as “http://234” or similar, like it is receiving an ID. However, if I change your code to…

$acf_exists = function_exists( 'acf_shortcode' );

        foreach ( $posts as $post ) {
            $image = '';
            $url   = '';
            $alt   = '';
            if ( $thsource == 'custom-field' ) {
                $debug .= 'Using custom field;';
                //$url = $basic_url = get_post_meta( $post->ID, get_option( 'relpoststh_customfield', $this->custom_field ), true );

if ( $acf_exists ) {
   $url = $basic_url = get_field( get_option( 'relpoststh_customfield', $this->custom_field ), $post->ID );
} else {
   $url = $basic_url = get_post_meta( $post->ID, get_option( 'relpoststh_customfield', $this->custom_field ), true );

…then everything works perfectly. I’m guessing that ACF does not store custom field data in the postmeta table using the specified ACF field name, but instead does some sort of name mangling that get_field() undoes.

Wow! Fast service! You are awesome.

Thanks!