Ability to limit push to only added content (pages, plugins, users etc), to prevent deleting elements on the remote server.

[MarkErik]

Is your feature request related to a problem? Please describe.
I deleted a page on my local machine, and then pushed to the production machine and the page was deleted on production too. (Which is to be expected, but also anxiety inducing since I might make a more serious mistake in the future)

Describe the solution you'd like
Ability to limit the push to only additions, so that nothing would be deleted from the production site.

Describe alternatives you've considered
I had tried excluding the DB in the 'forbid' section of the movefile.yml, but in that case none of the changes (pages etc.) would get pushed.

[alessandro-fazzi]

Would be correct update the title to

Ability to limit push to only added database content (pages, plugins, users etc), to prevent deleting elements on the remote server.

?

---

I've to think more about what you requested, but at a first look I think that a behavior like the one you described is not possible to be accomplished within wordmove, at least w/o wrtiting a completely new sql_adapter.
Some notes/questions:

• you say "added", but "added" since when?
• contents in the database are not simple "blocks" to move away; often a "page" is composed by relational data spread in different tables. Design a software capable to deeply interact with CMS's internal API/logic is more a matter of writing a WP plugin or a WP-CLI plugin, I can't see how to implement such integration inside wordmove.
• wordmove behaves with wordpress from a foreign point of view: the core, plugins, themes, database are all considered as files to be moved. It's really agnostic relatively to the internal logic, with the exception of the URL replacement in the database
• you mentioned "Plugins", but plugins are folders + some un-knowledgeable rows inside wp_options db table + optionally custom tables on the db. You described you problem as related to the database, but plugins deletion is not related to the database as far as I can understand
• generally speaking I've the feeling that you're trying to use a screwdriver to close bolt :) I mean: wordmove is not a publishing tool, but a deploy tool. Do you mind the difference? What's your opinion about my feeling? How am I wrong?
• Personally I never use wordmove to push contents (and with "contents" I mean the database) to production, but only to pull them when I need to reproduce content dependent bugs. Moreover I don't know about other deploy tools designed to publish specific contents. My point here is: deploy is not publishing nor seeding contents.

Thanks for sharing your ideas and thoughts 👍

[electricarts]

Personally I never use wordmove to push contents (and with "contents" I mean the database) to production, but only to pull them when I need to reproduce content dependent bugs. Moreover I don't know about other deploy tools designed to publish specific contents. My point here is: deploy is not publishing nor seeding contents.

Wait. Wordmove is not meant to be a 2-way synchronization tool?

For me it is. And that includes the "content" (i.e. the DB) of course. My workflow is usually this: I have a live page and a staging page. Updates or changes (both layout and features) are tried on the staging page. For this I synchronize the staging with the live site to have an exact copy of it. However, after successful changes, I don't want to redo this already done work on the live site. So I synchronize this state of the staging page back to the live page.

Unfortunately, this doesn't work for WooCommerce installations, for example, because I can't exclude _post and _postmeta from the sync, because that way I would overwrite orders received on the live site in the meantime. But for "normal" sites (99% of my managed sites) wordmove is an essential part of my workflow. And that includes content changes and its synchronizations.

[alessandro-fazzi]

@electricarts I see and understand. But do not twist what I meant: wordmove IS a 2-way sync tool. But MY workflow never include pushing contents to production. I work locally, push features/bugfix to the staging, where developers and customers can test them inserting contents in order to do a functional review. Then only the code is published in production and contents are instead always re-inserted ex-novo.

This is what I prefer in 90% of scenarios; the bigger exception being all the work done before the first public release.

I work this way mainly for three reasons:

• I don't trust wordpress architecture where data and code are often tight together
• I want to be free to alter data on my stagings - and I never have a remote testing environment + a proper staging environment
• customers always independently update the production and I don't wanna be the master of the syncronization magic :P

Instead I often pull DB from prod to staging and from staging to local in order to reproduce bugs.

That said: wordmove is and will absolutely a 2-way tool and I never meant to invalidate such assumption. Just saying my personal approach is to use wordmove as a deploy tool and personally I consider deploying as deploying the code, thus a separate thing from publishing contents.

Consider my work doesn't include copywriting, too. So publishing content is not my business.

---

About

Unfortunately, this doesn't work for WooCommerce installations, for example, because I can't exclude _post and _postmeta from the sync, because that way I would overwrite orders received on the live site in the meantime.

consider this should (I use a conditional because I haven't tested yet, but it's my design pourpose) be possible with wordmove 6.0 configuring wp-cli.yml something like

db export:
  exclude_tables: prefix_posts,prefix_postmeta

NOTE: since not sync-ed they neither will be backup-ed

And probably you should be able to achieve it even with current stable excluding the tables through mysqldump_options.

[electricarts]

consider this should (I use a conditional because I haven't tested yet, but it's my design pourpose) be possible with wordmove 6.0 configuring wp-cli.yml something like

db export:
exclude_tables: prefix_posts,prefix_postmeta

That was my mistake. I did not express myself clearly and my English is quite lousy. 😜

In wordmove I can of course exclude tables from synchronization. But in case of WooCommerce I would have to exclude posts and postmeta completely, because unfortunately Woo stores the orders in there. And not in a separate table as it would surely make more sense. And if I exclude posts and postmeta, I'm missing the entire content. So this is a WordPress/WooCommerce problem and definitely not wordmove related.