Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By westsyde on
I am fairly new to Drupal however it is clear to me that Drupal is a superior CMS.
The issue I have is that I can not find the information I require to clarify and resolve the following:
1. When I upgrade my database (from lets say) test to production, I can not import the database without first dropping the existing database which means that even if I set my site to offline mode during the maintenance period I lose my sites offline page due to the fact that the nodes are removed by dropping the tables/database.
I imagine that there is some way to merge the database files so that the site stays online.
2. I could always redirect my production domain to a maintenance directory with a site running in full time maintenance mode however this will still mean that I will loose my site for a period of time however a can not display page in my view looks better that one with *.sql errors (LOL).
I am confident that option two is not required during transfer/upgrade of the *.sql’s.
Any suggestions regarding option 1 will be much appreciated.
Comments
Following
Following
Why not just manually insert
Why not just manually insert the database name/username/password/localhost information for the existing (test) database into the settings.php file for the new (production) site? Or am I misunderstanding what you mean (always a good possibility)?
----------------------------------------------------------------------
http://classicvinyl.biz
http://music.bwv810.com
http://association.drupal.org/user/1207
Sounds like an option
That sounds like an option bwv.
I believe your right, that would resolve the site going offline and elimiante the maintenance site I mentioned.
Is this way suggested by Drupal / mySQL etc anywhere ??
Are there any other alternative options or is this the best approach when using PHP database driven sites.
Forgive my ignorance.... ;-)
One other thing
In following the suggestion above, as apposed to merging the databases, I would need to set the production site to offline, back up database(s), then import it for use with the test site, add any changes (previously tested) and then by modifying the setting.php make the live (offline) transfer.
Otherwise I would lose any comments (nodes) etc made during the testing process, which could take hours, days to redo.
If you could simply merge (copy) one database over the other one would think that you could update content to your test site which would eliminate doing such during the time that your production site is set to offline for maintenance mode.
My aim is to have as little downtime as possible.
I think you need to accept
I think you need to accept the fact that there will be downtime, and communicate this to your users/visitors in advance so they are not surprised when your site is down. In the past I have put up a notice in a block a few days or a week before an event (transfering a site to another server,for example).
I would not attempt to merge databases. I would simply use the one with the latest information, and make my alterations to it.
----------------------------------------------------------------------
http://classicvinyl.biz
http://music.bwv810.com
http://association.drupal.org/user/1207
Tried suggestion
I tried your suggestion (bwv) regarding the changes to the setting.php however for some reason my server won't allow the changes.
I altered the database mysql://username:password@localhost/databasename'; and the prefix_ from the production site settings.php to the test site and saved changes. I also tried downloading the setting.php, altered it and uploaded, only to find that it reverts back to the previous settings.
What am I am missing here. Not sure what I am doing wrong but there must be something.
Perhaps it is my host. Or it may be a mySQL communication isssue as the database would be driving two sites for a short period, until the test site database is replaced with a new database of its own.
Should I break the connection between the test site and test database prior to upgrading the production sites settings.php to the test database settings.
Any further suggestions?? Thanks.
=-=
permissions on the file need to be 777 or 755
sometimes I've found it necessary to also have to alter the permissions on the default folder to 777 or 755
I've also found it is better to change this from the host panel file manager rather than from a FTP tool as the changes with a FTP tool may not take.
ensure to note what the permissions are before you change, so that you can change them back.
Getting somewhere now
I have tested the suggestions and I have found that the folder permissions by default is 755 which works fine.
Initially I found this set to 555 but tested other installations to discover it should be set to 755 not 555.
The settings.php however should be set to 444 by default.
For some reason this changes to 644 after uploading the file with updated settings.
Therefore you should set the permissions on the settings.php from 644 back to 444 once uploaded.
Perhaps someone knows why the permission changes and would like to explain.
System of naming of sql files etc
I have come to the conclusion that my old site directory naming and database layout will not be easy to work with using this awesome system to carry out php / mySQL site upgrades.
I have a series of production and test sites and I will continue with this to allow for testing the various versions and modules etc however instead of prefixing the databases after the site directories such as Tv5 which is an acronym for testing version 5. The production I named v5. I named them like this as I thought I needed to overright the database and not the settings.php
I will now prefix the databases after the major drupal version, followed by using a consequtive number for each database update understaken. Therefore the *.sql for Drupal version 5, database upgrade # 127 would be 5127_
I could be wrong but I believe that drupal version 5 allows four digits prefixes, where I understand that drupal 6 allows 6.
In any case I would image that by the time I do 999 database upgrades I would be upgrading to the next major version of drupal, whereby my database prefix numbering would start again with 61 for version 6, database # 1.
Hope this helps someone else to short cut their way to this basic understanding.
How have you done it?
Wondering how to do this, best practice. I am in process of developing a test/prod. environment.
1. The test server is on the same machine, e.g., test.example.com or is it on another machine/server altogether. I mean at DIWD it was suggested to use another test server altogether. Are there any problems with testing it on same machine with test.example.com?
2. So finally you could resolve it by making changes in settings file and pointing to the new database, right?
Thanks,
RKC