Add some functions to allow CRUD operations in JSON files to core

I am a strong defender of “add as least as possible” to core, and “remove as much as possible” to keep core lean.

But,

I am in the adventure of creating plugins to manage Custom Post Types, Custom Taxonomies and Custom Fields. Have two of those working but I don’t like to store the information in the database.

It would be a great feature to avoid storing that data into the database, and store it in JSON files instead.

Why?

Because I may be working on a site in my local environment, create some Fields, CPTs and Taxonomies via those plugins, and the only way to move those changes to production would be to repeat the process on production, or somehow export all that data from my local env to production.

ACF also stores Fields in JSON files, but creates its own JSON API for this.

I think it would be cool to allow plugin developers to store some specific data into JSON files, which can be commited to the repo or just copy/pasted, to gain all those ready to use Fields/Taxonomies/CPTs or whatever else that the plugin may offer. (Many plugins just use “options” for this).

And all of this with a centralized JSON DB API, instead of letting each plugin create its own JSON DB API.

I found this excellent simple yet complete solution: cybrox/crunchdb: A simple JSON based database system written in PHP. Useful for smaller applications. (github.com)

Three relatively short PHP files. It can be adjusted.

So CP Core would end up with two databases:

  • The current one, for all the heavy content
  • A simple JSON based one that can be commited to the repo, for site settings and simple stuff that needs to be moved from one installation to the other easily, by copy/pasting the files or via Git

If you like this idea let me know. In any other case, I will just add it to the plugins once I get time to work on them. Just posting this now so this can be discussed.

It doesn’t break anything and it provides value to ClassicPress. But of course, this may be seen as bloat from other respectable perspectives.

The export is built in, and is also easy to add a new export/import, along with there already being lots of plugins to manage export/import.

While it’s your choice, you should give some thought to using the standard database for custom posts and taxonomies, so that other plugins and the theme can be used for the custom stuff. Otherwise, you have to reinvent everything.

And by the way, the current JSON API is called REST.

Will look into this. Just for curiosity, why would ACF prefer JSON then?

See: ACF | Local JSON (advancedcustomfields.com)

Quoting:

  • “dramatically speeds up ACF”
  • “allows for version control over your field settings”

(none of them apply with having / moving around database entries)

I don’t mean the JSON API in the sense of communicating with CP from outside. More a PHP API to communicate with files.

  • Write this into this JSON file.
  • Read whatever from this JSON file.

They are solving a different problem. They also have an agenda, which is not necessarily good for users.
MySQL has permissions built in, locking, all sorts of stuff for queries. Core also has permissions. All of that is bypassed when there is a flat file sitting there publicly available to the internet.

1 Like

Agree with @joyously 100%. The REST API isn’t just for external connections either. I use it extensively within a site, and you can use both PHP and JavaScript to communicate with it.

Excellent. Some are fair points. I don’t want to turn this into an endless discussion but I think you are misunderstanding what I mean.

As far as I know this has nothing to do with the REST API. Why are you talking about the REST API?

I was just talking about some PHP functionality that can handle read/write JSON files and query them.

REST API works with JSON but has nothing to do with this, as far as I know.

Permissions that can be used to write or not the file: if(have_permission()){ write_it() }

There are solutions to prevent this file from being public.

But all right, If there are no votes in favor, I’ll just add it to the plugins. Only problem is… it will be redundant, but, all cool.

You can define your own endpoints in the REST API and then read or write what you want to/from it.

But that’s not the point of my proposal, my proposal is to be able to do something like:

$jsonDB->table('plugin-stuff')->select(['type', '==', 'chocolate'])->fetch();

It’s database CRUD features.

The REST API is something else. It’s like saying… you don’t need this because there already is a media gallery where you can potentially store json files.

Just being able to have an endpoint (custom or not) is not what this is about at all.

(Hope this doesn’t get interpreted as rude, I’m being serious and appreciate your feedback)

I’m not easily offended, so I’m certainly not taking this as rude!

You could actually compose an endpoint to do even that, but it sounds like you’re just duplicating the options table. I really don’t see the point of that. If it’s that you specifically want the results in JSON, then I suggest you Google for a very informative post (can’t remember where I saw it right now) on how to make an internal request to the database to get just that.

No, it’s not this.

This is not about the format, it’s about storing the information in static files, instead of a MySQL database. Could as well be YAML files, no need to force JSON.

The reasons are:

  • Easily move those specific changes across different installations without a need to export/import.
  • Allow version control
  • Tremendously faster, increased performance

This is not for users to save blog posts into JSON files or to replace the database, at all. It’s to add the possibility to save some very specific information into JSON files instead of the DB, to take advantage of the mentioned benefits.

The possibility is always there, this is just aiming to centralize the process so that plugins don’t need to reinvent the wheel for that.

I wouldn’t add another “database” functionality, but I do see what you’re referring to. This is basically a configuration/settings export/import, which I think could be useful.

For example, Beaver Builder team created Customizer Export/Import plugin. This is the type of settings import/export feature I would support. It exports everything in a file, which then can be imported to another website.

This could be beneficial to allow migrating settings/features across websites:

  • All the core settings
  • Customizer settings
  • Custom post types
  • Custom taxonomies
  • Menus
  • Sidebars
  • Widgets
  • etc.

Users could have a screen where they would select what settings they want to export.

But. two main things:

  • This should be core plugin, not everyone needs it but it can be very helpful
  • This shouldn’t be read from JSON file. JSON file can store the data, but whe import process would need to import eveything to the database. This is where it would be stored.
    • Most of the settings already are part of the database, so that’s easy. The harder part, how do we store CPT and taxonomy configuration? Do we also offer UI to manage it? Might be a good separate core plugin.

But there’s no reason to add another CRUD functionality because core already offers everything one needs to do what you want.

It can be a good plugin, but not core.

1 Like

It’s more than that, it’s also a version control system associated to that specific set of settings (and a performance improvement).

But you are misunderstanding one thing: this is not about exporting “Everything”.

It’s about allowing each plugin to use that feature.

If this get’s done as a plugin, not core, other plugins won’t be able to rely on this. If I need to store the information somewhere, and I (as a plugin developer) decide that I want static files, I will have to force the user to install this plugin before installing mine.

That would be crazy (i.e. not actionable).

Or it could be automatic with plugin dependencies.

1 Like

@moderators please close this petition as declined.

We cannot count on something that doesn’t exist yet for something that doesn’t exist yet. One step at a time.

Conclusion is: if a plugin wants to store stuff in files, it should just handle it.

As a note, for DB sync, see: https://phinx.org

But see Plugin Dependencies – WordPress plugin | WordPress.org

1 Like

That’s a nice plugin (even if it is compatible for WP 6+).

The problem is that if you create a plugin with dependencies and the dependency plugin is not installed, nothing works.

So, somehow, this is a dependency too.

When and if this gets ever integrated into core, which makes hella sense, we can count on it.

However, I agree that dependencies are a very nice solution for this petition, so I (the petition starter) vote to close this as declined and forget about it.

I also agree that the current focus should go into populating the Plugin Directory, so that CP gains value in that sense, before “wasting” efforts in other fancy stuff.

2 Likes

It’s not “a dependency too.” It’s just the very definition of a dependency. And such dependencies are already in use. See, for example, Classic Editor + – WordPress plugin | WordPress.org

This topic was automatically closed after 20 hours. New replies are no longer allowed.