Databases, fields, field values, and development - migrating structure/schema

[etling]

I'm not sure how to even phrase this question, I think I need to learn more specific vocabulary to even ask it. But here goes:

With a Processwire site, how does one deal with synchronizing data between a local development database and a live production database?

Specifically, the following scenario. Let's say I'm developing a site for a small business client:

• I develop the site locally, and eventually deploy it to a server
• The client starts using the CMS, and entering data which is saved in the production database
• The client requests a new feature -- let's say it requires adding a few fields to an existing template
• I add the fields to the template on my local development machine
• Now how do I get those changes to the live site, without overwriting the data the client has already entered?

The way I am currently handling this is as follows:

• I ask the client to stay out of the admin area and stop making changes
• I dump the production database, and import it to the local dev database
• I make the changes to the fields / templates
• I dump the dev database, and import it to the production database

Is there a better, more efficient way? Are there specific database tables that define the "idea" of fields and templates, but not their content? In the Rails world, this sort of task would be a "rake db:migrate".

One solution, I guess, would just be to connect my local dev site to the live production database once a site is live. But I prefer to be able to work offline if needed, and sometimes I'm dealing with shared hosting services that have limited or unreliable external database access.

Forgive me if this is covered elsewhere, or already has a well-documented and obvious solution. I would love to hear any thoughts or suggestions.

[horst]

Hi Etling,

actually there is no prefered way to do this. Here is a module that may help: https://processwire.com/talk/topic/4420-page-list-migrator/

I haven't used it until now but have bookmarked it for the future. Adrian states it still alpha, but has done a lot of work to it allready. So more than worth a look.

[WillyC]

Are there specific database tables that define the "idea" of fields and templates, but not their content? 

underlines them for u i did

[adrian]

To clarify what WillyC is saying - there are DB tables that store the settings for template and fields. If you fire up something like PHPMyAdmin you should get the idea.

The Page Tree Migrator (PTM) module that horst linked to is still in alpha, although I hope not for much longer. I just pushed a new update literally a couple of minutes ago that deals with some bugs that were introduced with a major new feature in the last version.

I think PTMis very powerful and is a huge time saver when it comes to migrating fields, templates, and trees of new pages and their content. It should be able to solve your issue if you choose the correct settings (I have gone a little nuts on this?). It should allow you to export the new template structure (with the newly added fields) from your dev site and import them to the live site.

The one thing I need to get this out of alpha is testers, but please do your testing first on two test PW installs. If it works as expected for your given scenario, then you should be good to use it on the live site.

[horst]

@WillyC: does that mean one can, for example, create a new field, add it to the basic_page template and only need to update the tables fields and templates and add the new table field_myNewField to the live server?

[mrjasongorman]

Great Topic, i come across this problem all the time. Wouldn't be such a big problem if ID's were truly unique.

With ID's are being auto incremented separately (on development, and in production) it makes it hard to merge the two DB's without conflict.

I tend to just make a note of fields / templates added and then go through the process manually on live. Bit of a pain.