Drupal

With the upgrade to drupal-5.14 and using the SecurePages 5.x-1.7-beta1 module:

Error:

Solution:
Added the below code to the beginning of the securepages_init function in "securepages.module" so function gets loaded.

  if (!function_exists('drupal_urlencode')) {
    include_once 'includes/common.inc';
  }

Reference:
http://drupal.org/node/330171

With the upgrade to drupal-5.11 the caching feature seemed to have broken SecurePages and the GlobalRedirect modules.

Error:

Solution:
Added the below code to the beginning of the securepages_init function in "securepages.module" so paths get loaded if cache is enabled.

  // If cache is enabled we need to load the path system
  if (variable_get('cache', CACHE_DISABLED) != CACHE_DISABLED) {
    drupal_bootstrap(DRUPAL_BOOTSTRAP_PATH);
  }

Reference:
http://drupal.org/node/119009

Error:

Solution:
Add "function_exists('_menu_item_is_accessible') &&" check in "globalredirect.module":

  if (function_exists('drupal_get_path_alias') &&
      function_exists('_menu_item_is_accessible') &&
      _menu_item_is_accessible(menu_get_active_item()) &&
      isset($_REQUEST['q']) &&
      empty($_POST)) {

Reference:
http://drupal.org/node/301844

Since Drupal has been coming out with rapid updates, mainly due to security fixes, it's quite cumbersome to have to keep it up to date. However, with the below setup and the script to help with the maintenance, it was a breeze with the last update. The script has been used to upgrade from 5.5 to 5.6 release.

Note: The script does not currently have any checks (extreme alpha stage) and my Drupal installation is not a standard install so usage may vary. Make sure you understand the script prior to running it. Usual disclaimer applies. You will also need root level access to shell to run the script as it is set to change ownership of files and folders using the "chown" command.

My current Drupal install are based on symbolic links for easy maintenance and upgrades. The layout is as below:

/var/www/html, /var/www/html/site_files, /var/www/html/sites are all symbolically linked to the /var/www/drupal-5.x, /var/www/drupal_files, /var/www/drupal_sites respectively where /var/www/html is the web root.

Document Root = /var/www/html            -> /var/www/drupal-5.x
Files Folder  = /var/www/html/site_files -> /var/www/drupal_files
Sites Folder  = /var/www/html/sites      -> /var/www/drupal_sites

Also, any customization to the .htaccess is on top of the default Drupal code. So the script will automatically prepend the data to the upgraded .htaccess file. Since, I also have the gallery module, the .htaccess file is also set to be writable by apache.

Don't forget to set your site in "maintenance mode" with the default theme, and disable all modules prior to the upgrade. Although, I've done some updates with all modules available without any issues. Also, my custom theme resides in the sites folder and stays untouched with the update.

Place the script in "/var/www" (just outside your document root) and run the update via:

Once completed, run update.php to update any changes to the database. Set site back to production mode, re-applying any customization as necessary.

I run the site on the open-source Drupal CMS and recently updated to the latest 4.7.7 version. The site has quite a few customizations and is not a standard install.

The html document root is a symbolic link to the actual drupal gunzipped folder and all other relevant custom modules are also just symbolically linked from the modules folder to keep the updates as simple as possible.

I also use the "bluemarine" theme which has been customized and named as "linuxweblog", so updates don't necessarily override my custom theme.

Pre-Update Preparation:

1. Backup database and site files.
   
2. Login to website as the administrator.
   
3. Disable the "Tag Cloud" block as it has some custom php.

Update:

1. `cd /var/www/`
   
2. Download from http://drupal.org/project/releases
   
3. Untar the gzip package.
   
4. `rm html` -- remove the symbolic link.
   
5. `ln -s drupal-* html` -- link to the newly extracted folder.
   
6. `cd html`
   
7. Edit the "sites/default/settings.php" file
   • Add the correct database, username and password to $db_url
     
   • Edit the $base_url without trailing slash to http://www.linuxweblog.com
8. Go to linuxweblog.com/update.php and run the update.

Post-Update Customizations

1. `cp -a themes/bluemarine themes/linuxweblog
   
2. Copy or merge node.tpl.php, page.tpl.php and style.css to the linuxweblog theme folder.
   
3. Merge .htaccess file and bring over the old customizations.
   
4. `cp -a ../drupal-old-*/{robots.txt,favicon.ico} .`
   
5. `ln -s ../site_files/ site_files` -- create the symbolic links to where the cache and other static files are placed.
   
6. `ln -s site_files/cache/ cache` -- create the link to the cache.
   
7. `ln -s ../../drupal_contribs modules/custom_mods` -- create the link to the custom modules.
   
8. Enable the "Tag Cloud" block.
   
9. Re-apply the google search hack to the "search.module" .

Security:

1. `cd /var/www/`
   
2. Chown -R user:group drupal-*
   
3. Set the directory permissions: `find . -type d -exec chmod 755 {} \;`
   
4. Set the file permissions: `find . -type f -exec chmod 644 {} \;`
   
5. `chmod 640 sites/default/settings.php`
   
6. `chgrp apache sites/default/settings.php`

I was serving static content within a drupal installation, which became a huge nightmare when doing upgrades. So, I decided, I should just create a symbolic link to a folder outside the installation and route the traffic via mod_rewrite rules.

I first created a folder called "/var/www/site_files" and then symlinked to it from "/var/www/html/site_files". This way, I just have to recreate one single symbolic link after doing the upgrades.

With the below rules, I was able to maintain the links to the existing pages.

Drupal is the name of the software which powers linuxweblog.com . There are Drupal web sites all over the world, and many of them share their registration databases so that users may freely login to any Drupal site using a single Drupal ID.

So please feel free to login to your account here at linuxweblog.com with a username from another Drupal site. The format of a Drupal ID is similar to an email address: username@server. An example of valid Drupal ID is mwlily@www.drupal.org.

Jabber is an open source instant messaging system designed to give the power of choice and freedom back to the users of instant messaging. Not only does Jabber allow its users to use (and create) clients for numerous platforms, but it allows people to communicate to whomever they want in the way which is most convenient for them.

You may login to linuxweblog.com using a Jabber ID. The format of a Jabber ID is the same as an email address: name@server An example of valid Jabber ID is mwlily@jabber.com.