I just moved a client site to a production server and all the ACF fields are working fine, except for one.
This field does not show on 1) the front end 2) the edit screens of individual posts or 3) the ACF admin screens.
But I can see the field and all its values in the database.
I strongly suspect that it’s a serialized data problem because I had that kind of problem with Contact Form 7 during this same move (data in the database but not showing in Admin screens).
With Contact Form 7 I know what piece of data changed length because it was the same in all 12 forms, but with this field they’re all different, so I’m trying to spot the common thread.
Just wondered if anyone else has had this and if they’ve found another cause other than serialized data corruption…
My set up: WP 3.6 ACF 4.2.2 and the production server is on Bluehost (I mention that only because I’ve never worked on their servers and I’ve never had these kinds of issues when moving databases)…
Hi @seehowtwo
It sounds like the issue may be related to a corrupt serialized array.
Can you view teh database via phpMyAdmin and edit the row that contains the field object?
This row will be found in the wp_postmeta table, with a meta_name of ‘field_123’ where 123 is the field key. You can copy out the meta_value and check that the serialized array is correct.
Did you by chance have a url in the field settings? Perhaps as a default value or in the description? Then, did you do a search / replace when you moved servers? This would cause the issue described completely.
Thanks
E
In the case of Contact Form 7’s corrupted serialized data, it was a problem with a URL, but there is no URL in this field.
I had checked all the value lengths in the problem ACF field object and they’re all ok:
a:10:{s:5:”label”;s:28:”Interior Dimensions Imperial”;s:4:”name”;s:28:”interior_dimensions_imperial”;s:4:”type”;s:4:”text”;s:12:”instructions”;s:77:”Enter the interior imperial dimenions, using this format: 12”L x 34”W x 56”D”;s:8:”required”;s:1:”0″;s:13:”default_value”;s:0:””;s:10:”formatting”;s:4:”html”;s:17:”conditional_logic”;a:3:{s:6:”status”;s:1:”0″;s:5:”rules”;a:1:{i:0;a:3:{s:5:”field”;s:4:”null”;s:8:”operator”;s:2:”==”;s:5:”value”;s:0:””;}}s:8:”allorany”;s:3:”all”;}s:8:”order_no”;i:5;s:3:”key”;s:7:”field_5″;}
The only other thing I can think of is that this Instructions field contains quotation marks (denoting inches), and all of the database entries for that field contain quotations marks. There’s another field for metric and it shows up fine, but has no quotation marks. Could it be some sort of character encoding issue when I moved the database to a new server?
Or a serialized data issue with quote marks?
http://davidwalsh.name/php-serialize-unserialize-issues
Hi @seehowtwo
potentially, yes, the issue is caused by un-escaped quote marks.
I have not experienced this issue before, so it could be server specific.
Easiest way to get the field back working is remove the quote marks and update the corresponding string count
Thanks Elliot – that worked. I’ve never worked with Bluehost before, and the database had been moved around on Hostgator servers with no problems, so, as you say, probably a server-specific issue.
