There’s a bug with how ACF stores the “field_***” meta value for the relevant key. It appears you add the underscore to the option_name for the field reference and then apply a character limit after this to both the option_name for the value and for the field reference. E.g.
Obviously the _*** option_name needs one more char than the value option name. However, could this char limit lead to edge cases where two option names end up with the same name as only the truncated section of the option_name is different. Would it not be better to enforce a character count on the names themselves in the UI?
ACF is not setting the character limit, that is the WP Database Schema. The options_name field is varchar(64).
The WP team has been talking about changing this to varchar(255) for 4 years with no action taken, they keep saying, “maybe in the next release”.
I routinely change this by altering the database and change this column to varchar(255).
However, when you update WP it will be changed back to 64 and break your site unless you do something to prevent that from happening. Which is why I built this https://github.com/Hube2/wp-update-prevent-db-changes
Even at 255, you still need to be mindful of how long the option name will get, especially with nested repeaters.
I have been giving this some thought.
When I’m creating a field group and putting that code into a plugin I do it in such a way that I get the field group and use the fields in the group to get and/or generate option_name values so that I can get the option values without using ACF functions like get_field.
If, ACF had an additional array value for each field called something like “db_name” or whatever works for Eliot, then, when looping through the fields I can use that value instead of the “field_name”. This would work for post_meta fields as well.
For repeaters, instead of the option_name being
it could be
the real problem occurs with nested repeaters
.'_'.$index.'_'.$sub_field_name can be added infinitely.
Seriously, even 255 isn’t really long enough for option_name for people that create nested, nested[, nested[, nested]] repeaters. 😛
as long as $db_field_name is short enough to accommodate indexes. The only problem might be keeping it short enough to allow for large sub field indexes. How many digits do you allow? How many are people likely to create? 9? 99? 999? 9,999? 99,999? There would have to be some physical upper limit, which is something I don’t really believe in as I fully subscribe to the Zero, One, Infinity Rule.
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
© 2022 Advanced Custom Fields.