I have a development machine at home, and then an online site for production. The aim was to perform the installation and check it on the dev machine, keep repeating it until it went smoothly and then repeat the procedure on the production machine. The production site is not a heavy usage site (~200 user/day), but I wanted the update to not take longer than an hour. As an extra catch, I only have FTP access to the online site, no Telnet or shell access and no access to the database. So, it had to work!
I have a PHP script on the online server that will query the database and extract all the data into a set of files (.sql files and restore.php) that can be used to recreate the database when needed. I've never needed to do it, but its comforting to know that I can. I use this script to transfer the data from the production site to the development site.
NOTE: these notes apply to the above upgrade. Your setup may be different.
The first thing I did was to make an installation on the development machine, in a different directory from the old version. Untar the files etc.
Next, make sure that there was a backup of the old installation database, so that I could rollback if needed. I repeated the installation about six times, backing up to the 0.63 version in between, so a script was needed, something like this:
In /var/lib/mysql make a back up like so:
tar czf pn63.tgz postnuke
Have a script like so:
<code>
#!/bin/sh
rm -r postnuke
tar xzf pn63.tgz
chmod 700 postnuke
chown mysql:daemon postnuke
</code>
Run this script and afterwards run:
mysqladmin flush-tables
OK, so now we have a backup of our 0.63 version of the database, we have the 0.713 files installed (in a new directory), now we need to copy over the extra themes, modules and blocks that the 0.63 installation used. Put them in the same directories in the 0.713 directory.
IMPORTANT: you will need to keep the PostNuke theme in order to make a first login in the new site. After the site is setup and running, you can remove the PostNuke theme if you don't need it.
Check the naming of the images/avatar files. In the 0.63 install, they were 'graphics/avatar/ava001.gif', in the 0.713 install, they are 'images/avatar/001.gif'. The change in directory name doesn't matter but the change in the gif name does, as your current users will have the gif name stored in their profile. The solution I took was to rename them all to the old names, the other possibility would be to run an update on the database (see later for this).
Copy over the old config file from the 0.63 install and rename it to pn7config.php. Check that the config.php and config-old.php files have 666 mode.
We're ready to run the install.php script now, follow the instructions on screen.
Assuming it was successful, we're now ready to log in as an administrator and configure the site to our needs. If the installation was not successful for some reason, running it again will not work because the installation scripts will complain that the (new PN0.713) tables already exist and abort. We can either modify the scripts to delete the new tables (take a look in pn7.php for this) or simply rollback the database as per my instructions above. Thats why we made a backup!
Right, logged in as administrator? No? One problem could be that if you are installed on an intranet or local machine, then PostNuke will not let you log in unless you use a fully qualified domain name, so make sure you have a fully qualified domain name in the location bar. (i.e. using 'http://mybox/pn7/index.php' will not work, you need to use 'http://mybox.domain.com/pn7/index.php').
Administration tasks:
The first thing to do as administrator is to go to the settings page and configure the site as you need.
Nip over to the comments page to change the name of the anonymous user if you need to.
Then move to the permissions page to set up the permissions.
On the blocks page, disable the Reminder block and set up the other blocks as you need them.
My installation ended up with two admin blocks, the first one activated, the second not. I deactivated the first and activated the second. I then modified the block to show adminstration and logout links.
I also added some links to the menu block. The nice thing about PostNuke0.713 is the abillity to design the menu with the items in the order you want, with the labels that you want.
On the modules page, setup the modules that you need.
Some funny things that I noted:
- The main menu had three blank items at the start, which I had to remove using the blocks admin page.
- The two admin modules as noted above.
- The permissions system is quite complex and powerful, I won't make any description of it here, the online docs do a good job of that, but I will note that if something doesn't work the way you expect, then this is the first place to check.
- If you add a logout item to the menu, then you would expect it to read something like:
user.php?op=logout
But if you do this, then the logout will just hang. You need to use:
user.php?op=logout&module=NS-User
- Double spaced lines, extra '\n\r' and so on, see the note at the end of this article.
- addslashes, stripslashes and the magic_quotes_gpc debacle, see note at the end of this article
By now you should have things working the way you want. Once you have everything checked and OK we want to create some scripts. What we've been through above is far too long winded for a real production site, what we want to do now is to dump out the setup and configuration data and create some PHP scripts that will automatically update the database with the settings we need.
There are two approaches to this. The first is to go in to mysql and dump out the data by hand. The other is to write a script to do it for us. I actually used the first method, but if I was to do it again I would use the second method. In fact, the backup script that I mentioned at the start of the article will do this job for you.
Now the site is setup on our development server, its working the way that we want and we have an update script that will load the configuration data into the database. Good. So, now delete everything in the pn7 installation directory. Using the shell script that I mentioned above, restore the old postnuke database to the way it was in PN63 and check that your old PN63 web site is working the way that it used to.
The next step is to have a dress rehearsal of installing the new site. Follow the instructions above (untar the site, copy over the needed files etc) until you have finished the install script and logged in as administrator. Now run the update script that we made in order to setup the site configuration. This should theoretically take care of all that phatzing around and the site will be set up in minutes instead of an hour.
If some things are not working out, run through the whole dress rehearsal again, modifying the update script in between till all the data that you need is updated. The aim here is to make it so simple that the real production site can be updated in a matter of minutes not hours.
When the whole process is running smoothly, you can go ahead and do the real thing on the live production server. You may want to provide a small index.html informing users of why they can't find the site while the update is taking place. Delete the root files first and put up the index.html. Then delete all the old files, ftp up the new ones, do the install, run the update scripts and the world is a beautiful place.
Some More Notes:
Double spaced lines
On the first run through, all my news stories came out double spaced! For every '\n\r<.br>\n\r' in the text I now had '<.br /><.br><.br />'. Not good, especially when you have hundreds of stories. The offending lines are in the install scipt 'pn7.php' around line 97 there are some nl2br(...) function calls. Comment them out. I haven't noticed any detrimental side effects from doing this.
There is also an informative article at http://abooks.com/lines.htm by Ralph Roberts
The magic_quotes_gpc problem
When you run the install script, on the second page, where it checks the permissions on the config files, it will also check the magic_quotes_gpc setting (in the php.ini file) and warn you if it is set to Off. If it is Off, then it will advise you to turn it on.
The magic_quotes_gpc setting is a PITA. In my opinion PostNuke should not require it to be on, its not necessary. On my Web host, the setting is off, and I have no access to the .htaccess files to override that setting. I can't turn it on. So, I have to find another way of dealing with the problem. I think (but I'm not 100% sure, any feedback appreciated) that a modification to the textsanitizer.php script is all thats needed. Near line 85, these two functions should be changed to look like this:
function oopsAddSlashes($text) {
if (get_magic_quotes_gpc()) {
$text = addslashes($text);
}
return $text;
}
function oopsStripSlashes($text) {
if (get_magic_quotes_gpc()) {
$text = stripslashes($text);
}
return $text;
}
Good luck and have fun.
jalal at gnomedia.com