Apache

Installing Drupal 6 from scratch

The next major version of the ever-popular CMS framework (yes, that is Drupal) is in your hands to install for testing or production deployment (depending on how many modules you want to use in your production environment).

Modules and add-ons

As you may expect, or have come to expect, module builders and themers are yet to churn-out new, and ported and updated version of existing modules and give-away themes. As such, if you are already running your site on a previous version of Drupal (Drupal version4.7x or 5.x), you should weigh your options before replacing your existing production version with the new version. Personally, I run pre-release and release versions of Drupal on a secondary environment for 1 to 4 months (or until my critical modules are ported - those that will affect access to content, and SEO), before I begin to roll-out or upgrade the newest version to the production server. This delay also enables me to thoroughly learn the workings, features and other changes; this properly equips me to quickly deploy the application and respond support my clients.

Step by Step Instructions

• Download a fresh copy of Drupal version 6 from drupal.org.
• Uncompress the source and upload it to your LAMP/WAMP server (Apache, MySQL, and PHP are requirements to exploit the many powerful features of Drupal)
• Access your Database Management Application and create a new database, or identify and existing database in which you Drupal 6 will create database tables. Write down the database name, username (with ALL privileges to that DB) and password, you will need them below
• * As usual, make sure that you also create a /files folder and make it writable (CHMOD 666 or more). This is the location where the application will write uploaded files to. If you do not create this directory at this time, you will be warned by the Drupal 6 installer to do so after you begin the installation process
• Open your browser (my skewed recommendation is to always use Firefox) and go to the URL that defines the location where you uploaded your Drupal 6 source files - You will see a familiar Drupal installation screen with a global progress list on the left, and directions on the right
• Assuming that you are installing in English, click on the first link to start. If you do not have a writable /files directory within your Drupal installation folder, you will see the following error message ("The directory files does not exist. To proceed with the installation, please ensure that the files directory exists and is writable by the installer. If you are unsure how to create this directory and modify its permissions, please consult the on-line handbook or INSTALL.txt.")
• Once you have created a 'files' directory and given the correct permissions (666 - read/write or above), try again and you will proceed to the next step
• Using the database name, username and password that you created, or noted when you created or identified the database, fill in the three fields provided at this stage. You have the option to expand to the advanced options if you want to define the name of your database server (if it is not on the same IP/server as your Drupal web server), database port, and the table prefix (if you are using an existing database, or intend to share the database with other applications, then you should define a table prefix to help you identify the tables by application or installation version)
• The installer will display a progress meter while it writes to the file system (settings.php), and creates database tables to enable Drupal 6 to run
• When done, the next screen will require you to enter elementary account and site information. This is a departure from earlier versions of Drupal in the following ways
  1. In previous versions, generic information was used and this information needed to be added after installation
  2. Previously, if you did not create the first user (UID=1) as soon as possible, as well as the first node, someone else could potentially hijack your installation and site/server (could run PHP code) by calling the installation URL and maybe secretly creating a controlling account
  3. In Drupal 6, you can choose the name of the admin account, and there is a password security evaluation metre that tells you how strong your password is, and if the repeated password matches
  4. There is a configuration test that tells you if you are able to enable and use 'clean URLs' based on whether your server configuration (Apache mod_rewrite) is enabled
  5. The last feature on this page is the ability to have Drupal 6 alert you whenever there are updates and upgrades to your current installation - this feature ensures that you are running the latest and greatest version (if you choose to install), or you are at least aware of the option
• When you are done adding the requested information, you will see a message in the next screen informing you that your installation has been successful

congratulations, you now have a working Drupal 6 installation

An effective, flexible and useful Web Content Management System (WCMS) feature

Like many leading Web Content Management Systems, Drupal is especially flexible and powerful when it comes to providing administrators and content managers and publishers with the ability to easily create and maintain custom and flexible user-friendly paths and URLs/URI. Despite the typical assumption that a dynamic CMS application has to suffer from the inability to generate or accommodate the custom paths, Drupal makes it possible to match the flexibility and choice of a static, file-system-based web-site content path system while maintaining the power and flexibility of a Web Content management System.

