Drupal 5

To add granularity to the items in a given view that should be shown on a given list, you can either use:

1.  Taxonomy terms - has the disadvantage of being listed in the term listing for that node unless you do extra work to exclude the vocabulary
2. Re-purpose the 'promote to frontpage', or 'Sticky' settings already provide in Drupal - can have side-effects by affecting the promote and sticky features; since this is a 'misuse' of features
3. Views Bookmarks - This module provides the features of the above alternatives without the disadvantages of either option. The module enables the creation of multiple and virtually endless switches that can be restricted by roles allowed to use them, the scope of effect (users can create bookmarks that only affect what they see), and the node-type (CCK) that a tag/switch can affect. Most  importantly, this module closely works with VIEWS, and so the switches can be used to add more granularity to VIEWS queries without unnecessarily clouding Taxonomy or mis-using existing settings (Sticky, Promote)

Drupal 5 is now available for general installation, and to respond to this important and long-awaited news, we have decided to embark on upgrading our main website that is currently using Drupal 4.7x to use the new version so that we can reap the benefits of the many new functions of the popular and even more powerful CMS infrastructure/application.

Although many modules that are currently in use are not yet ported to Drupal 5, the above-mentioned benefits of upgrading, as well as the ability to document all possible challenges, errors, and other notable experiences for our customers, or just as testimony to our confidence in the new version is reason enough to upgrade.

This is not our case, but you may opt not to upgrade from your current version of Drupal if you have so heavily invested in custom modules and forked Drupal core code to a point where you may not want to compromise existing functionality. Or you may be so far off from the standard Drupal code that you will need time to develop and port your custom functions to be compatible with Drupal 5.

Like any site/life changing website modifications, you should or rather, you must make a backup of the sites database and codebase (files) before you embark on upgrading and replacing things. This is because if the upgrade process fails in any way, you will be unable to get back the old website if you do not have backups.

The necessary steps to this are fewer than what I will outline in this section. The minimum requirements are for you to make one backup of the database and keep it in a 'safe' place while you upgrade the installed/live database.

• My choice is to make a backup of the site as it is/was before you even thought about upgrading Drupal (together with all your modules in place and working). Since it is advisable to turn-off all your modules and themes before upgrading, this first backup will enable you to rebuild your site as it is/was running the old version of Drupal without worrying about re-enabling themes, and modules
• The second database backup should be done after you have disabled all your non-core modules, and changed your default module to one of the out-of-the-box modules that come with Drupal. These two steps will enable the post-upgrade relaunch of the site to be smooth as there will be no theme and module settings to generate error messages. In particular, as of this upgrade, there is no Drupal 5 compatible version of the module node_privacy_by_role.module which I am running on the 4.7x site. It is crucial to turn this module and other modules OFF from their respective settings' section before upgrading. In particular, since this module controls who/what content is visible to the various roles on your website, leaving it active will switch off all your content from display to anonymous users once you upgrade/delete the modules files.
• Instead of upgrading the live database that is left on the server, another level of security for me is to leave it intact just in case the SQL database backup was not clean and create a new database to use in the upgrade. I therefore imported the above exported SQL code into a new MYSQL database.

Copy all the files and folders in your Drupal program folder on the server and keep them in a safe place for use just in case the upgrade process fails or if you would like to re-install the soon-to-be previous version Drupal on a different server to be able to test the old version or use it for other research purposes such as supporting your customers who may choose to maintain their sites on Drupal 4.7x (It is assumed that you will have by now upgraded all your sites to Drupal 4.7x as all older versions will not be supported by the core developers).

Reliability of service is key in maintaining and increasing the user-base of your website. You should therefore notify your visitors that you are in the process of upgrading your CMS application or will be otherwise off-line for maintenance so that they can understand if they experience limited or no content delivery. There is functionality within Drupal to handle the display of the maintenance message. NB: In addition to that, I also create a message in an index.html file that will be served when I delete or rename the old Drupal versions pages including the index.php that would otherwise serve the site maintenance message.

• Rename all the pre-existing (4.7) folders to enable the creation of new Drupal 5 folders. In my case, I decided to add an underscore "_" to the file and folder names from Drupla 4.7 so that I can be able to go back to the 4.7 site to tweak things in the configuration if need be (I had forgotten to turn off some modules, and would prefer to do so from within Drupal as opposed to tinkering with the database especially since I would like to begin with a clean set of tables without potential errors).
• Download a fresh copy of Drupal 5 code and upload it to your server in the pace where you would like to have your permanent website. NB: Previously I used a temporary folder and this was included in the node page for some pages in the upgrade from Drupal 4.6x to Drupal 4.7 , and I had to spend a lot of time cleaning up the paths physically and in the database. This is unnecessary and should be avoided.
• Copy the contents of your "/sites" folder to the live (Drupal 5) site folder, as well as other items that you would like to reuse such as the "/files" folder.
• So as not to modify the Drupal 4.7x database that is live on the server, we will upgrade the database that we created in the last step of the Database backup process above. We MUST therefore modify the "/sites" configuration so that the settings.php file points to the copy of the database that we created for upgrade. NB: If you at this point attempt to access your website, you will see the below error message "Fatal error", but fear not as this is normal being that the database tables have not been updates to Drupal 5.
• Run the /update.php file and you will go through the update process; if you are luckier than me, especially if you followed all the steps, you will get a confirmation screen informaing you that the upgrade is complete.

  
  
  
  

• I was not as lucky, maybe because the database import I performed to safeguard the live/working database took more than 30 minutes to export and completed with an error.
• My upgrade process resulted in an error message that

  user warning: Can't DROP 'vid'; check that column/key exists query: ALTER TABLE node DROP INDEX vid in /home/cmsprodu/public_html/includes/database.mysql.inc on line 167.

  I ignored the error and I was able to access the website to update the theme and other modules for the website.