Sunday, February 21, 2010

Anatomy of a Drupal-based Home Page

Technorati Tags:
home-page We are close to launching our re-designed website for the church I attend. To gain a bunch of functionality and enable easier updating we picked the Drupal CMS as a framework. The past three months have been a journey of discovery into its features that is reflected in our home page shown on the right.
The default Navigation menu has been enhanced by including the Nice Menus module. This gives us cascading sub-menus for “free” by simply installing and configuring the module. You simply need to edit the left-sidebar block and replace the Navigation block with the Nice Menu module then choose “Configure” next to the Nice Menu and select the <Navigation> menu as its Source Menu Tree.
We used the Simple News module to handle weekly emails and exposed it as a block shown on the lower left. Simple News enables user-controlled subscriptions and handles batched sending from the web server. Previously our administrative assistant used Outlook and had to divvy up the distribution list into several chunks to stay beneath her email host’s restrictions for bulk emails. Now it happens “magically” using cron features on the server – a fire-and-forget approach.
home-page-content The main content area started out as a simple Page node-type however we wanted more granular control of the content layout so we added Panels. Originally we had a welcome message followed by the photos/writeups of our two locations and the two Views blocks for announcements and upcoming events at the bottom of the content area. As the page evolved, we decided that the announcements and upcoming events should be more prominently displayed between the two content areas. We also wanted to insert a flash video welcome message from our pastor between the two sections as well. One approach would have been to resort to coding a custom theme template peppered with PHP code however that would’ve limited its use and updating to…well, just me! By using Panels I was able to layout the page into four main sections and make it accessible to others right from the website without resorting to hand-editing files on the web server as shown below:
panel-content
Notice that the two middle sections use Views as their content source. So far, the only coding I’ve had to do is a custom installation script for deployment to the live server and a custom theme for the sermons page. Drupal is impressive for the amount of features and maturity of the package that enables complex sites to be built with very little coding – all for the price of $0 and a little time and effort!

Friday, February 19, 2010

Comparison of LAMP settings across Linux distros

I’ve been using SUSE quite a bit lately and before this current job it was CentOS (a.k.a. RedHat) all the time. With my recent adoption of Drupal for our church’s website I also found myself playing around with WAMP as well. There are plenty of HOWTOs on each distro as well as forums and discussion threads that answer specific questions on where things are located, defaults, commands for restarts, etc. but I haven’t come across a simple comparison chart so here’s my attempt:

  CentOS 5.3 SUSE 11.2 WAMP 2.0c
Apache ver. 2.2.3 2.2.1.13 2.2.8
http.conf /etc/httpd/conf/httpd.conf /etc/apache2/httpd.conf
/etc/sysconfig/apache2
C:\wamp\bin\apache\apache2.2.8\conf
Apache commands apachectl  start|stop|restart|status
/etc/init.d/apache2 start|stop|restart|status
rcapache2  start|stop|restart|status
/etc/init.d/apache2start|stop|restart|status
{use tray applet}
Apache docRoot   /srv/www/htdocs C:\wamp\www
MySQL ver. 5.0.77 5.1.36 5.0.51b
PHP 5 ver. 5.2.9 5.3.0 5.2.6
php.ini /etc/php.ini /etc/php5/apache2/php.ini C:\wamp\bin\apache\apache2.2.8\bin

Thursday, February 18, 2010

Basic, Essential Drupal Modules

Technorati Tags:

Today’s post will cover some basic, essential modules that are generally recognized as “required” for most types of projects. Having worked previously with other packages such as DotNetNuke, I’ve learned that the Drupal core team takes a different approach – probably due to its Unix heritage. For example, DNN comes out of the box with a membership profile system built in which means all sites get this whether they need it or not. Drupal core offers a basic user profile for registering users (i.e. username, password, email) and nothing more. There’s also a core “Contact” module that allows you to add additional fields, photo, etc. However, you need not install or configure this unless you want the added functionality.

