Implement local json syncing for ACF config

[cjg89]

Description

See title

Why it's Important

To reduce the amount of manual uploading of ACF configs we have to do.

Alternatives

Possible Implementation

We did this in at least one other recent project. Find that and use that as inspiration.

Additional context

[jmbarne3]

We need to make sure we test this to make sure we can support multiple json sync points. If for example, another plugin were to also have a sync location, would field groups properly sync to their separate json files in each plugin folder, or would they sync all the fields in the db to a single sync location.

I feel like this was the issue we were running into with using this method. We should do some testing and see what happens.

[jmbarne3]

Adding a reference to a good "how to" article ACF has on this: https://www.awesomeacf.com/how-to-avoid-conflicts-when-using-the-acf-local-json-feature/

[jmbarne3]

Potential difficulties:

1. The acf/settings/save_json excepts a single path to be returned, making it impossible to sync multiple JSON files. This is going to be a challenge when we have multiple plugins enabled on a local dev site and we need to sync changes back up.
2. The acf/settings/load_json allows for multiple paths - allowing the plugin to provide its json path - and works great as long as the JSON uses the correct schema (details below). However, because we can't utilize the save_json filter above properly, automatically syncing these files up will not be possible.

Possible solutions:

Manual Updates

With the load_json filter set on a plugin, that plugin's ACF fields will show up in the Sync tab in the Field Groups list. Once a field group is synced, the developer can make whatever changes need to be made and then manually re-export the field group. This would involve the following:

1. Exporting the individual field group using the JSON export option in the Tools menu. If multiple field groups have been created or modified, each one needs to be exported separately.
2. The JSON needs to be updated from an array, to just be the field group object: [ { 'fields': 'are', 'here': '!' } ] to { 'fields': 'are', 'here': '!' }.
3. The appropriate json file can then be created or updated, making sure that the modified field is not removed - or added if making a new file. The filename must match the group id, i.e. group_somecrazyid.json.
4. To ensure the sync option is available the next time a developer works on the project, the modified value has to be incremented. If we were using the save_json method for syncing, this would happen automatically. Since we're not, we would have to increment the value somehow.

Storing ACF Fields in Code

The workflow for creating and editing fields if we store them in code would look something like the following:

1. Design all the ACF fields in the admin menu, like normal.
2. Export the ACF fields using the Export PHP option in the Tools menu.
3. Add the PHP markup to an appropriate place within the project and clean up for readability. This might include removing default values. Or we could leave all the markup and just clean up the spacing.

One possible solution to make working on the fields easier would be to include the json file in the project for easy loading. The fields could then be worked on and then exported as PHP again, allowing the code to be updated without a lot of manual editing. This workflow would require us to remember to always update the PHP code and the JSON when we make edits.

Build a plugin to do all this

Another possibility is we use the load_json method to get fields loaded in, but then build an interface via a plugin that allows us to target specific field groups to plugins. The default path for ACF when saving into the theme is $theme_dir/acf-json - we could standardize on that for plugins. Each plugin would then need to have one snippet added so that the $plugin_dir/acf-json directory is added to the $paths array that is returned by the save_json filter.

As an additional layer of safety, we would only install this plugin locally, requiring any field changes to be made locally. We could also check to make sure the WP_Debug constant is set, which it never should be in a production environment. And all syncing would be done via an options page, to ensure no weird overwrites happen automatically.

I'm open to any thoughts on suggestions on any of these approaches.