-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move specific DB tables (supporting wildcard names) #468
Comments
Following your last answer on #442 (and to follow this thread 😃) : yet simpler if |
Yep, simpler, but less powerful: if I'd be developing a plugin with a prefix like |
Happy Issue Anniversary! Did this happen? |
I can't assure when the feature will be implemented (it also has a blocker), but I can assure that when it will this issue will be updated. |
If I am reading this correctly, it would allow to exclude the users from a DB push / pull operation? |
Hey @MarkErik the feature is a different one actually. But the one you’re talking about already exists; please search for “forbid” in the documentation 😉 |
Dear @pioneerskies, my apologies, I might not have clearly commented what I was hoping for and perhaps for missing something in the documentation. In my comment: "exclude the users from a DB push / pull operation" what I was hoping to say was that the registered WordPress users could be excluded from Push / Pull operations. I had also opened a feature request expanding on this so that pages / posts / users etc could be selectively excluded from push / pull operations. Note, I had tried the forbid command: And as a test I registered a new WordPress user, and created a page locally, and as expected when I pushed, neither showed up on the production site. My goal is that I can create new pages (perhaps with new plugins) locally and push them to the production server, and in most situations for safety prevent the accidental deletion of elements that I am not working with. |
@MarkErik you could try to exclude your |
@pioneerskies Thank you for that suggestion, I will give it a try. Feel free to remove my earlier comments if you'd like to keep the original feature discussion cleaner :) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hello,
now that we have slowly moved along the way and we have declared
wp-cli
as a dependency, we have possibility to afford this feature in a secure, standard way.I'm thinking about solving 2 different problems here:
The config inside
movefile.yml
would look likeor
or a mix
The implementation would rely on
wp db tables
command; slow (wp-cli
is slow to load) but rock solid. I'd cycle over the array of stringstables
and construct a string from the output ofintercepting the use of the wildcard and passing thus to
wp-cli
; or simply appending 'wp_posts' because no wildcard is used.The resulting
mysqldump
command would be, e.g.:Tables would be specified for each environment (local and/or remote) based on the desired behaviour. Opening to scenarios where I can pull only
wp_posts
from production, butwp_users
andwp_posts
from staging.Note:
The text was updated successfully, but these errors were encountered: