• Resolved abitofmind

    (@abitofmind)


    Hi,

    I have studied your documentation intensively, and found no explicit answer, could only speculate. I’d love to get an answer on this, before further considering it.

    Scenario:
    Production: Export everything.
    Staging: Import everything. Various experiments.
    Production: New posts + new comments keep coming in.
    Staging: Export with DB table exclusions. Effectively only exporting “wp_options” which has all the theme config & customization stuff.

    My question:
    When putting installer.php and archive.zip into the root of the wp-directory of the production installation (not a blank one as with a migration!) and then calling /installer.php in the browser, how does Duplicator proceed with the option “overwrite existing DB”:
    1) Clears only those tables which where included in the archive and spares the other tables (wp_posts and wp_comments which have accumulated new content meanwhile).
    2) Clear all tables from the DB, then refill it with the tables it finds in the archive.

    If it is #2, then I would need to block comments and new posts on the production server (frozen read only server) while the development on the staging server, or else loose this later. And need to include all tables both when migration from production to staging and again when pushing staging back to production again.

    If it is #1, then this would be quite a suitable plugin for staging purposes for me. You could do theme/plugin/configuration changes but no content changes on the staging server, accumulate new content on the production server, and then carry over the staging changes to production.

    I’d appreciate if I get an answer to this. Thanks!

    The page I need help with: [log in to see the link]

Viewing 5 replies - 1 through 5 (of 5 total)
  • Hey @abitofmind,

    At the moment the plugin only supports the #2 scenario.

    Let me know if you have any other questions~

    Thread Starter abitofmind

    (@abitofmind)

    @corylamleorg thanks for confirming.

    The name alone “Duplicator – WordPress Migration Plugin” already indicates just this. Just wanted to be sure.

    So for a continuous integration of production->staging->production one better consults other more suited solutions like https://wp-staging.com or https://wpstagecoach.com

    And for moving once between webhosts, or for all-inclusive WP server setup cloning or for staging rudimentally your plugin is the right tool then.

    Hey @abitofmind,

    In the Pro product, we are working to enhance developers’ workflows to more easily accommodate these scenarios. I have not used the staging solutions you mention directly so I wouldn’t be able to comment on them. This article might be of use to you if you plan to use our plugin in some of your workflows.

    https://snapcreek.com/blog/wordpress/techniques/create-wordpress-staging-site/

    Hope this helps~

    Thread Starter abitofmind

    (@abitofmind)

    My scenario “Content-freeze on production > Staging, do experiments > Back to production” is now semi-automatized enough for me and my little portfolio website, with the help of Duplicator.

    1) The option to disable plugins during the installer.php process is great!

    On my staging server I have https://www.ads-software.com/plugins/jonradio-private-site/ set to active and hence what I try out there is only visible to logged-in users. No spiders and visitors see my potentially embarrassing experiments.

    When I push it to production via Duplicator I choose to deactivate onradio-private-site and this in effect makes the site public immediately (avoids an additional downtime of 1-2 mins for logging in, going to plugins, deactivating it, logging out, checking as anonymous).

    2) One thing which Duplicator could improve during the re-installation downtime:
    While the installer runs through step 3 of 4 “Update Data” and an anonymous user visits your website, they get redirected to /wp-admin/setup-config.php

    Effectively they cannot do anything, as proceeding opens a screen where you need to tell the database name/username/password.

    But nevertheless. This feels “too much door open” for my taste.

    Proposal: Duplicator’s first step within 1 of 4 deployment (of the files) should be to position a custom maintenance index.php and .htaccess which simply shows a minimal “Site in maintenance very shortly, back up in a few minutes.” which get’s removed after the database update step with the real index.php and .htaccess, to be ready for step 4 (cleanup and login of admin).

    3) One last thing for my semi-automatic workflow: Maybe I find a plugin which pauses content-creation and commenting when it’s on. Then I simply only need to turn this on. Then migrate to staging. Do my experiments. And when pushing back to production simply choose to de-activate the plugin and in effect allow fresh content creation and commenting again. I’ll update this thread here if I find a suitable solution for this.

    • This reply was modified 3 years, 4 months ago by abitofmind.
    • This reply was modified 3 years, 4 months ago by abitofmind.

    Thanks for the feedback!

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Import: Is table left intact when corresponding table was excluded while export?’ is closed to new replies.