Dev to Live

[Thor]

So I just cloned my testing PW installation to a second live server to keep things clean after a few days of testing PW (yes, I'm convinced with the software )

So I can properly test and code in the development environment.

But I was wondering since PW stores everything into the database (pages, fields, others). Besides transferring or merging the database is there something else I should take into account when I need to move changes from staging to production?

I will just sync/merge the database so all the fields and data appear on the live site after I make some changes. Or are there specific things that PW will write or save to the disk regarding config that I should also be aware?

When I mean transferring, I only refer to the /site folder and MySQL database. Not the wire folder which I will never touch as instructed on the documentation except for upgrades.

To resume, if I transfer the site folder, and database, all the new fields, settings, and changes should appear on the live site correct?

[bernhard]

hi thor,

if you copy over your files and database you will have an exact copy. only thing you would maybe have to change is the settings in /site/config.php (database settings, if you have different ones at dev and live).

the only problem would be that you overwrite the data of the live website's database. for example if you had some user input while developing on your dev and then you upload your dev-db to your live-db you would lose this data. that's been discussed several times before (because it can be a littly tricky). see 

or migrations module:

https://modules.processwire.com/modules/migrations/

https://processwire.com/blog/posts/introduction-migrations-module/

[Thor]

Yeah, I forgot the config file, you are right, I will take a note as the dev has different settings and logins of course.

So basically that means having a live copy? Sounds great! 

I actually did this just an hour ago, and indeed, my other site is an exact copy. But it's just a few pages and test data, so it was not a problem.

Now with live data in the future. I don't think that would be a big problem unless you let users create tables and fields on your live site. Let me explain why (and please correct me if I'm wrong).

Unless you change fields name by renaming them which you created before, which is not something people usually (and PW even warns about that regarding data loss) from the short time I tested the software it seems it creates a new ID and tables for everything. So it's very unlikely you will end up with the same ID for a new field, page, user, etc.

If you just copy the dev DB to the live DB then, of course, that would overwrite everything, including your production data but that is not how I would do it.

I would compare the DB and tables and just merge the differences (the dev would usually have the new stuff but no data). And differences would just be the new fields, pages, etc. which don't exist yet on the live DB, so there would be no data there to overwrite there. Maybe I'm wrong, but PW creates a new table for fields, so those will not exist in the live site yet.

Now, if you let users create pages and other things, then you are probably right, and I see how that can create a conflict. In that case, maybe you can do the opposite before starting developing. Copy the production BD over to the Dev DB so you have a similar match.

Personally, I never did that because I'm always afraid of using real users data with testing sites, in case it emails them something for example while I'm testing to a real customer with a real email. So usually I just use dummy data on my dev installations.

This is what I use for databases in case someone is wondering:

http://sqlyogkb.webyog.com/category/290-database-synchronization

 

Edited May 20, 2017 by Thor
Typo

[bernhard]

you can just create a config-dev.php on your dev and pw will use this one (only if it is present, so you just have to make sure it does not get uploaded to your live site).

interesting link. I'm thinking about this topic for quite some time and came up with this approach: 

but i think the most solid approach is to use the api (like the migrations module does or like i showed in the last posting).

would be interested in your experiences though

 

[szabesz]

2 hours ago, Thor said:

in case it emails them something for example while I'm testing to a real customer with a real email.

I recommend: https://processwire.com/blog/posts/introducing-tracy-debugger/#mail-interceptor-panel

When Adrian is back, we should ask him to add a setting which makes it possible to always intercept emails in DEVELOPMENT mode of the module, so that we do not forget to set it.

[Thor]

16 hours ago, szabesz said:

I recommend: https://processwire.com/blog/posts/introducing-tracy-debugger/#mail-interceptor-panel

When Adrian is back, we should ask him to add a setting which makes it possible to always intercept emails in DEVELOPMENT mode of the module, so that we do not forget to set it.

Sounds good. So a better proposal is to just use live data for developing and stop emails out?

I guess that could work, then before doing some dev, you just copy your production DB to the dev first, so you have an environment as close as possible. Make all your dev, and then merge changes back. That would keep the changes to merge and apply from dev to production to a minimal.

Also instead of intercepting emails, another way would be just to alter the email formats on the sync/transfer process. Example changing all emails from account@example.com to account-example.com or similar. That would make all emails out as invalid as well or better, replace all of them with an all catch in the address in your domain like changing account@example.com to account-example.com@yourdomain.com

I think that approach would be better just to be sure because the module you mentioned is only for emails using the WireMail function. So if you have PHP code that does its own email sending, or any other form or system sending emails mixed up or made up on PW templates, that module would not work.

[szabesz]

I always clone a site form production to my local dev machine, I follow the simple workflow of syncing files AND cloning the database of the production site to my Mac.

To clone the db I use this in a simple Bash script including the following:

printf "Trying to drop all the tables of the Target database called $DB_TARGET_NAME \n"
mysqldump -u $DB_TARGET_USER -p$DB_TARGET_PASS --add-drop-table --no-data $DB_TARGET_NAME | grep ^DROP | mysql -u $DB_TARGET_USER -p$DB_TARGET_PASS $DB_TARGET_NAME

printf "Trying to download+import the database...\n"
mysql -u $DB_TARGET_USER -p$DB_TARGET_PASS $DB_TARGET_NAME < <(sshpass -e ssh $SSH_ARGS "set -e; mysqldump -P 3306 -h $DB_SOURCE_SERVER -u $DB_SOURCE_USER -p$DB_SOURCE_PASS $DB_SOURCE_NAME | gzip -cf" | gzip -cd)

So I drop all the tables of the target DB first, then import the production DB via SSH as seen above. I have a keyboard shortcut to launch the script, so that I can get the production db in a matter of seconds in the case of not gigantic databases. (Which I do not have currently...)