While it is possible to find or build a large, full featured module containing a lot of functionality the tendency with Drupal is to compose features using smaller modules that serve a single purpose like the canonical Unix “pipe”. In this way your installation contains exactly the features you need and nothing more. One such module is the Content Construction Kit or CCK which allows you to define new fields and attach them to “nodes” which are the generic, published content your site uses. Like the “pipe” it is a simple module on the surface yet the possibilities are limitless – you can define and build an entire site schema representing all the “things” (objects, entities, content) you need to store and display. CCK also recognizes and supports the “Advanced Help” module to give administrators more in depth help if it is installed. Views is another module that goes hand-in-hand with CCK and allows you to build queries to generate pages, blocks, feeds, etc.

Here’s my list of the basic, essential Drupal modules, as of 6.x:

CCK The Content Construction Kit allows you to add custom fields to nodes using a web browser.
Calendar This module will display any Views date field in calendar formats, including CCK date fields, node created or updated dates, etc. Switch between year, month, and day views. Back and next navigation is provided for all views.
Date This package contains both the Date module and a Date API module. The Date API is available to be used by other modules and is not dependent on having CCK installed. The date module is a flexible date/time field type for the cck content module which requires the CCK content.module and the Date API module.
Demo This module allows you to take snapshots of your site. It turns a Drupal installation into a sandbox that you can use either for testing modules or setting up a public demonstration site for a module / extension / theme (you name it). Whenever you need to reset your site to a saved state a click of your mouse will do so. With cron enabled, a Drupal site can be automatically reset to a chosen snapshot in a definable interval.
Image This module allows users with proper permissions to upload images into Drupal. Thumbnails and additional sizes are created automatically. Images could be posted individually to the front page, included in stories or grouped in galleries.
IMCE IMCE is an image/file uploader and browser that supports personal directories and quota. Since its first release, IMCE has been used as a file browser in many popular rich text editors such as FCKEditor, TinyMCE, WYMEditor etc.
jquery_ui A wrapper module around the jQuery UI  effects library that lets module developers add swooshy, swishy effects to their code...This is a utility module that won't do anything on its own. See README.txt for how your module can use it to add jQuery UI effects to your pages.
Node Export The export module allows users to export an existing node and then import it into another Drupal installation. The idea is similar to the way you export/import Views or Content Types.
Views The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented.
Wysiwyg Wysiwyg module allows you to use client-side editors (a.k.a. WYSIWYG editors) to edit content in Drupal. It simplifies installation and integration of editors and allows to assign an editor to each input format. Wysiwyg module replaces all other editor integration modules and no other Drupal module is required.

NOTE: The above descriptions were not authored by me – I simply pasted them from their respective project pages which each module above links to.

The nice thing about the modular approach is that you can skip the modules you don’t need. Not going to allow folks to do rich-text, HTML-savvy editing? Don’t include Wysiwig or IMCE! Prefer a different tool for the job? Use it instead!

Initial Drupal Configuration

Technorati Tags:

After initial setup and login, you should back up your database and site. Two reasons for doing so are if you do something “bad” and need to get back to an earlier state and in case you want to quickly clone the existing site. Use the Nautilus file manager to select the site directory (e.g. /home/username/www/drupal614) then right-click and choose “Create Archive”. Next, switch to (or open) a terminal session and use the following command to backup the MySQL database:

mysqldump -u root -p {dbname} > {dbname}-initial.sql

Next I find it useful to set some basic site information before doing anything else. Navigate to Administer / Site Configuration / Site Information and input your site name, slogan, and copyright statement as a footer message.

The above is a “safety” feature however I learned from going to my first Drupal meetup that there’s an even cooler and easier way to backup – using the Demonstration Module. It will take a snapshot of the database and easily allow you to restore to that point. Over the past three months I’ve used it dozens of time while testing my install and configuration scripts – which are a subject for another blog post.

Wednesday, December 2, 2009

Why Beyond Compare tool rocks

