PostNuke
Flexible Content Management System
News
A Contest for a Community Network Open Source Package
Web hosting -- multiple sites in directories under a single domain name (e.g. http://civic.bev.net/seniors/, http://civic.bev.net/lions/) or virtual hosting (e.g. http://www.quiltingclub.org/). FTP access, PHP scripting support, and email reply form support (could be a CGI or PHP) are minimum requirements.
Email -- Civic groups typically need two or more email accounts to assist with Web site management and group management. POP3 accounts are required, and a Web-based email interface is very desirable. Email accounts may use a common domain name (e.g. quiltingclub@bev.net) or use a custom domain (e.g. web@quiltingclub.org).
Mailing lists -- civic groups typically use one or two mailing lists as information channels to their membership and to the public. Mailing lists may use a common domain name (e.g. quiltingclub@list.bev.net) or use a custom domain (e.g. members@quiltingclub.org).
Discussion forum -- civic groups often use forums for public and/or private discussions. These forums are integrated into the group site.
Online calendar -- civic groups use online, interactive calendars with a forms-based interface to provide a calendar of group and civic events. Sometimes more than one calendar view is used (e.g. one for public use, and one for private use by the managing board).
Email -- Civic groups typically need two or more email accounts to assist with Web site management and group management. POP3 accounts are required, and a Web-based email interface is very desirable. Email accounts may use a common domain name (e.g. quiltingclub@bev.net) or use a custom domain (e.g. web@quiltingclub.org).
Mailing lists -- civic groups typically use one or two mailing lists as information channels to their membership and to the public. Mailing lists may use a common domain name (e.g. quiltingclub@list.bev.net) or use a custom domain (e.g. members@quiltingclub.org).
Discussion forum -- civic groups often use forums for public and/or private discussions. These forums are integrated into the group site.
Online calendar -- civic groups use online, interactive calendars with a forms-based interface to provide a calendar of group and civic events. Sometimes more than one calendar view is used (e.g. one for public use, and one for private use by the managing board).
Jakarta-Architects.Net
Footnote: 1
Updating PostNuke - a users report
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:
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:
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:
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:
Good luck and have fun.
jalal at gnomedia.com
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
Core Development Detailed Roadmap
Regarding the API, can we also setup a page ala php.net manual inside postnuke.com so we can use the pnAPI as development framework.
I just want to minimize the probability of doing the same thing so I and others who are not members of the Core devteam can go with other enhancement or improvement. Also, somehow we can predict applicable future modules.
I accept that the module dev't is very uncertain but please have the core transparent as it should be.
thank you.more power.
I just want to minimize the probability of doing the same thing so I and others who are not members of the Core devteam can go with other enhancement or improvement. Also, somehow we can predict applicable future modules.
I accept that the module dev't is very uncertain but please have the core transparent as it should be.
thank you.more power.
Upgrading .71x to .713
Now, to quote from the original post..
So, good luck, and ask in #postnuke-support (Click here for web based chat) if you have any more questions.
This version of PostNuke includes a new version of the autolinks code, as the old one had a number of bugs and performance issues which required a
re-write of the module. Before installing this patch please go to the Modules administration screen and deactivate and remove the 'Autolink' module.
Once this has been done you can remove the following files/directories from your PostNuke directory:
html/includes/autolinkinc.php
html/modules/NS-Autolink
and apply the patch. Once the patch has been applied run 'Regenerate' from the Modules administration screen, and initialise and activate the new Autolinks module. To get autolinks working with news, edit the 'News' module from the Modules administration screen and select the 'Activate Autolinks for this module' checkbox.
This patch has no database changes so no upgrade scripts need to be run to migrate from 0.712 to this version.
So, good luck, and ask in #postnuke-support (Click here for web based chat) if you have any more questions.
Idea...Maybe....
At our community we have webmail and homepages and I wanted to provide links to these programs in the member's area.
I hope you all know what I am talking about, because I am kind of wondering if I do...lol
Anyway I have been examining the PHP files trying to figure out which one puts the menu together and how to add my options to it as well. Can anybody explain which file does this or point me to the correct documentation if there is any?
Maybe this option could be put in future versions of PostNuke Rogue?
I hope you all know what I am talking about, because I am kind of wondering if I do...lol
Anyway I have been examining the PHP files trying to figure out which one puts the menu together and how to add my options to it as well. Can anybody explain which file does this or point me to the correct documentation if there is any?
Maybe this option could be put in future versions of PostNuke Rogue?
Footnote: 1
vplanet.de get's postnuked.
First plans were to write an own CMS, but after a some time spent with postnuke we realized that it's simply a great and modular CMS with tons of features we could use. Of course, not to mention the other geeks behind the postnuke modules and blocks we've all used at our site! thank you guys - you've done a great job!
check out www.vplanet.de - get the party started! ;-)
check out www.vplanet.de - get the party started! ;-)
Footnote: 1
Page 98 / 277 (971 - 980 of 2763 Total)
