Drupal

The standard release of Drupal, known as Drupal core, contains basic features common to content management systems. These include user account registration and maintenance, menu management, RSS-feeds, page layout customization, and system administration. The Drupal core installation can be used as a brochureware website, a single- or multi-user blog, an Internet forum, or a community website providing for user-generated content.

As of August 2011 there are more than 11,000 free community-contributed addons, known as contrib modules, available to alter and extend Drupal's core capabilities and add new features or customize Drupal's behavior and appearance. Because of this plug-in extensibility and modular design, Drupal is sometimes described as a content management framework. Drupal is also described as a web application framework, as it meets the generally accepted feature requirements for such frameworks.

Symptoms: An authorized Drupal user loses "edit" access to nodes they've created, even if they have appropriate node (or other module) access permissions. Or, user cannot edit a node that should be editable by them, based on access control or node access settings. No errors or warnings are presented to the user. Nothing in the Drupal watchdog log.

Possible Cause: The user does not have permission to use the input filter currently assigned to the node. (An administrator or other privileged user may have changed the input filter settings, or, input filter permissions may have been changed to exclude the node author since the node was created. As a result, the user never had, or no longer has permission to use the input filter associated with the node.)

Another common alternative platform to Drupal is Ruby on Rails. We really don't have much to say about Ruby except that it is a framework moreso than a platform. There are some characteristically challenging web development tasks that are quite easy to do with Ruby, and there are others which are infinitely more complicated than they should be.

One big difference is the fact that Ruby lacks the refined data object model found in Drupal that ensures interoperability between various aspects of the system, such as adding new modules to modify the operations of others. Whereas Drupal offers a self-generating database schema for many modules and underlying components of the platform, Ruby on Rails emphasizes a design philosophy holding that simplification of code conventions leads to better outcomes. While this all sounds good in principle, we have found there are certain tasks that make adherance to this philosophy an ideal moreso than a practical goal and breaking free from these conventions when necessary a daunting task (especially when integrating with external systems).

Drupal is often compared to a number of commercial content management systems including Crown Peak, Expression Engine, Clickability and Site Life in terms of capabilities. None of these systems offer the range of features that can be found in Drupal or the flexible, developer-friendly architecture that allows us to rapidly deploy dynamic web sites. In terms of sustainability, these platforms charactertistically lack the innovative approach to development embraced by the Drupal community, with updates and new features continually being added to the platform. These systems typically do surpass Drupal in terms of out-of-the-box reporting and metrics tools, generally providing views of data that is also stored in other systems. For instance, detailed page tracking information can just as easily be pulled from a CDN and integrated into a Drupal site for much less than the costs of per-seat licenses from a commercial vendor over a 1 month period.

A wide range of support services are available for organizations running Drupal sites. The Drupal community itself is an excellent resource for people looking to learn more about the platform or resolve specific issues that emerge using the system. Acquia offers an enterprise distribution of Drupal that includes uptime monitoring, email and telephone based troubleshooting support, and subscription plans for sites with varying performance requirements.

For hosting, Our works with a variety of partners to deliver solutions to ensure sites are operational and can scale to meet changing traffic expectations. Rackspace is Our preferred hosting partner, and their 100% uptime guarantee allows us to focus on building great web sites without worrying about the network. Workhabit and Amazon S3 offer cloud hosting solutions that allow us to build sites that automatically scale to handle large peaks of traffic, and to provision new servers dynamically based on actual traffic conditions on any given day.

Given that our choice of short name is "onthisdate", start the module by creating a folder in your Drupal installation at the path: sites/all/modules/onthisdate. You may need to create the sites/all/modules directory first. Create a PHP file and save it as onthisdate.module in the directory sites/all/modules/onthisdate. As of Drupal 6.x, sites/all/modules is the preferred place for non-core modules (and sites/all/themes for non-core themes), since this places all site-specific files in the sites directory. This allows you to more easily update the core files and modules without erasing your customizations. Alternatively, if you have a multi-site Drupal installation and this module is for only one specific site, you can put it in sites/your-site-folder/modules.

The module is not operational yet: it hasn't been activated. We'll activate the module later in the tutorial.

The first step in creating a module is to choose a "short name" for it. This short name will be used in all file and function names in your module, so it must start with a letter and by Drupal convention it must contain only lower-case letters and underscores. For this example, we'll choose "onthisdate" as the short name. Important note: It is not just a convention that the short name is used for both the module's file name and as a function prefix. When you implement Drupal "hooks" (see later portions of tutorial), Drupal will only recognize your hook implementation functions if they have the same function name prefix as the name of the module file.

It's also important to make sure your module does not have the same short name as any theme you will be using on the site.

There are three ways to interact with the search system:

Specifically for searching nodes, you can implement nodeapi ('update index') and nodeapi ('search result'). However, note that the search system already indexes all visible output of a node, i.e. everything displayed normally by hook_view () and hook_nodeapi ('view'). This is usually sufficient. You should only use this mechanism if you want additional, non-visible data to be indexed.

Implement hook_search (). This will create a search tab for your module on the /search page with a simple keyword search form. You may optionally implement hook_search_item () to customize the display of your results.

Implement hook_update_index (). This allows your module to use Drupal's HTML indexing mechanism for searching full text efficiently.

If your module needs to provide a more complicated search form, then you need to implement it yourself without hook_search (). In that case, you should define it as a local task (tab) under the /search page (e.g. /search/mymodule) so that users can easily find it.

For a recent project I needed to customize the feed icon in the Drupal theme I was creating. This wasn't as straight forward as I thought it would be. Being the drupal newbie that I am I went looking for it in the core templates and suggestions page only to come empty handed.

Previously I found the solution to theming a search form by using the search-block-form.tpl.php template file and thought there would be one for the feed icon too. I found the solution to this in the function reference in the form of a theme hook.

theme_feed_icon($url, $title)

This function is internally called by drupal to generate the feed icon in the Syndicate block. Our Job is to override this function.

Define the navigation menus, and route page requests to code based on URLs.

The Drupal menu system drives both the navigation system from a user perspective and the callback system that Drupal uses to respond to URLs passed from the browser. For this reason, a good understanding of the menu system is fundamental to the creation of complex modules. Drupal's menu system follows a simple hierarchy defined by paths. Implementations of hook_menu () define menu items and assign them to paths (which should be unique). The menu system aggregates these items and determines the menu hierarchy from the paths. For example, if the paths defined were a, a/b, e, a/b/c/d, f/g, and a/b/h, the menu system would form the structure:

a

a/b

a/b/c/d

a/b/h

e

f/g

► Upload your folder with the complete drupal installation to your home-directory.

► Once done, go to phpadmin on the new host, create a new mysql database, example "name_drpl1" and create a new mysql user. Create a password for this new mysql user, click "assign all privileges" to this user and assign the user to the new database.

You now should have a new mysql database on the new host with a mysql user, eg. "name_drpl1" as database name and "name_username" as database user name.

► Import (upload) the database (which you exported from the old host earlier) with phpadmin to the new database. This might take a minute.

► If needed edit the file [drupal home]/sites/default/settings.php and edit at the section where you enter the database, location, username and password. You CAN enter the password either encrypted or not encrypted there.

► Chmod your "files" folder so it is writeable using your ftp client (filezilla), chmod to 777

► Double check your .htaccess and [drupal home] /sites/default/settings.php and make changes in case they are needed.

Change nameserves on your domain host and let them point to your new host's nameservers.

Enter the new nameservers in your control panel where your domain names are hosted, overwriting the old ones.

After some time (sometimes a day or two) your domain should point to the new host and drupal should be up and running on the new host.