Support

Account

Home Forums Feedback Workflow hassle for multiple developers making a theme and plugins

Solving

Workflow hassle for multiple developers making a theme and plugins

    • Tim

    • October 15, 2019 at 3:55 am

    Howdy!

    These points are regarding a workflow with git, multiple developers, a website where both the theme and some plugins are developed, and the client does not manage ACF field groups or even knows that ACF provides the fields.

    Currently new local field groups get their json dumped in the theme folder. I then move them to the correct plugin. I add the private: true tag, and commit them. When a coworker needs to change that field group, (after a git pull) they have to move the file to their theme, remove the private tag, sync it, apply the changes, add the private tag back in, move the file back to the plugin and commit it. Can this not be made any simpler?

    1. There should be multiple json save points.
    There is only 1 save point in ACF according to the docs. Field groups can provide functionality to the site in general, like the company address, or the to specific theme, like the header image. So should there not be multiple save points? When a developer decides to create a new group he can then select if it should be saved as part of the theme, or as part of one of the plugins. When he edits an existing group you could show what it belongs to, and allow it to be moved, in case of a mistake during creation.

    2. Can we have the json private true flag ignored on the local environment?
    When a json field group with private: true added to it shows up in a json save point, it gets loaded, but doesn’t provide a UI to sync to the DB. As the docs say “This may become useful for plugin / theme developers who wish to keep their bundled field groups hidden from the user.”. Indeed, a great feature! However, if we’re going to take away field management from the end users on the production server, then we are going to have to do field management on the local installs of the developers. When a new developer sets up his local environment, the json field groups won’t show up either, because of private: true. Just like on production. Wouldn’t it be nice if private: true was ignored when WP_ENV was set to local? Or some other “Hey ACF! This is a local dev env!” setting. We could then leave private mode on, and still modify the groups. The syncing to the DB should still be automatic, so the json is basically the primary source of truth. No more manual syncing needed. If this is implemented there should also be an option added to field groups to manage their private-ness. Private being off by default, for anyone that doesn’t want to use this new workflow, and perhaps a warning tooltip, for basic users, that they won’t be able to get into that field group anymore once private is turned on, without enabling local dev env mode, or removing the private flag from the json file.

    Why not use the PHP export?
    You can’t use the field group editor on PHP-made fields afterwards. Right? I love PHP, but there are so many field types and arguments to ACF that a GUI is not only easier to use, it’s possibly faster than hand coding coding too.

    Related: https://support.advancedcustomfields.com/forums/topic/save-local-json-file-to-load_json-location/.

    I haven’t yet tried to see what I can code myself, or already exists. I believe I did bookmark a multiple save point plugin somewhere. I also did a few hours of research so I just had to get this posted and out of my head so I can go home. 😉

    Thanks for taking the time to read. Looking forward to your thoughts.

  • 1) you can use the plugin, there are also topics on this site about saving field groups to a custom location. I generally build this into my plugins to force saving field groups used by the plugin into a folder on in the plugin and load field groups from there.

    2) I have thought about this as well. There are filters that are run on field groups before and after the json saving/loading. It is very likely that the private flag could be turned on and off by your plugin using these filters and checking some env setting when they run, but I don’t know this for sure.

    • Tim

    • October 17, 2019 at 6:04 am

    I’ve played around with that plugin and some snippets, yours included. 😉 Most are quite old, but @infinimbal ‘s is quite new, and the UI is nicely integrated into the FGE. I’ve played with his code a bit and made myself this:

    It works, but its got a few bugs, will post the code later.

    Regarding my rant yesterday. I’ve done some testing and drawn some nice to know conclusions. Probably amateur hour, but it was useful for me.

    (FG: Field Group. FGE: Field Group Editor.)

    1. When you save a FG in the FGE, it gets a DB entry, and optionally a JSON. (obvious)
    2. Syncing is making a DB entry from a JSON FG. (obvious?)
    3. The FGE only loads from the DB. You cannot make it edit JSON files.
    4. Both private and public JSON FG are active right away, if in a load_json dir.
    5. Public JSON FG can be synced. Private can not.
    6. Private JSON FG do not sync automatically either.

    Sooooooo.. DB entries cannot be abandoned if I want to use the FGE. To get the JSON in the DB we need to sync. To sync (manually) we need public JSON FGs, so private is of no benefit.

    The solution I’m going for right now is to still distribute via JSON files. Then automate syncing so the DB gets the new changes (Todo). Then use dir selection shown in the screenshot to always have a JSON file made for every new DB entry. And allow us to move the existing JSON FGs to any of the load_json dirs. Lastly, if the WP_ENV is not local I just remove the ‘Custom fields’ menu item. Easy! I hope.

    • Tim

    • October 17, 2019 at 6:12 am

    I’ve played around with that plugin and some snippets, yours included. 😉 Most are quite old, but @infinimbal ‘s is quite new, and the UI is nicely integrated into the FGE. I’ve played with his code a bit and made myself this:

    It works, but its got a few bugs, will post the code later.

    Regarding my rant yesterday. I’ve done some testing and drawn some nice to know conclusions. Probably amateur hour, but it was useful for me.

    (FG: Field Group. FGE: Field Group Editor.)

    1. When you save a FG in the FGE, it gets a DB entry, and optionally a JSON. (obvious)
    2. Syncing is making a DB entry from a JSON FG. (obvious?)
    3. The FGE only loads from the DB. You cannot make it edit JSON files.
    4. Both private and public JSON FG are active right away, if in a load_json dir.
    5. Public JSON FG can be synced. Private can not.
    6. Private JSON FG do not sync automatically either.

    Sooooooo.. DB entries cannot be abandoned if I want to use the FGE. To get the JSON in the DB we need to sync. To sync (manually) we need public JSON FGs, so private is of no benefit.

    The solution I’m going for right now is to still distribute via JSON files over git. Then automate syncing so the DB gets the changes (Todo). Then use dir selection shown in the screenshot to always have a JSON file made for every new DB entry. And allow us to move the existing JSON FGs to any of the load_json dirs. Lastly, if the WP_ENV is not local I just remove the ‘Custom fields’ menu item. Easy! I hope.

  • So, when I’m developing a plugin I generally add my own json save for groups used in that plugin, as you’ve seen elsewhere. I have a single site where I do plugin dev work and this is the only site where the field groups for the plugin are loaded into the DB and where I sync them.

    What I have not done is create a way to alter the private flag setting when loading the field groups from JSON when on my dev site.

    You can’t do this with the acf/load_field_group hook, this hook is not run when a field group is loaded from a json file. What you need to do is use the acf/validate_field_group hook. I don’t know if this will work, but what I’m thinking is that I can add a filter, check to see if it’s my dev site, if it is then set the private flag to false. The only question is, will this allow me to sync the group on my dev site while preventing sync on sites where the plugin is used? Unfortunately, I don’t have time to test this theory

    • Tim

    • October 19, 2019 at 3:24 am

    I’ve posted my “multiple save points” code over on the other topic: https://support.advancedcustomfields.com/forums/topic/multiple-save-locations-for-json/
    And here: https://gist.github.com/toscani/635a0ef618fd199d069550f124fe68e6

    I’ve also been looking at sync plugins/code made my own for that, because I don’t trust old code from the internet, and I want to create a complete package specific to my workflow. If anyone else wants to hop aboard that’s fine by me.

    I’ve already put the sync code in the package plugin: https://github.com/Brugman/acf-agency-workflow
    That one’s got one bug atm: You can’t delete any FG because it will get synced back soon after. So I’m going to have to add a hook to delete the JSON when a FG gets deleted.

    • Tim

    • October 22, 2019 at 1:41 am

    Added hooked function to delete the JSON if you delete it in the FGE.

    I’m going back to the multiple save points “bugs”, the final frontier!

    • Tim

    • October 22, 2019 at 3:55 am

    Fixed the multiple save points bugs! Discovered a new one, but not as bad. I think I’m going to try the plugin in a client project now and see what happens. I’ll probably still want to OO-ify it and write a readme and stuff, but it feels like I crossed the finish line! 🙂 New bugs are welcome on Github ofc.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.