User Goal: wp plugin commands to reinstall extensions exactly (active/inactive, auto updates on/off) from list file or database backup

[porg]

Big picture: Efficiently backup my Wordpress database. Then restore Wordpress Core + Extensions (Themes, Plugins) as exactly as possible in an automated fashion.

1. In this scenario I back up my Media Library by other means (rsync or CDN). What remains:
2. Backup the database (already know how to do that).
   • Note: That database already contains a list of all plugins (in their exact states) in the table wp_options in the various *_plugins rows.
   • That alone should make a convenient automatic re-installation of all themes and plugins possible.
   • It's a pity that there is yet no wp-cli command making use of this. Big user experience potential!
   • Proposing to make that possible with:
     → wp plugin install: Accepts also path to full or partial database backup .sql (.zip) extension-command#345
3. Source Code: Wordpress Core + Themes + Plugins:
   • Backing up up those generic source code files is a waste as they anyhow exist in public online repositories.
   • But in addition to step 2, I want to backup a list of installed plugins, like various Unix package managers allow that.
     • To keep that extension-list (CSV, JSON, …) for documentation purposes and for automated re-installation.
   • This is already possible with wp plugin list.
     • But currently does not keep track of whether auto-updates for a particular plugin are enabled or disabled.
       • In a few cases I keep a plugin frozen at a particular version on purpose.
       • On automatic restore those plugins should keep that setting.
     • Proposing to improve this with:
       → Include additional column (field) "auto-updates" which can be on or off extension-command#344

[danielbachhuber]

Great idea, @porg !

This is similar to a project I worked on in the past: https://github.com/danielbachhuber/dictator

I've moved your issue to the wp-cli/ideas repo. Our existing packages try to emulate WordPress core behavior as much as possible. This particular idea probably makes most sense as a standalone package.

If you'd like to work on such a package, here are some docs to help get you started: https://make.wordpress.org/cli/handbook/guides/commands-cookbook/

Hope this helps!

[porg]

Flattered that you like my idea! As mentioned I'm a UX designer and no developer.

To model the command verbs along the Wordpress core terminology is a good decision! My wording below is purely to present the idea. Ofc it should match the typical wp-cli style and grammar.

1. I deem a new overall command like restore with various sub-commands not suited for the intended use:
   • because of the manifold possibilities of sources (plugin-list, theme-list, database)
   • to destinations (plugin-list, theme-list, database)
   • and each of them possible having multiple options.
   • all together yielding too many permutations which would explode the grammar & vocabulary, e.g.:

$ wp restore
--plugins [ full-or-partial-DB-file | plugins.csv ] … specific opts e.g. --plugin-version=preserve
--themes [ full-or-partial-DB-file | themes.csv ] … specific opts e.g. --theme-activation-status=preserve
--database ideally-full-DB-file … specific opts e.g. [ --database-prefix-old "wp_"  --database-prefix-prefix-new "wp2_" ]
…

You see: It quickly gets a mess. Because with a database file as a source the user may have different intents for the target (restore the plugins from it or the database tables itself, or only the plugin options, or … or …). It gets manifold pretty soon!

2. Hence I propose to rather integrate a --restore option to each of the destination specific commands like plugin / theme / db.

• In the destination context of plugin using --restore from [ database | csv | json ] with additional options like --activation=preserve, --version=preserve and --auto-update=preserve (see #344) will restore the attributes of all plugins as found in the --restore source.

  • Note: I assume "preserve" to be a safe special reserved word here, because I doubt it to be ever used as a value in a version, activation-status or auto-update-status.

  • Exception handling: If the --restore source is a flat list (plugin names only, space or newline separated),

    • then --version=preserve gets ignored and instead simply the newest version gets loaded,
    • and with --autoUpdateState=on|off and --activation=on|off you can set/override the respective attribute for all plugins (regardless if source contains attributes or not).

• In the destination context of database, the most additional options will accumulate over time, b/c there are so many interesting use cases. These can grows over time.

• The destination context of theme is the least complex one. Simply as only 1 theme can be active, it is already less complex than plugin I guess.

[porg]

https://github.com/danielbachhuber/dictator is not available, but I found https://danielbachhuber.com/introducing-dictator/

• As I understand it, the practical goal of this is to clone a Wordpress Site in terms of plugins and/or themes and/or configuration to a fresh site without necessarily the content data (posts, pages, categories, media, users).
• It is abandoned. Why? Are there meanwhile other established methods for this?

[danielbachhuber]

https://github.com/danielbachhuber/dictator is not available

@porg Oh! Sorry, I made it a private archive previously and forgot about it.

These folks are actively working on it: https://github.com/boxuk/dictator

As I understand it, the practical goal of this is to clone a Wordpress Site in terms of plugins and/or themes and/or configuration to a fresh site without necessarily the content data (posts, pages, categories, media, users).

Yes — and offer an abstraction for doing so, to bring the data into a YAML file that can be tracked in version control.

It is abandoned. Why? Are there meanwhile other established methods for this?

Oh, I didn't want to pursue it anymore.

[porg]

• Now you confirmed that work on dictator is continued and by whom.
• What you did not answer: Has dictator become the standard way for the forementioned practical goal?
  • Or other methods/apps/software-stacks?
  • Or is cloning/version-managing Wordpress overall still a very vivid/developing/competitive domain?
  • I'd appreciate a good link or summary on this. Thanks!

[danielbachhuber]

What you did not answer: Has dictator become the standard way for the forementioned practical goal?

• Or other methods/apps/software-stacks?
• Or is cloning/version-managing Wordpress overall still a very vivid/developing/competitive domain?
• I'd appreciate a good link or summary on this. Thanks!

I have no idea! I think this would make a great blog post 😁 Post Status might pay you for a guest contribution.

[porg]

Thanks for the info. As a relatively new arrival to the Wordpress scene (intensive research for my website from 9-12/2021, then a pause (content creation), now 12/2022 resuming website work) I may have the unbiased outside view, and see features or the lack of it, maybe differently.

But nevertheless I'm no expert at all for a serious guest contribution.

Maybe when my website is finally done, and I had some "DevOps" experience with it (with life teaching disasters along the way 😉 ) I may qualify 😂