Report on my experience with Duplicator

  • Resolved Angelina Belle

    (@angelina-belle)


    10 years, 1 month ago

    I think this is a great utility. As I am new to wordpress, I was a little bit unsure where to look for all the settings I would need to change to get the clone looking to its own files, and a bit worried at the warnings on the wordpress site about changing values in the database.

    I think this duplication went fine, though a small number of puzzling things happened.
    I was working in a Linux shared hosting account at ixwebhosting.com.

    1)

    Install Report Errors: Deploy (381) Update (0) Warnings: (0)

    . The install-log.txt file existed by was empty. Odd.

    2) All the tables made it across to the new database, including the ones I had checked off NOT to include in the package.

    3) There were 189 rows missing from _options, including 3 with duplicator settings, and 186 wit option_name like ‘_transient%’ or ‘_site_transient%’. Are these filtered out on purpose?

    4) _duplicator_packages made it as well, but was empty (one row missing).

    5) A suggestion — make it easy for the user to change the wordperfect prefix. When I have cloned SMF forum installations, I used to do this with global-search-and-replace on the SQL dump of my database. It can be convenient for users who cannot create an unlimited number of databases to co-mingle a couple of transient test versions of wordpress in a single database.

    Thanks for providing a tool that worked so well.
    I hope you can fix the confusion that caused the 381 error messages to go missing. I have not found anything wrong with the cloned website so far.

    https://wordpress.org/plugins/duplicator/

Viewing 6 replies - 1 through 6 (of 6 total)
  • Cory Lamle

    (@corylamleorg)

    10 years, 1 month ago

    Hey Angelina,

    I’ll try to answer each question here:

    1. If the install-log.txt file was empty then that means the PHP process probably didn’t have access to write to it, which is a bit strange because the process was able to create it. I’m not 100% sure on this but it might be permission related

    2. Did you use the mysqldump option or the PHP option? Both should have filtered the tables if the ‘enabled filters’ checkbox on the database tab was checked.

    3. Transient data in WordPress is cached data. This data is removed on purpose to avoid any caching issues when the data is migrated.

    4. This is desired behavior as the package files on the orginal host are ignored to keep the package size smaller, so all items in the new DB are removed.

    5. This is on the todo list, but since I’m currently the only developer it may take some time to get to…

    Cheers~

    Thread Starter Angelina Belle

    (@angelina-belle)

    10 years, 1 month ago

    Thanks for your extremely prompt answers.
    1) Yes. I thought that was strange, too. It is unfortunate I cleaned up the files already. Nothing to see = nothing to fix.
    I’ll just mark this as resolved, since there is not really anything you can do about it without information, and if I see the same behavior again I’ll start a new topic.

    2) I did not use mysqldump. Didn’t seem worth the bother for a small test install. Didn’t realize that was a dependency. Perhaps I should clean my glasses.

    3,4 ) Makes sense. 189 * 2 is close to 381, so I was grasping at straws.

    5) Nice to know that is on the to-do list. And I understand about the resource issue. I can GSAR database.sql myself.

    …. and looking through the SQL, I see a couple like:
    CREATE ALGORITHM=UNDEFINED DEFINER=old_database_name@localhost SQL SECURITY DEFINER VIEW view_name blah blah blah;

    I think this will always fail. Either the logged-in user has no access to old_database@localhost, or else it does, but the view already exists. That might account for 2 of the missing errors.
    No, I didn’t test it in phpmysql. Overall, I guess it worked. I’ll keep a cleaner database in the future, and not be so quick to clean up files if I run into any problems when I take one of these test instances live.

    Cory Lamle

    (@corylamleorg)

    10 years, 1 month ago

    Sounds good! Thanks for the update.

    Thread Starter Angelina Belle

    (@angelina-belle)

    10 years, 1 month ago

    I tried again, this time on another host.
    2) I used the mysqldump option, and I also noticed that checking table names does not force a check in the “filter” box, which probably explains why I didn’t get filtering last time.

    —–
    I also discovered that if you GSAR the table prefix in the .sql file and in wp-config, it still won’t work. therer is an error message involving <old prefix>_blogs, which I cannot account for. I didn’t know where else to look. so I just downloaded the package again and have decided to live with wptest_

    Cory Lamle

    (@corylamleorg)

    10 years, 1 month ago

    Hey Angelina,

    Here is an article that might help out:
    http://www.wpbeginner.com/wp-tutorials/how-to-change-the-wordpress-database-prefix-to-improve-security/

    Cheers~

    Thread Starter Angelina Belle

    (@angelina-belle)

    10 years ago

    I’ll consider it! Thanks!

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Report on my experience with Duplicator’ is closed to new replies.