Anyone else experiencing this weird behaviour?
Field group containing a flexible content field.
Adding a new layout works but all that is saved is the layout label, name and layout. Whatever fields we add they do not show up in the backend.
Curious: they are stored in the database except their post_status is set to “future”.
We deactivated all plugins > no changed
Checked if there are any filters which interfere > nothing
Even changed the maximum input vars to 9000 > no change
Any idea why their post status is wrong?
Could it be that we use a MariaDB instead of mySQL?
After checking different possiblities I saw that everything is saved to the DB but post_status remains “future”.
Where is this set?
After changing this to public in the db, everything is there.
It sounds like you’re running into an issue with the php setting max_input_vars. This plugin will let you know if you are https://wordpress.org/plugins/wp-max-submit-protect/
Hi John. Unfortunately this is not the problem. As I wrote before we already set the max to 9000. I installed the plugin you suggested and added a single text field to the group. Saved, got the update message and it is in the db but like any other field, it’s post_status is set to “future” and that’s the reason it doesn’t show up in the backend.
I just did a test and I’m not seeing any problem adding fields to a layout.
If the post status of the field is being altered, do you have any plugins installed that manage or update the post status of new posts? Try deactivating it and see what happens. Have you tried deactivating plugins or changing themes?
A test on your installation/server doesn’t really help for our problem – it is definately not working as before and we try to find the source of the problem.
As stated in the main post here: we already tested with all plugins deactivated. We changed maximum numbers of input vars and we checked the theme’s functions for any filters. Nothing helped to fix the post_status problem.
I have the most current version of the plugin installed and the most current version of WP installed on my test site. All that I can tell you is that, only ACF installed and using an unmodified version of either 2015 or 2016 theme, I cannot replicate the issue.
I did a search of all of the ACF code and there is nothing in ACF that could be setting the post status to future. You might want to open a new support ticket https://support.advancedcustomfields.com/new-ticket/
Already opened a ticket today.
We even cloned the site, completely disabled all other plugins.
Deleted the field group, imported it again and it shows up empty with an info “schedulded” next to it.
Something really doesn’t work together here.
Would you mind attaching a copy of the exported field group that I can test? You can attach it here if you put it in a .zip file.
No problem.
I guess it’s a problem between ACF and the server configuration.
Whatever we do, it’s impossible to add new fields for now.
It’s not a problem with the field group, it imported and works fine for me.
You say that the fields are marked as “future”, WP does this when you set the publish date at some time in the future, you can’t actually set this yourself. In the database, what is the “post_date” value for the fields marked as “future”? Could it have anything to do with a difference in when WP thinks it is and when the server thinks it is?
Or even a difference in the time that the PHP server and the MySQL server think it is. It’s just a guess and not even sure how you’d test this.
That’s what I assumed before but I couldn’t find a difference
UTC is 200 and correct. Mysql Datetime and Server time is the same.
Also, the field post_created and modified times are also correct.
What a pain in….
—
will clone it to another server
Update: cloned it to another server and guess what. Works perfectly.
Now I need to find out what the problem on the production server could be.
Damn 🙂
Does the post_date match the post_modified time and does the post_date_gmt match post_modified_gmt and are the values recorded equal to the time you update the field group or are they for some time in the future. It’s definitely and odd bug. I’ve done some more digging around in code and don’t really see how this can be happening.
At this point I can tell you what I’d be doing. I’d be following the save/update code and adding thinks like:
echo $now; die;
directly into the the WP core code to see what was going on. Check out wp-includes/post.php line 3200
Thanks for the hint, John.
I did what you suggest and $now is 2 hours behind current time (guess it’s UTC time)
mysql date (Post Date GMT): 1455784671
mysql date (now): 1470733499
now: 2016-08-09 11:04:59
In WordPress, timezone is set to my current time (UTC + 2) as it is for the mysql server. So right now I am curious where we need to fix it.
edit: here’s the debugging for save_post
Post Status (before):publish<br/>
Post Status (after):publish<br/>
mysql date (Post Date GMT): 1455784671<br/>
mysql date (now): 1470740759<br/>
now: 2016-08-09 13:05:59
Post Status (before):publish<br/>
Post Status (after):future<br/>
mysql date (Post Date GMT): 1470747926<br/>
mysql date (now): 1470740759<br/>
now: 2016-08-09 13:05:59
Post Status (before):publish<br/>
Post Status (after):publish<br/>
mysql date (Post Date GMT): 1455784671<br/>
mysql date (now): 1470740759<br/>
now: 2016-08-09 13:05:59
Post Status (before):publish<br/>
Post Status (after):future<br/>
mysql date (Post Date GMT): 1470747926<br/>
mysql date (now): 1470740759<br/>
now: 2016-08-09 13:05:59
Post Status (before):publish<br/>
Post Status (after):publish<br/>
mysql date (Post Date GMT): 1455784671<br/>
mysql date (now): 1470740759<br/>
now: 2016-08-09 13:05:59
To be honest, I don’t know where the disconnect it. You basically need to follow all of the functions and figure out where WP is getting the wrong times from. Beyond that I’m not sure I can help you any more. Since we know it’s somehow server related the only thing that I can guess at is that somehow the is some server configuration somewhere that’s causing some php or WP function to return an incorrect timestamp.
It is fixed now. After struggling two days with the webhosting company they admit that their timezones were not configured correctly. What a pain in the ass.. Thanks for the support. Your hint with the post.php debugging helped finding the time bug.
acf-export-2....zip