• Spinit

• in reply to: ACF duplicating fields
• February 5, 2015 at 11:07 pm

Actually I just updated to ACF 5.1.8 and the sync still does it.

We have production- and staging servers. Locally we develop on Vagrant.
We git everything to bitbucket and sync fields between vagrants and servers through the ACF json files.

On the production server, the customer is adding content, and we respond to requests and bugs by fixing them locally, pushing, bambooing to stage and then when stable bambooing to prod. To get the changes locally we use WP Sync DB to pull the database from prod to dev and then sync the json to get our ACF to the latest state.

I’ve had to use https://github.com/FreshFlesh/ACF-Sync to get it to work, because when I try to use the ACF bundled sync it acts really, really weird.

What it does is sometimes duplicating fields, and then loosing repeater subfields. This might not be a catastrophe if it didn’t arbitrarily make the json explode at the same time. Now counting three times, I’ve been in the position to have to reset to earlier commit, backing up the json, pulling myself back to HEAD and then pulling the DB all over again, and firing up the ACF-Sync plugin to do what ACF should be able to do just as well.

** Hey Eliot **, I think the culprit here might be that you try to do too much in one go. You try to sync both ways, don’t you? First pulling the json into ACF, and then saving a new json. So if operation one creates a problem, then operation two gets equally fu**** up… I would like the option of pulling one way only, letting the json stay untouched, that way I have something to fall back on if the fecal matter hits the rotating impeller.

Could you separate the sync to db and sync to json from each other?

I think I will start at ticket…

• Spinit

• in reply to: Unnecessary AJAX-calls
• December 11, 2014 at 8:31 pm

Damn, I should have taken a closer look at how ACF handles conditionals. I had the impression it loaded just what was needed, not everything. But it seems that with conditionals all the fields are still there, just hidden.

This of course means that some calls are made for fields I don’t use. And some scripts runs brutally slow.

I chose conditionals, because it made the interface behave as I wanted it to. But what I should have done where to create new layouts for each content type, since those load as needed rather than always.

As soon as I moved the relationship field to its own layout, the AJAX-calls stopped. I then found the next bottleneck, which where the wysiwygs. I have a 40 second latency between loading tinymce and rendering/continuing.

It seems the code for handling conditionally hidden elements is less than complete. Really, stuff should be truly inactive when they are conditionally hidden. It’s bad enough that they get posted, they should not be scripted as well.

But, to be fair, it makes a kind of sense – if you see conditionals not as a way of choosing what kind of content to add, but as a way to make variations in the kind you have already chosen.

Could I ask, as a minimum, that this is reflected in the documentation? It would prevent the kind of gotchas I’m experiencing now. I’m among those that tend to RTFM before I start, so it would have been a great help avoiding this situation.