If a picture is worth a thousand words, here’s 10K worth for why you should check out Beyond Compare. It’s the one tool that I use every day I’m working at my computer. I’ve used it to compare not only files and folders but zip files to folders - it treats a zip like a folder and let’s you update the zip in situ. I’ve also used it to compare two Word documents, two Excel spreadsheets, MP3 files (tags), version stamps on executables. However, I wasn’t aware it could compare two photographs and show a “mask” of the differences between them!! It’s also the “external” tool I use for differencing in version control systems. If you earn your living using a (Windows or Linux) computer, how can you not afford to spend $50 to increase your productivity?

Thursday, November 26, 2009

Preparing CentOS 5.3 (LAMP) for Drupal 6 – Part 2

Technorati Tags: ,,,

In the first article, I covered the basic steps for preparing a CentOS 5.3 installation for Drupal 6 by installing and configuring MySQL. This article covers the last quartet of the LAMP stack – PHP as well as initial installation of Drupal 6.

From a terminal console use the ‘yum’ utility to install the necessary PHP components:

yum install php-mysql php-gd php-imap php-ldap php-odbc php-pear php-xml php-xmlrpc

Next it’s helpful and common practice to create a PHP informational page to verify its installation using the Gnome text editor:

gedit /var/www/html/phpinfo.php

Paste or type the following then save and exit:

<?php

// Show all information, defaults to INFO_ALL
phpinfo();

// Show just the module information.
// phpinfo(8) yields identical results.
phpinfo(INFO_MODULES);

?>

Display the PHP information using the browser:

phpinfo_header

Scroll further down to verify that the Apache URL rewriting module is loaded:

phpinfo_modrewrite

This will be useful later for what is known in Drupal as “clean URLs”.

Implicit in the above instructions is the fact that the default location for the Apache web server document root folder is /var/www/html which means placing web files and folders under there makes them automatically served up by Apache and accessible via a web browser with no other special configuration. However, a common alternate approach is to create a separate Unix user account per installed application so that permissions and configuration settings are easily isolated to that account. This approach also facilitates remote development because it’s simpler and easier when enabling FTP access since Unix accounts typically have full access to their “home” directories. Doing it this way means a couple of extra steps when initially setting up the Drupal website but saves a ton of headaches in the future trying to enable access to the machine-wide directories under /var.

Earlier we created a MySQL database account called ‘drupal614’ (reflecting the current released version of Drupal). If you haven’t done so already, we’ll next create a Unix account with the same name:

useradd drupal614

passwd drupal614

After logging in as this new user, browse to the Drupal website and download the latest 6.x released version. Use the Nautilus file manager to open the .tar.gz file and extract it under the user’s home directory. Planning ahead for managing several versions, I chose to create a separate folder to hold websites (e.g. /home/drupal614/www/) so the full path becomes /home/drupal614/www/drupal-6.14.

At this point, we need to configure Apache to expose the Drupal directory by editing the httpd.conf file and adding entries:

gedit /etc/httpd/conf/httpd.conf

First we create an alias to the actual physical location on disk then we allow settings there to override the default settings for Apache by placing the following into the file at the end:

drupal_install_3-cleanurls1

Next we edit the .htaccess file in the root of the Drupal install directory – uncomment the RewriteBase instruction and set the path to the alias we specified above in the httpd.conf file:

drupal_install_3-cleanurls2

Now we should be able to follow the steps to grant write permissions outlined in the install guide then open a browser and navigate to the install page:

http://localhost/drupal614/install.php

You should see the initial page to choose a language:

drupal_install_1-language

The next page is where you’ll put in the database configuration information we had previously setup:

drupal_install_2-database

After setup is complete it is generally recommended to go into admin/settings/clean-urls and enable them if not already enabled:

drupal_install_3-cleanurls3

At this point we have an installed and working version of Drupal! Subsequent posts will cover installation and configuration of various modules to achieve the level of functionality required for a high quality community site.

