Local JSON

[tw2113]

We will be borrowing a lot from the pros, I mean, Advanced Custom Fields. Do we dare outright copy https://plugins.trac.wordpress.org/browser/advanced-custom-fields/tags/5.12.3/includes/local-json.php and amend as needed?

Enabling

• UI setting vs folder existence
  • We don't really have a page with random-ish settings available, so enabling dynamically would be awesome and save time/options pages.
• "is enabled" method, which checks if folder exists and if yes return true. else return false.
  • return false if not write-able to.
    • Throw an admin notice of some sort if so.

Saving in UI

• New items should be added to file.
• Existing items should update update to file.
• Deleted items should be removed from file.

Avoiding file deletion.

• With ACF, you have to version control the file, and do a git reset to restore after clearing out database version. How can we avoid this nuisance step?
  • Tools menu and {""} import method doesn't trigger saving/deleting hooks, but still removes database options.

Loading and precedence

• DB option should be used before local JSON copy.

Sync settings

• Show if local version is different or more specifically newer?
• Timestamps like Advanced Custom Fields?
  • New CPTUI option for last save time?
    • Prevents need to edit our existing data.
    • Only if we enable local JSON version?
• UI needed to sync.
  • Link in "Listings" page?

CPTUI UI data display like tools, get code, listings.

• Should we show local loaded data in the same places, perhaps with notes of "loaded via theme" or similar wording?
  • Show but have various links like "edit" etc disabled because there's nothing in the UI to edit without sync?

Multi-Site

• append ID to file name, if Multi-Site and not main site. Leave main site ID off to avoid potential backwards compatibility breaking for people using the functionality already.

Extra testing

Confirm this does not interfere with CPTUI-Extended. Bonus points if made to work with Network-wide content types, or made to be able to work with that.

[tw2113]

Enabling

All bullet points done and available in https://github.com/WebDevStudios/custom-post-type-ui/tree/891-local-json

[tw2113]

Saving in UI

All bullet points done and available in https://github.com/WebDevStudios/custom-post-type-ui/tree/891-local-json

[tw2113]

Multisite ID appending got handled as part of the Saving in UI section

[tw2113]

Loading and precedence

Now passing in existing cptui data to override filters, and returning those if not empty, else reading from local JSON. Also available in https://github.com/WebDevStudios/custom-post-type-ui/tree/891-local-json

[tw2113]

CONFLICT

As is, we're wanting to prefer the database version over local JSON version. However, we allow adding new via UI, even if local version exists, and that would create a new option, BUT ONLY WITH THAT ONE NEW ITEM. So we have potential to freak people out if they have many registered which is very common.

Do we want to try and merge database versions of specific types, and override loaded local copy of same slug, with the database version? Or perhaps if we have a local version, and no database version, force importing?

[tw2113]

local_is_being_used() check if files exist, not just if folder is writable

switch to saving individual json files per post type/taxonomy ?

instead of filtering the get content type functions, leave those alone and create new function for just reading json file(s) and load/combine data, dependent on if still 1 file or all files? a case of if is local being used, pull in info with this function, else, currently used function?

[tw2113]

creating some local content types, and then deleting the db copy, and then adding new afterwards would wipe out the local json copy IF storing all of them. So we need to get around that somehow.

[tw2113]

Need to account for any helper functions that are meant to fetch slugs and data.

[tw2113]

With individual json files for each post type, we still need to also account for loading specific files for specific sites.

Specifically in local_combine_post_types and local_combine_taxonomies

[tw2113]

With individual json files for each post type, we still need to also account for loading specific files for specific sites.

Specifically in local_combine_post_types and local_combine_taxonomies

This has been handled in our branch

[tw2113]

creating some local content types, and then deleting the db copy, and then adding new afterwards would wipe out the local json copy IF storing all of them. So we need to get around that somehow.

We have moved from an all-or-nothing approach to an individual content type getting their own file, and we combine into our desired array during loading/registration.

[tw2113]

local_is_being_used() check if files exist, not just if folder is writable

We have local_has_post_types() and local_has_taxonomies() which will do a combining of found local JSON files, if any exist, and check for empty()

[tw2113]

I think https://github.com/WebDevStudios/custom-post-type-ui/issues/891#issuecomment-1254195669 is still our biggest hurdle before primary development of this feature is handled and we're ready for general testing and confirmation of behavior.

[tw2113]

~~https://github.com/WebDevStudios/custom-post-type-ui/issues/687#issuecomment-1292740292~~

[ivenomweed]

OMG FINALLY :O thanks a lot have been looking at your docs and stuff for years for this feature <3

[ivenomweed]

On single WordPress installs this works like a charm!! However, in multisite instances, the shipped JSON only works on the main site any other child sites don't show the JSON CPT packaged in the theme but if you create a new CPT in the child sites it does create a new JSON files in the cptui-json folder.

Can't wait for this release ^_^

[tw2113]

It should have multisite support generally working, unless I broke something somehow. The site ID should be getting appended to the generated JSON file.

That said, I need to resume working on this sometime soon, and also do a good amount of testing before final release.

Thanks for doing some testing ahead of time @ivenomweed :)

[ivenomweed]

@tw2113 yes it's adding the site ID properly it's not broken at all. But if you wanted to supply a post type let's say something like "portfolio" (like how acf-json works in a way) for each individual site from the theme it will only show up on the main site, not the sub-sites as when you are developing locally the JSON file is saved as cptui_post_type_test_data1.json and in the plugin, there is this following check:

if ( $file_site_id !== $site_id ) {
	continue;
}

so it doesn't show up on all the sites basically.

I modified the code a little bit to make it work.

First: Renamed the JSON file manually from cptui_post_type_test_data1.json to cptui_post_type_test_data0.json

Second: Modified the check

if ( $file_site_id !== $site_id ) {
	continue;
}

to

if ( $file_site_id !== $site_id && $file_site_id !== 0 ) {
	continue;
}

here am counting 0 as a global post type. I don't know if this is a dumb idea or not. And I apologize if that's out of the scope.

And I have been using CPTUI for almost 6 straight years you bet I wud be testing it :P

[tw2113]

@ivenomweed if I'm understanding you correctly, you are wanting the ability to have locally saved CPT data that gets read and added to all the sites?

I know with CPTUI-Extended, our premium extension, we have network-wide content types that we'll need to be minding here, but I am thinking at least initially, we want to make sure the free plugin has top notch support and functionality.

[ivenomweed]

@tw2113 aaah I see got it thanks for the clarification awesome work btw <3

[andyplak]

For what it's worth, I'd just like to add that I've been testing this out on a single site and its working really well. A database revert to an older (pre newly added CPTs) saw these added as expected from the json. Looking forward to this being released, but I'll be running this branch for a certain project until it does.

[tw2113]

@andyplak Awesome to hear that it's looking to be pretty solid already, though I know I've stalled on finalizing and finishing it up as well.