Support

Account

Register Login

Home › Forums › ACF PRO › ACF Pro 5.6 Update: "Restructured plugin files"

Solved

ACF Pro 5.6 Update: "Restructured plugin files"

  • Just put it here for anyone who might be looking for information. Acf 5.6 changes how the field class are structured.

    Before 5.6, field are setup with __construct() method. After 5.6, it’s done by initialize() method.

    Example Before, 5.6:

    
class my_custom_field extends acf_field
{
    public function __construct()
    {
        $this->name = 'my_custom_field';
        // ... hter stuff

        parent::__construct();
    }
}

    Example After 5.6:

    
class my_custom_field extends acf_field
{
    public function initialize()
    {
        $this->name = 'my_custom_field';
        // ... hter stuff

        // don't need to call parent
    }
}

    To have you field compatable, this is what I did (not fully tested, but works for me).

    
class my_custom_field extends acf_field
{
    public function __construct()
    {
        $acf_version = acf()->version;

        if (version_compare($acf_version, '5.6.0') >= 0) {
            parent::__construct();
        } else {
            $this->initialize();
            acf_field::__construct();
        }
    }

    public function initialize()
    {
        $this->name = 'my_custom_field';
        // ... hter stuff

        // don't need to call parent
    }
}

    Hope it helps 🙂

  • What happens if you leave it the way it is? I find it hard to believe that Elliot would make such a drastic change and not have it backward compatible with the number of ACF add ons that exist. I’ve tested several add ons with the new version and I’m not seeing any problems so far. Am I missing something?

  • Yep, it doesn’t happen on all the addon, but i saw a couple ppl asking on github so i thought I’d post it here. The new constructor will only affect addon that extends on the existing core field.

    2 of my addon are extending repeater field. and couple other ones i use that extends image and gallery field all run into the same issue.

    Basically, what happen is, say, you have a addon that extends repeater field, the class look something like this:

    
class my_custom_field extends acf_field_repeater
{
    public function __construct()
    {
        $this->name = 'my_custom_field';
        // ... ohter stuff

        // not calling on the repeater but the core field
        acf_field::__construct(); 
    }
}

    So, with the new constructor, a field registration’s order will happen like this:

    1. my_custom_field::__construct()
    2. acf_field::__construct()
    3. acf_field_repeater::initialize() <—-

    the 3rd one, because my_custom_field will not have method called ‘initialize’, so it will call the repeater’s initialize() and will cause unexpected error depends on the addon. Because repeater’s initialize() will overwrite the correct $default, $name etc… properties. So, my_custom_field->name is actually “repeater” instead of “my_custom_field”.

    I’m not sure if this is consider a bug, cause it’s more like the addon author need to fix their code 🙂

    There’s actually another cleaner quick fix, which is adding an empty body initialize() method on the my_custom_field class

  • Hi @gummiforweb

    Thanks for the post and info!
    Elliot here – ACF dev.

    The new ‘initialize’ function was added in to allow for inheritance, as the previous model did not.

    May I ask how you were previously extending the ‘repeater field’ class?
    Previously, any settings made in the my_custom_field _construct() function would have been over-written by the parent acf_field_repeater _construct().

  • Thanks for the explanation gummi, that sheds light on the add ons that do seem to be having a problem, like the image crop field that extends the image field, although that one also seems to be having an issue due to a change in the image field’s return value.

  • Hi hi,

    Here’s a simple example of how a addon extends the core field looks like:
    https://gist.github.com/gummiforweb/3293ec7a0f0708df40c2ae5df8252fa3

    Here’s some things I notice so far with the sample field,
    1) When create new field, the field “My Custom Field” do show up in the field type dropdown, but after 5.6, “My Custom Field” doesn’t show up in the dropdown anymore.
    5.5.14: https://www.screencast.com/t/weRD4owkUY
    5.6.0: https://www.screencast.com/t/7BETqEES3

    2) When editing and exiting field in a post, it’s loading repeater’s render_field. (i think this might be true for all the field actions/filters)
    5.5.14: https://www.screencast.com/t/lVliDpia
    5.6.0: https://www.screencast.com/t/YqDTz23RQ

    Right now, a quick fixes on the addon part is to add an empty initialize method like: 

    
public function initialize() {}

    🙂

  • Hi @gummiforweb

    Thanks for the reply.
    This is great info.

    I did not realize that developers would call the acf_field::__construct(); directly like this. Sorry to have caused this new issue.

    Yes, the best solution is to add a blank initialize function to the field class. This will avoid any ‘inheritance’ issues.

  • 🙂 thanks for 5.6 though, loving this one so far

  • function initialize() {

     /* do nothing */
			
}

    The above function worked for me! thx

  • Hi @gummiforweb

    Thanks for the support. I’m really sorry to have caused you this issue, I’m sure your inbox is a bit more full today!

    Looks like you have already released an update which is awesome. If you are looking for any more info, I’ll be chatting about it here: https://github.com/andersthorborg/ACF-Image-Crop/issues/45

    In short, adding a blank ‘initialize’ function will clear the problem 100%!

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

The topic ‘ACF Pro 5.6 Update: "Restructured plugin files"’ is closed to new replies.