Preparing CentOS 5.3 (LAMP) for Drupal 6

Having just embarked on a side project to build a community website using Drupal 6 I decided to capture the steps both for documentation purposes and to help others who may seek to do the same. To begin with, CentOS is short for Community ENTerprise Operating System and is “an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor.” In other words this open source project takes the GPL-released RedHat sources and compiles them along with free, open source replacements for RedHat’s proprietary portions. Within the business community, it is widely popular because it is “just like” (just as good as?) the commercial version it is based upon.

On numerous occasions I have installed versions of CentOS on Microsoft’s Virtual PC and Hyper-V products as well as VMWare’s Workstation. In my opinion, it is far easier with VMWare’s built-in support however their workstation product costs around $180 whereas the Microsoft products are “free” with corresponding Windows licenses. Note however that VMWare Workstation is only necessary to initially build a new virtual machine instance. Once you have the guest OS installed, you can use their free VMWare Player to run the virtual machines. VMWare has a great program of “appliances” which are pre-built, pre-configured virtual machines ready for download and operation. In fact, there’s a CentOS 5.3 appliance ready to go – you just need to download then install VMWare Player and download the appliance and you’re up and running.

The Apache web server is already installed in the appliance and when you choose “server” if performing your own install. That leaves MySQL and PHP along with some configuration. Begin with MySQL by opening a terminal window (right-click on the desktop) and switching to the built-in root user (a.k.a. superuser):

su -

yum install mysql mysql-server

Once MySQL is installed enable it for autostart using:

chkconfig –levels 235 mysqld on

then start it manually this first time using:

/etc/init.d/mysqld start

Set the MySQL database login for root:

mysqladmin –u root password ‘PASSWORD-GOES-HERE’

Next log into the MySQL command processor and set the database name to use for subsequent commands:

mysql –u root –p

mysql> USE mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

At this point there’s some housekeeping that’s usually done to secure the database beginning with removing the anonymous accounts that let any connection to the database to happen.

mysql> DELETE FROM user WHERE User = '';

mysql> FLUSH PRIVILEGES;

Now look at the remaining contents of the user table:

mysql> select Host,User,Password from user;
+-----------------------+------+------------------+
| Host                  | User | Password         |
+-----------------------+------+------------------+
| localhost             | root | 44d0372963d3fb50 |
| localhost.localdomain | root |                  |
| 127.0.0.1             | root |                  |
+-----------------------+------+------------------+
3 rows in set (0.00 sec)

Note that the Password column contains a hashed (encrypted) value. To exit the MySQL command processor and return to the Linux shell use ‘quit;’  or ‘\q’:

mysql> quit;
Bye

Create a separate database login for a Drupal user (e.g. drupal614):

mysqladmin –u root –p create drupal614

This database account will be used to connect to MySQL and will “own” the tables and other artifacts created to support Drupal. Rather than using the separate mysqladmin from the Linux shell you can accomplish the same thing from within the MySQL command processor before quitting:

mysql> CREATE USER 'drupal614'@'localhost' IDENTIFIED BY 'drupal614';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'drupal614'@'localhost' WITH GRANT OPTION;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE USER 'drupal614'@'%' IDENTIFIED BY 'drupal614';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'john'@'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0.00 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

mysql> quit;
Bye

The above commands will create two database accounts – one for connecting from within the Linux machine and the second set for connecting to the Linux machine from another. This second account is useful if you wish to connect say from your Windows machine using a free utility such as DbVisualizer or SQuirreL SQL. The GRANT command is a lazy bit of a cheat in that it grants all permissions to the drupal614 account. Looking at the Drupal installation guide you’ll find a longer syntax which only grants the specific permissions that Drupal needs to connect and use the MySQL database.

This has been a quick whirlwind tour of the essential steps. I have only tried this twice – first as a trial and error practice and again using a fresh machine to validate that I had the specific steps worked out.

Next up will be the steps for installing PHP and Drupal.