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
