I think my site may be too complex for this plugin. From what I can tell, it seems to work on sites w/ little customization (as it isn’t working for my site at all). Is this the case?
Hi Apokalupsis,
The Duplicator does work with complex sites, however it doesn’t support sites where theme authors store their data in tables other than the wp_options table. The reason being is that it’s impossible to know the format of non-core WordPress tables. So the plugin does not attempt to replace data on 3rd party tables.
If a theme authors write their sites to the WordPress options table which is a standard place for storage, then the duplicator will attempt to replace that data.
Hopefully in the future we’ll try to write support for 3rd Party tables with some type of wizard move through option.
What happens when the scenarios is this:
1) I install duplicator plugin on production.
2) I pull it down to my local server to MAMP PRO.
3) I redesign downloaded site on local machine – changing its theme, style, and by adding plugins, widgets, etc.
4) However, as I develop locally, users on production site are uploading new content till the day we plan to launch the new website, which is January 1, 2012.
When I upload my locally design site to production server, it won’t have the latest data.
What is the best approach to make this work?
Will duplicator be a solution for this scenario?
Hey klikwebdesign,
The short answer:
Not really!
The long answer:
The merging of data from one database to another usually always requires some type of manual intervention. Because Databases don’t really have the concept of branching and merging (at least in smaller to medium size systems in which we develop) it usually is done manually.
Here is the approach I have taken for myself and customers and it has worked well for me.
1. I only do a Duplicator PUSH to production when the site is brand new and I have been developing locally. I don’t have to worry about any content, because its a new site.
2. Once a site goes live I only use the Duplicator to PULL from production to sync up my development box with the latest content. This is only done when I know the Production and Development lines are both in sync, and I want representative data from production.
3. All development efforts in-between a PULL from production are made in an Agile method of project by project where the scope of most changes are a few pages and images that are FTPed up and possibly some changes in the the WP-Admin which reflect setting up new widgets etc… downtime is very minimal if at all any…
4. If I’m working on what I know will be a large set of changes then I usually will use a diff tool to compare production and development, and keep track on the widget, plugin changes in a project plan. This usually has to be a really big big project, and if possible I try to get the client to push smaller more agile sections of the site.
5. Overall I use the Duplicator to do PULLS pretty often and PUSHES only on new setups. In order for the Duplicator to support PUSHES it would need a mechanism for allowing users to accept what changes they want and then only perform those items. It would be a good idea for a commercial product thought…
Hope that helps!
Thank you very much lifeinthegrid. It’s very helpful to know. Great information!
