Database char count bug

• RichieAHB

• November 13, 2014 at 11:04 pm

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.

options_alternating_recipients_0_alternating_recipient_email_add
_options_alternating_recipients_0_alternating_recipient_email_ad

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?

• John Huebner

• November 13, 2014 at 11:41 pm

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.

• RichieAHB

• November 14, 2014 at 12:00 am

Thanks for the reply – I’ve read the comments on the ticket and it seem crazy that it’s taken so long. I’ll keep that in mind in the future; definitely worth knowing.

• John Huebner

• November 16, 2014 at 5:47 am

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
$repeater_name.'_'.$index.'_'.$sub_field_name
it could be
$db_field_name.'_'.$index

the real problem occurs with nested repeaters
$repeater_name.'_'.$index.'_'.$sub_field_name.'_'.$index.'_'.$sub_field_name
the .'_'.$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.