My team just switched to using acf-json and we have some questions about how to treat the files in terms of a team using git.
The question is basically, should we always commit the .json files when they show as modified and should each team member adhere to a habit if syncing immediately after a pull?
Recently (before I understood that syncing was not automatic) I changed some things in the admin before I synced. Of course that made my ‘modified’ date newer and syncing was no longer an option. We fixed it by generating new .json files from the production server and synced our local machines to them. Problem solved.
But… after I synced, newer .json was created which are effectively identical to what I just imported but with a newer modification date.
Now, if I commit those and another user syncs those won’t the same thing keep happening forever?
For now I will just delete and not commit them but I’m hoping someone can explain a far more automated, not so hands on workflow when field groups are edited.
Maybe I got the question wrong,but
Personnaly I use the PHP export.
So each Time I modify ACF fields in the BO, I re-export to php, include it in my theme…
I save Json files just for safety reason
Acf PHP export is very good feature,… able to add dynamic fields, git able,…
How does that work for your team though? We have a number of people working on the same project so for safety reasons, whenever someone saves a field group and commits, we must send out an alert that everyone should do an acf sync immediately after pulling. It’s inconvenient but not near as much as telling everyone to re-export production and then re-import locally. Besides that, the only real issue is that a new acf-json file is created after sync that is virtually identical to the one that was just imported aside from the change date. I’m thinking acf should not save new json immediately after sync.
I believe what Joel is pointing out is that the ACF-JSON updates on EVERY save of an ACF field, including sync. Since saving a Sync creates a new date-timestamp, this becomes the new master when pushed up to Git, and then everyone else Syncs, creating new date-timestamps, and then it’s turtles all the way down.
This is an interesting point.
I don’t think there is any downfalls to disabling the ‘save json file’ during the sync process, but before I add this to my to-do, can you please post a step by step to produce the issue:
site 1, create a new field – saves a new .json
site 2, import the .json…
To illustrate the issue, lets say DevA and DevB have identical local copies.
1. DevA makes a change to My Field Group
2. acf-json/group_xxx.json is overwritten automatically
3. DevA commits and pushes group_xxx.json
4. DevB pulls group_xxx.json
5. DevB syncs My Field Group from within the ACF admin
6. acf-json/group_xxx.json is overwritten automatically
// now the bad stuff
7. DevB commits and pushes group_xxx.json (although the only thing that changed is the modified date)
8. DevA pulls and is notified by ACF admin that there is something to sync (although nothing has changed)
With poor communication this could conceivably go on forever.
What we do
Instead of step 7+ we immediately do a
git checkout acf-json/group_xxx.json after a sync to stop the loop.
I’m having the same issue with the way the json file is updated after using the sync feature.
* check in an updated json file to origin
* update remote using git pull via terminal
* hit sync on the remote via WP-admin
the json file is now modified with a new timestamp and “local”: “json” added to the end.
This creates an issue with our workflow since the remote should not be modifying files, and I have to do a git reset or checkout — before pulling any other changes.
Not sure when this issue was introduced, 5.2.8-5.3 all modify the json file when syncing.
We can get around the amended json issue locally by pulling the DB rather than using the sync feature. But can’t do this the other way around.
This is very clear, and I can understand the issue.
I’ll add this to my to-do and remove the ‘update JSON file’ during sync
This workflow issue has affected our dev team too, so preventing it from changing the timestamp during sync would be ideal.
Is there any way to take this a step further and prevent the timestamp from changing unless changes are actually detected in the Field Group? I was able to hack something together to do this inside the core/json.php file, in the acf_write_json_field_group() method but the code wasn’t exactly clean.
It would probably be better if this could happen when the fields are saved to the DB so the updated timestamp never changes (and the JSON would be overwritten with the same timestamp), but I’m not sure how difficult this could be.
Having said all that, the scenario of one of our developers saving a Field Group without making any changes is pretty rare, the sync issue is a higher priority.
Thanks again for looking into this!
Just tried 5.3.1. Works great!
Works perfectly for me too, I’ve already started writing some custom scripts to take advantage of this feature (such as an integration with the Faker library for auto-populating a complex ACF site with dummy data). This has opened up a whole range of new possibilities for us, thanks again!
That sounds cool, I’d like to see that. I just built a custom filtered search for our site and it was a beast to create enough posts of a custom type to test search against. I tried using LastPass’s custom form profile to auto fill but a lot of ACF’s great features like multi-select taxonomy and wyswyg are not accessible.
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!