I am planning to go from 5.1 to 5.2. Do I really have to take the site off-line?
I am having a major problem synching with local site. The server time stamp seems to be totally off. Both Transmit and Dreamweaver8 tries to download a bunch of files those which are known to be already synched, while both of them are missing more important files such as modules. Is there any better option for OSX10.4?
I spent entire day to delete a few thousands duplicated images. This has been a nightmare.
I do have a stage directory on the server but synching with the live directory seems to be almost impossible so I have abandoned it. My ISP only gives FTP access but not Terminal access. Any suggestion on good upgrade practice other than one is documented on Drupal.org, the one to take site off-line, would be very much appreciated.
Yes take the site of line, primarily meaning to use the drupal admin menu to put it into maintenance mode. They didn't mean actually shutting down apache or anything, but rather naviging to the Site Configuration and taking the site of line. You should see a link that looks like this on the administration menu.
Site maintenance Take the site off-line for maintenance or bring it back online.
As for the FTP client. I tend to upgrade locally prior to upgrading remotely on my MAC. Sometimes the database export is a little askew, but things generally work pretty much the same as on my hosting provider which also only provides FTP access.
I use Cyberduck on my Mac to ftp synchronization. Don't know if it will work better with your servers timestamp off, but it's worth a try.
Steps I use for staging: 1. Using phpMyAdmin backup download a local copy of the database. 2. Import that database to mysql on my Mac. 3. Copy all the files to my local box using ftp 4. Reconfigure settings.php to wrok locally. 5. Check the site out so I know if there are database encoding issues that aren't related to the upgrade.... Ignore these if nessecary. 6. Do the upgrade locally and make sure everything works.
When I'm ready to do Production. 1. Take the site offline using the drupal menu I described. 2. Backup the mysql database again using phpMyAdmin 3. Use the Cpanel file administrator on my site to make a pre-upgrade backup copy of my site. (this could probably be done via FTP as well.) 4. Upload ALL of the locally unpacked upgrade files for drupal5.2 core to production. 5. Run the update.php script. 6. Check the site out again. 7. Put the site back online using the menu I described.
It ain't perfect but it works pretty well in a remote hosted environment. If something goes bad. You have the copy to revert back to, and you have the database backup to restore from.
Dave -----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of A-NO-NE Music Sent: Thursday, August 23, 2007 2:20 PM To: Drupal Support Subject: [support] Planning upgrade
I am planning to go from 5.1 to 5.2. Do I really have to take the site off-line?
I am having a major problem synching with local site. The server time stamp seems to be totally off. Both Transmit and Dreamweaver8 tries to download a bunch of files those which are known to be already synched, while both of them are missing more important files such as modules. Is there any better option for OSX10.4?
I spent entire day to delete a few thousands duplicated images. This has been a nightmare.
I do have a stage directory on the server but synching with the live directory seems to be almost impossible so I have abandoned it. My ISP only gives FTP access but not Terminal access. Any suggestion on good upgrade practice other than one is documented on Drupal.org, the one to take site off-line, would be very much appreciated.
Metzler, David / 2007/08/23 / 07:51 PM wrote:
Yes take the site of line, primarily meaning to use the drupal admin menu to put it into maintenance mode. They didn't mean actually shutting down apache or anything, but rather naviging to the Site Configuration and taking the site of line. You should see a link that looks like this on the administration menu.
Yes, I know. In fact I already made a custom page to replace Drupal "off-line" page but I still do not wish to take it off-line. I get access from US, Europe and Japan so I don't really have any widow to take it off-line.
I use Cyberduck on my Mac to ftp synchronization.
Nice thing about Transmit is that it has emulation mode to run Synch before action to make sure which files will be updated. This is where I see thousands of legit files being replaced.
Steps I use for staging:
Appreciate this very much.
- Check the site out so I know if there are database encoding issues
that aren't related to the upgrade.... Ignore these if nessecary.
Not sure if I understand this. What is the db encoding issues related to the upgrade?
- Do the upgrade locally and make sure everything works.
This is where I get stuck. The documentation sez move entire directory to backup directory, install 5.2 as if it is the initial install then copy necessary files back from the backup directory. My fear is I don't think I know all the necessary files to be copied. I don't remember all the custom files and hacked module files, and the date stamp, which could had been the only clue, isn't reliable at this point.
- Check the site out so I know if there are database encoding issues
that aren't related to the upgrade.... Ignore these if nessecary.
Not sure if I understand this. What is the db encoding issues related
to the upgrade?
No there aren't typically database issues associated with the upgrade, but rather with the dump from one verion of mysql (on the server) to another (on my mac). Some characters don't come across cleanly. I really haven't spent any time trying to research this cause frankly it doesn't matter to me. I just check the site out to make sure I know what problems are caused by the upgrades and what problems arent.
- Do the upgrade locally and make sure everything works.
This is where I get stuck. The documentation sez move entire directory to backup directory, install 5.2 as if it is the initial install then copy necessary files back from the backup directory. My fear is I don't think I know all the necessary files to be copied. I don't remember all the custom files and hacked module files, and the date stamp, which could had been the only clue, isn't reliable at this point.
-- Yeah I don't do that. I normally copy the files in 5.1 to make a backup, and then copy the unpacked 5.2 files over the top of the existing 5.1 install, letting it overwrite duplicates. I copy them all, and don't use a sync function for this. I never hack core so this is safe for me, and I've never had a problem yet. I suppose if a file ever got deleted in a .x upgrade this might cause me a problem, but it has yet to happen. I use a different strategy for doing something like a 5-6 upgrade. I agree with you that trying to remember all of the custom files would probably cause more problems than my current strategy.
Quoting A-NO-NE Music madflute@anonemusic.com:
I am planning to go from 5.1 to 5.2. Do I really have to take the site off-line?
For an upgrade to production it is advisable to put the site off line for a few minutes. It is up to you as to whether or not you wish to deal with the fallout or not.
I am having a major problem synching with local site. The server time stamp seems to be totally off. Both Transmit and Dreamweaver8 tries to download a bunch of files those which are known to be already synched, while both of them are missing more important files such as modules. Is there any better option for OSX10.4?
I would suggest a network time protocol daemon for both hosts. For the database you may wish to look at the importexportapi module or maybe the excellent dba module. For the file system you might look at unix standards such as rsync.
I spent entire day to delete a few thousands duplicated images. This has been a nightmare.
It's tough to realize that you've stabbed your own self.
I do have a stage directory on the server but synching with the live directory seems to be almost impossible so I have abandoned it. My ISP only gives FTP access but not Terminal access. Any suggestion on good upgrade practice other than one is documented on Drupal.org, the one to take site off-line, would be very much appreciated.
Have you considered using tar?
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie Boyd / 2007/08/24 / 08:25 AM wrote:
For an upgrade to production it is advisable to put the site off line for a few minutes.
Ha-ha. I don't see how this can be done in a few minutes. Thank you for your response, however. You are very helpful and I always save your comments.
I would suggest a network time protocol daemon for both hosts.
I am sorry, but I don't understand what you are suggesting.
For the database you may wish to look at the importexportapi module or maybe the excellent dba module.
I don't have database backup issue. Copying database between the live and the staging within the live server is pretty easy. I do this all the time.
For the file system you might look at unix standards such as rsync.
I thought rsync also look at the time stamp, no? I have got ChronoSync which is a pretty good application, but turns useless when time stamp is messed up.
It's tough to realize that you've stabbed your own self.
The problems is I don't know how I stabbed myself.
Have you considered using tar?
Do you mean uploading tar file? Do I not loose the "Site-Offline" page as soon as I expand the directory to overwrite the live directory until I manually rewrite the settings.php?
By the way, there is one inc file I modified but I can't remember which one. Without proper time stamp, this is bad. I was wondering if anyone knows a good def GUI app runs on OSX10.4. I actually don't know a proper keyword to google this.
On 8/25/07, A-NO-NE Music madflute@anonemusic.com wrote:
Earnie Boyd / 2007/08/24 / 08:25 AM wrote:
For an upgrade to production it is advisable to put the site off line for a few minutes.
Ha-ha. I don't see how this can be done in a few minutes. Thank you for your response, however. You are very helpful and I always save your comments.
There may be ways. If it is not a community site continuously updated by the users, you could upgrade a copy in a subdomain, using a different database, and take the site off-line as long as it takes to move the files and to load the updated database.
I would suggest a network time protocol daemon for both hosts.
I am sorry, but I don't understand what you are suggesting.
For the database you may wish to look at the importexportapi module or maybe the excellent dba module.
I don't have database backup issue. Copying database between the live and the staging within the live server is pretty easy. I do this all the time.
For the file system you might look at unix standards such as rsync.
I thought rsync also look at the time stamp, no? I have got ChronoSync which is a pretty good application, but turns useless when time stamp is messed up.
It's tough to realize that you've stabbed your own self.
The problems is I don't know how I stabbed myself.
This was probably about modifying core files.
Have you considered using tar?
Do you mean uploading tar file? Do I not loose the "Site-Offline" page as soon as I expand the directory to overwrite the live directory until I manually rewrite the settings.php?
By the way, there is one inc file I modified but I can't remember which one. Without proper time stamp, this is bad. I was wondering if anyone knows a good def GUI app runs on OSX10.4. I actually don't know a proper keyword to google this.
Perhaps if you remember why you modified it, it would help finding which one you modified (or whether it matters now).
--
- Hiro
Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com
-- [ Drupal support list | http://lists.drupal.org/ ]
By the way, in the release announcements of image module v. 1.4 and 1.5 there is a strong warning about taking the site off-line and not accessing any images until update.php has been run.
Cog Rusty / 2007/08/25 / 09:29 AM wrote:
Perhaps if you remember why you modified it, it would help finding which one you modified (or whether it matters now).
It was a patch required by a module, which I don't remember what module that was. The patch didn't run so I had to hack manually. Anyway, lesson learned.
I need to go over Earnie's response to think hard for re-planning.
I always find it a good idea that if I absolutely must patch or manually modify a contrib module, to first copy the original to something like modulename.module.orig so that I can easily find which module(s) have been modified, and can do a diff to see exactly what those changes were at a later date (such as upgrading the module, etc..). Just a little tip, hopefully it helps you out in the future.
William
On 8/25/07, A-NO-NE Music madflute@anonemusic.com wrote:
Cog Rusty / 2007/08/25 / 09:29 AM wrote:
Perhaps if you remember why you modified it, it would help finding which one you modified (or whether it matters now).
It was a patch required by a module, which I don't remember what module that was. The patch didn't run so I had to hack manually. Anyway, lesson learned.
I need to go over Earnie's response to think hard for re-planning.
--
- Hiro
Hiroaki Honshuku, A-NO-NE Music, Boston, MA http://a-no-ne.com http://anonemusic.com
-- [ Drupal support list | http://lists.drupal.org/ ]
Thank you so much every one who helped me on my 5.1 > 5.2 upgrade. It has finished nicely and down time was only one minute if it was not less.
I finally found which inc file I modified. It was menu.inc required by menu_per_role module. When I updated my local server, it was obvious since all the menus those which shouldn't be showing got visible :-)
So, I ended up this way. Note that, I don't know what is the correct term in English about this, I do have subdirectory setup as the root of my site. I initially did this in preparation for upgrade, and I think it paid off.
I first upgraded on my local server then run test drive I duplicated the directory then replaced the settings.php with the live one Zipped it up Upload Unzip it on the server Take the live site off line Rename the 5.1 directory to 'old' Then rename the 5.2 to live one
Just for checking, I accessed right after renaming the live directory, and got a server error instead of the Maintenance message. As soon as I renamed 5.2 directory to live one, all came back right away.
All in all, I was pretty happy how it went.
Quoting A-NO-NE Music madflute@anonemusic.com:
Earnie Boyd / 2007/08/24 / 08:25 AM wrote:
For an upgrade to production it is advisable to put the site off line for a few minutes.
Ha-ha. I don't see how this can be done in a few minutes. Thank you for your response, however. You are very helpful and I always save your comments.
You work hard at trying to do a good thing which makes me want to be helpful. Using tar (see response below) can help manage a smaller window.
I would suggest a network time protocol daemon for both hosts.
I am sorry, but I don't understand what you are suggesting.
http://en.wikipedia.org/wiki/Network_Time_Protocol http://www.cis.udel.edu/~mills/ntp/html/ntpd.html
For the database you may wish to look at the importexportapi module or maybe the excellent dba module.
I don't have database backup issue. Copying database between the live and the staging within the live server is pretty easy. I do this all the time.
For the file system you might look at unix standards such as rsync.
I thought rsync also look at the time stamp, no? I have got ChronoSync which is a pretty good application, but turns useless when time stamp is messed up.
Which indicates that you have a time value synchronization issue between the two hosts and why you need to setup ntpd processes on the two hosts. Note, I am not talking about timezones which gives local representation of time. I am talking about the time value and there is only one (or should be) of those.
It's tough to realize that you've stabbed your own self.
The problems is I don't know how I stabbed myself.
Have you considered using tar?
Do you mean uploading tar file? Do I not loose the "Site-Offline" page as soon as I expand the directory to overwrite the live directory until I manually rewrite the settings.php?
Yes, that is what I mean. You can exclude[1] the settings.php file or the entire sites directory and any other file or directory you wish. The site maintenance is controlled in the DB via admin/settings and opening ``Site maintenance''.
By the way, there is one inc file I modified but I can't remember which one. Without proper time stamp, this is bad. I was wondering if anyone knows a good def GUI app runs on OSX10.4. I actually don't know a proper keyword to google this.
You can always install a pristine set of files somewhere on the disk and use the diff command to find the changes. If you want a GUI visual I suggest gvim[1].
[1] http://www.gnu.org/software/tar/manual/html_node/exclude.html#exclude [2] http://macvim.org/OSX/index.php
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-
A-NO-NE Music -
Cog Rusty -
Earnie Boyd -
Metzler, David -
William Smith