General Requirements of a WCMS friendly path system

1. To enable content creators and optimizers to create and apply human readable URL paths that are relevant to the page content in keywords and inference.
2. Create URLs that are short and easy to remember for marketing programs and printed materials
3. Allow the creation of path aliases to enable traffic channels to be tracked by using different paths for different sources
4. Facilitate the option to create paths that mimic the file-system based URLs delimited by "/". This is useful for the migration of already established physical paths that are logical, semantic and have high pageRank
5. Make the selected paths independent of the destination GUID so that one established path can be pointed at any location, and changed as necessary
6. Ability to create more than one alias per physical content item: Especially in the migration, there are many pages that are redundant, and for the first 6-12 months, we will need to maintain 301 and 302 header redirects from many paths to one single resource

Basic features of a WCMS path alias management tool

1. Integrate with the content creation work flow to enable content publishers to select a suitable path and verify that the path does not already exist - Paths by definition of URI have to be unique, and an effective path management system has to be able to alert the publisher when he/she attempts to create a duplicate path/URL
2. The alias management tool itself will provide the option to edit and modify existing URL paths to enable the creation of paths without having to create a content object (e.g http://cmsproducer.com/nature-photography pointing to idonny.com), or to change the destination of an existing path/destination pair
3. The friendly URL has to be able to mask characters that are reserved by the web-server/Operating System to eliminate the restriction not to use "-" in friendly paths
4. The paths do not need to have file extension *.aspx, *.asp, *.php, *.htm, *.html unless the user chooses to create them or other kinds of extensions to mimic a legacy URL that is being replicated. - Ideally, all paths should be folder-level to eliminate the need for a technology specific extension that will be a liability if future choices of a CMS platform or technology. For instance, if a CMS requires the use of an extension, it will unnecessarily expose the technology in use (*.aspx, *.asp, *.php, *.htm, *.html), and if in future the site-owner chooses to migrate to a different web-server technology, it will prove unnecessarily difficult or impossible to maintain the same URLs/paths without having to translate them

There are overwhelming reasons to NOT use the dynamically generated paths that Web Content Management System (CMS) or any other ECM or document management. Whether it's for SEO or for human users to be able to track and access content based on URL paths, it is always important to create short, content subject related URL paths that are easy to manage.

Various web server platforms feature various ways to handle and translate paths between the dynamic data laden path, to the desirable user-friendly path. In Drupal (running on Apache â?? mod-rewrite or IIS with ISAPI rewrite), the Path module enables the content creator and manager to define and control a path alias for every content item (node).

In addition to this basic facility to define and manage the alias, there are other modules and additions that make it easy and to an extent automate the creation of path aliases based on already existing descriptive information such as a node title, or descriptions.

Pathauto Module

The pathauto module generates a URL path from the title of a page an it has been notoriously deemed as the cause of some performance issues in the earlier versions of Drupal 4.6. In addition, it generates very long aliases based on all the contents of a node title and this makes the aliases difficult to handle and remember (although it may be an advantage when it comes to SEO).

Urlify Module

The Urlify module in Drupal generates a URL based on the words in the node title based on some rules that can be created in the module settings to exclude certain common words that rarely carry any unique meaning for a page (such as: and, or, not, maybe, etc).

Comparison or pathauto and urlify

The main difference between urlify and pathauto is that unlike pathauto, urilfy generates the alias as a suggestion pre-populated into the alias section that the content publisher can edit before publishing the content. This is an advantage in that it allows control and oversight. Urlify handles aliases on a none-by-one basis (which may be considered slow); but it makes for cleaner and more responsible URL creation.

Pathauto automates the creation of path aliases, but this seemingly efficient process leaves the entire process to software functions that do not regard the nuances and considerations or Search Engine Optimisation (SEO) that a human editor will take into consideration. Considering that URL path aliases are meant for human readers, it is recommended to use an approach that allows for page by age (node by node) determination of the path alias.