Support

Account

Register Login

Forum Replies Created

  • Hello ralphioooo and John,

    I have encountered the same problem on one of my websites where I updated the plugin to version 5.5.0. It is indeed a (severe) bug since saving a field set where a textarea is used resets to the “Automatically add paragraphs” option and it can completely mess up the frontend display or worst when used for e.g. adding JavaScript or CSS to the head of a website which I do on some occasions. Furthermore it may also affect other select type choices in other fields.

    Since with the database upgrade rolling back was not an option for me I dived into the code to put in a quick fix myself. I tracked the problem down to the following file after comparing the code to a previous version that did not have this problem:

    /advanced-custom-fields-pro/fields/select.php

    Around line 269 there used to be an additional couple of lines of code which, when adding them again to the file, solved the problem and the select now has the proper choice active in the WP admin edit screen:

    // add empty value (allows ” to be selected)
    if( !count($field[‘value’]) ) {
    $field[‘value’][”] = ”;
    }

    I’m not sure if the above piece of code was moved to a different location or rewritten/ replaced by a different piece of code that is apparently currently not working. It makes sense that it should be present because with the code missing it is no longer allowed to have an empty value a valid option.

    I hope that a fix will be released soon by you guys so the problem is resolved.

    Kind regards,
    Ernst Jansen
    ByteMotion

  • I can confirm that I ran into the same problem just now working on a frontend form for a client. After I updated to Advanced Custom Fields PRO Version: 5.4.0 I got the same error when submitting the form:

    Backend fatal error: PHP Fatal error: Call to undefined function get_current_screen() in /advanced-custom-fields-pro/api/api-helpers.php on line 3313

    So I think the problem has nothing to do with your specific setup but is a generic problem that was introduced with the latest release of ACF. When I rolled the version back to Version: 5.3.8.1 everything was working fine as before. I will update my version to 5.3.10 since you indicate the problem is not present there.

    I hope a fix will be available soon since we don’t want to miss out on all the great new features that are included in 5.4.0 😉 Thanks in advance for solving this!

  • Hi James,

    I was hoping this was the case and in this particular setup I already increased the amount of memory available to WordPress, increased the max number of input vars to 4000 and the post max size to 8 MB.

    We have been running multiple high traffic websites now over the past 9 months without any problems so it all works out.

    I’m just amazed that it took you 1 year and 7 days to respond to my question…

    Best regards,
    Ernst

  • Hi wleefro & Elliot,

    I stumbled upon this problem myself today whilst preparing a website for delivery to a client.

    The thing that appears to have changed in WP is the order in which the “add_action” for triggering the function with the “remove_menu_page” to remove the ACF menu item is executed.

    This used to be after the “add_menu_page” that is used within the ACF plugin, but now it runs before the menu item is added so it is not removed in the end.

    So what I’ve simply done to make it work is change the order (priority) for my removal function to ‘999’ so it is executed after ACF adds the item to the menu:

    	function remove_acf_menu() {
		remove_menu_page('edit.php?post_type=acf');
	}
	add_action( 'admin_menu', 'remove_acf_menu', 999);

    It might be a good idea to update the following “How to” page with this information since I also ended up on that page whilst searching:

    http://www.advancedcustomfields.com/resources/how-to/how-to-hide-acf-menu-from-clients/

Viewing 4 posts - 1 through 4 (of 4 total)