Support

Account

Forum Replies Created

  • Is there any thought about adding this functionality into the core of ACF? Saving field groups to the same location from which they were loaded would make life way easier for all these instances where things use ACF separately but are in active development together, such as site-specific plugins that are developed at the same time as a theme.

    Perhaps there could be two directories, like acf-json and acf-json-sync, where acf-json would be the distribution directory and acf-json-sync would be the development directory. Files in acf-json would not be editable and only be loaded if acf-json-sync does not exist. Files in acf-json-sync would take priority if they exist, and field groups loaded from there would be editable, syncable, etc. Field groups would be saved back to the same acf-json-sync directory they were loaded from as well as to the neighboring acf-json directory. That way we could develop with the GUI normally and then simply exclude the acf-json-sync directory in the distribution version of the plugin/theme.

    Or perhaps one directory and some other way to tell ACF whether it’s dealing with a dev or dist version, whatever works best.

    Other than that there could just be a dropdown select in the field group settings where we could select from the available save locations.

    In any case… seems like this all could be a bit more development-friendly.

  • How would one use get_post_meta() to retrieve a Repeater? When looking in the database, it appears that the sub-fields are saved as individual rows instead of being saved as the array that get_field() normally returns.

  • Personally I’d disagree with this – the blocks should behave and look as any other Gutenberg block to keep the UX consistent. I’d agree that a trash icon would be nice, but that would be a suggestion for the Gutenberg team, not the ACF team.

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