Related tags

Building a site on Drupal using MVC

If you ought to build a new site and don’t have time to develop a CMS, you’ll likely take an open source solution. And likely it will be Joomla or Drupal. They seem as most popular. Actually they are similar in many ways. Both provide basic content management frameworks, extensible through plug-ins and customizable via themes. Both focused on block-designed sites which can be often built without any programming at all, just using downloaded theme and configurable set of extensions. So it’s personal what to choose. I prefer Drupal. Its component model seems clearer to me. The documentation is much more explicit then Joomla’s and gallery of ready-to-use modules is really impressive.

Now let’s see if Drupal allows to achieve all the goals we have so far. There are no doubts it will be good for generic stuff like pages of different layouts, blog/storyboards, image galleries. But what about customization of administrative UI? Custom administrative modules? Positive! And you’re going to enjoy their approach as soon as you’ve got the overall idea behind it.

So, here we are. First of all Drupal is not MVC, but it’s built by other paradigm known as PAC (Presentation Abstract Control). So, it took me for a while to get in. It remotely reminds of Java’s portlets. You build application out of separate blocks, which have own views, controllers and shared API. Another discouraging issue is Drupal source code designed without any OOP. Here is some diffuse explanation by the author, but the fact – you have to deal with plain procedural code, mostly PHP4-designed. Nonetheless it implements widely the hook technique , something like an instantiation of Observer design pattern. I, personally, find it amazing. Drupal has system functions and default page element templates. Every plugged-in module has own functions and may have template. Now check it out, module can override system or other modules’ functions and template gracefully. And further, system and module functions and templates can be overridden within theme.

As I’ve already said, Drupal is primarily adjusted for not site building, but theming. When you install a new module, you can find you front-end appearance changed automatically. Drupal provides set of view variables in template scope. But the problem is page element variables contain ready HTML, which you can only display somewhere in page layout. That’s the way PAC works, it finds and theming all the elements by itself. I’m a MVC guy and used to have just raw data within templates and helpers to decorate it. And it’s quite available under Drupal as well. Let’s start from beginning and advance step by step. You’ll see everything on examples.

Setting up theme

Create in /sites/default/themes a folder of the name of your theme. Let’s say, mysite. Now add some files there:

You see, right before page rendering we can modify any of view variables. Particularly we modify the list of suggested template for the request. Since we use “clean URIs” like http://mysite.com/page1/subpage1 instead of Drupal’s native URIs http://mysite.com/node/12, we have to extend template suggesting mechanism. Now it tries to find page1-subpage1-page.tpl.php for the request. When failed it seeks for subpage1-page.tpl.php or page.tpl.php. We can add here conditional logic, for instance, to match templates against content types.

Switching to MVC

Now let’s bring in some stuff of Zend Framework. I’m going to make it feel like home. First, we need auto-loader. Add into theme controller this code:

include realpath(dirname(__FILE__) . "/../../libraries/Autoloader.php");
new libraries_Autoloader();

And put autoloader at the path: /sites/default/libraries/Autoloader.php

Now when Drupal’s PAC looks like customary MVC , we can come back to our page templates. For example, page.tpl.php (/sites/default/themes/mysite/page.tpl.php). We can access data of the elements added by system modules and view variables assigned by our custom controllers via $view namespace.

Pay your attention that administrative interfaces play under the same rules. You can arrange administrative theme using this MVC-like pattern.

Hooking

As I mentioned already Drupal allows customize core and installed modules behavior thought hooks. We examined phptemplate_preprocess_page hook in template.php file. Now let’s try some other. For example, you are customizing core optional module Book. By copying predefined templates (book-node-export-html.tpl.php, book-navigation.tpl.php, book-all-books-block.tpl.php) from the module folder in a folder within your theme and modifying them you will get a pretty good result. But if you want to customize markup for book menu items, you can do nothing via templates. It uses the decorator common for every menu item. Though you can change it, putting into template.php (theme folder) following:

Modules

I assume modules are the very benefit everybody likes Drupal so much for. If you want to extend the system somehow just search for ready modules and likely someone has written it already. On the other hand, it will take you for while. Sometimes it seems easier to develop a feature by yourself then find a good implementation of it among thousands of modules. Though some of contributed modules are made really felicitous and got sort of standards ‘sui generis’. Let’s say, Content Construction Kit (CCK) . By default, for a node Drupal provides only title and body fields. CCK allows you enhance content types with fields of various types. You can find ready rich controls for CCK. For example:

Also I would like to mention jQuery Update module that fix the fact Drupal 6 is based on old stripped version of jQuery. A good one is PathAuto Module , which allows auto-generated node URLs (on default it's node/xxx, but can be aliased automatically as news/xxx or /section/news/some-title-here).

You see Drupal is a very flexible framework for a CMS. It has its lacks though. For instance, default administrative content management UI is confusing and not useful. But let’s think positive, you can always to plug-in and customize it.

If you ought to build a new site and don’t have time to develop a CMS, you’ll likely take an open source solution. And likely it will be Joomla or Drupal. They seem as most popular. Actually they are similar in many ways. Both provide basic content management frameworks, extensible through plug-ins and customizable via themes. Both focused on block-designed sites which can be often built without any programming at all, just using downloaded theme and configurable set of extensions. So it’s personal what to choose. I prefer Drupal. Its component model seems clearer to me. The documentation is much more explicit then Joomla’s and gallery of ready-to-use modules is really impressive.

Who's the dude?

Dmitry Sheiko is a web-developer living and working in Frankfurt am Main, DE