Administration

Admin
Perhapse the mose confusing part when first starting to work with Drupal is the lack of a proper administration section. The “back end” of the web site in Drupal is an integrated part of the site itself. This probably has to do with Drupals history as a community system where all users were able to create content. This is however not the case, for the most parts, when I develop sites.

The module simply named Admin solves this problem and does it beautifully. Admin is developed as part of the new administration interface in Drupal 7. The module rearranges the default Drupal navigation menu and makes it more logical for administrators and also ships with a custom administation theme that makes the admin section of your web site look beautiful as well.

Administration theme
Administration theme is a module allowing you to use your selected administration theme on any page. Good for among other things to get the batch processing pages to display with the administration theme.

Better formats
Better formats adds more flexibility to Drupal’s core input format system. It allows you to set default formats for different user roles and is pretty much a must have if you have more then one administrator/editor on your site.

Trash
This module adds a trashcan for nodes. Nodes can be moved to the trash instead of being deleted and thus can be restored or permanently deleted later on.

Menus, breadcrumbs and taxonomy

Menu block
Menu block if a module for creating blocks displaying only parts of a specific menu. Say you want to display a menu only containing level 2+, then this module is for you.

Menu breadcrumbs
By default, Drupal 6 will use the built in Navigation menu for the breadcrumb. This module allows you to use the menu the current page belongs to for the breadcrumb.

Taxonomy breadcrumb
The Taxonomy breadcrumb module generates taxonomy based breadcrumbs on node pages and taxonomy/term pages.

Taxonomy force all
This module forces the paramter all to the taxonomy listing pages. This corrects the problem of empty pages when using hierarchical taxonomy terms.

Editing and file management

Wysiwyg API
Wysiwyg API module allows you to use client-side editors (a.k.a. WYSIWYG editors) to edit content in Drupal. It integrates your editor of choice (well, almost) with Drupal. Personally I almost always use TinyMCE, a free editor by Moxiecode.

IMCE
IMCE is an image/file uploader and browser that supports personal directories and quota. It’s not the prettiest module out there but it gets the job done. This module can also be integrated with client-side editors to allow for a more intuitive image selection tool when creating or editing HTML content.

I use this module as a file manager and with a bit of tweaking you can get this module to integrate visually with the Admin module.

ImageCache
ImageCache allows you to setup presets for image processing. If an ImageCache derivative doesn’t exist the web server’s rewrite rules will pass the request to Drupal which in turn hands it off to ImageCache to dynamically generate the file.

This is a must have module if you are using a lot of images in your content. It takes one image uploaded by the content creator and transforms it to exactly fit the desired dimensions.

Utility

Google Analytics
Adds the Google Analytics web statistics tracking system to your website. Supports tracking of logged in users and outgoing links.

Backup and Migrate
Backup and Migrate simplifies the task of backing up and restoring your Drupal database or copying your database from one Drupal site to another. It supports gzip, bzip and zip compression as well as automatic scheduled backups.

I wont go into details and tell you about all the hair (of which I have very little) I lost during my search for a way to get ahold of those processing instructions. In the end I used a XPath expression to select the PI. Below you’ll find the code I used.

$doc = new DOMDocument;
$doc->load("document.xml");
$xpath = new DOMXpath($doc);
$nodes = $xpath->evaluate("/child::processing-instruction('xml-stylesheet')");
if(!empty($nodes))
$pi = $nodes->item(0);
print $pi->target;
print $pi->data;

The next problem I ran into was customizing the form error messages, not just customizing the messages but also localizing them. The framework has default error messages defined for all validators you can use with your form elements but they are kind of stiff and I doubt anyone really want’s to use them. It turns out the solution is really simple.

To attach a validator to a form element you normally write something like this:

$textField = new Zend_Form_Element_Text("myField");
$textField->addValidator(new Zend_Validate_NotEmpty());

If you want to customize the message and maybe even localize it you simply init a validator and manuelly set the message via the setMessage method, like this:

$notEmpty = new Zend_Validate_NotEmpty();
$notEmpty->setMessage("You have to enter a value");
$textField = new Zend_Form_Element_Text("myField");
$textField->addValidator($notEmpty);

If you like to localize the error message, replace the setMessage call with:

$notEmpty->setMessage($this->getView()->translate("You have to enter a value"));

It’s just that simple

The Zend Framework offers many ways for you to store your translated strings. It could be an array, a CSV or XML file or you could use gettext which we will be using in the examples below.

First you need an example application, it doesn’t need to be more complicated than a clean installation of ZF with a IndexController and a matching view, and of course the bootstrap.

Ok, so the first thing we will do is to load the Zend_Translate class in our bootstrap, load the language files, and save the object in the registry using Zend_Registry.

Zend_Loader::loadClass('Zend_Translate');
Zend_Loader::loadClass('Zend_Registry');
$translate = new Zend_Translate('gettext', './languages');
$registry = Zend_Registry::getInstance();
$registry->set('Zend_Translate', $translate);

Ok, so what we did here was to first load the classes that we need, the Zend_Translate and Zend_Registry classes. Next we create the Zend_Translate object and pass in the directory containing all of our different languages we will support in our application, in this case we will be supporting swedish and english language. Don’t worry about the language files, I will explain how you create those later on. Finally we save our Zend_Translate object to the registry so we don’t need to create our object over and over again in our application.

The next step is to dive into our applications views to identify the strings we want translated. In our example we only have one view, the index view of our IndexController. So let’s open that up and have a look at it.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Zend_Translate example</title>
</head>
<body>
<h1>Hello World!</h1>
<p>This is a Zend_Translate demonstration</p>
</body>
</html>


Here we have two strings that needs to be localized, so we wrap these strings in a call to the translate object.

<h1><?php echo $this->translate("Hello World!"); ?></h1>
<p><?php echo $this->translate("This is a Zend_Translate demonstration"); ?></p>

Zend Framwork 1.5 ships with the Zend_View_Helper_Translate which makes translating strings easy, before you were forced to translate the strings in the controller or write your own translation view helper.

Now we have made all the modifications to our application that needs to be done to support string localization. Now it’s time to create our translation files, the .mo-files. First thing you want to do is to download Poedit. Poedit is an application that helps you gather all the strings that should be translated from your application and presents them in a interface for you to translate. The program is open source and exists in versions for all major operating systems.

Lets fire up Poedit and try to import the strings. Click File -> New catalogue and a settings windows should appear.

Fill in the settings so it looks something like the above image. Then click the Paths tab.

Here you first enter the base path to your application and then you add the directories in your application that contains the files with the strings to be translated (your views). When your done click the Keywords tab.

Here you enter the name of the function you are calling to translate a string, in Zend Framework the function name is translate ($this->translate(“String”)).

When you’re done click OK. If your setup is anything like mine you will now encounter a error saying the catalogue update failed.

This was expected and happens because Poedit don’t know to look for strings in .phtml files that are used by Zend Framework. Click File -> Preferences and click the tab Code readers. Select the PHP item and click Edit.

Edit the settings so they reflect the settings in the picture above.

Now when you click update the strings that we wrapped in the translate function call should appear in Poedit in a list with the original strings to the left and the translations to the right. Get to work translating your strings and then save the catalogue. I’m keeping all my language files in a directory called languages in the web application root next to the library and application directories.

The application will automatically detects locale based on the HTTP_ACCEPT_LANGUAGE header sent by browsers. It will try to match the available languages to the users preffered language and if no match is made it will use the default language (the strings in your view files). You can customize this to use other methods but that’s out of the scope for this post.

Data returned from the datebase via stored procedures was contaning lots of garbeled data and results from previous select statments. So i turned to Google to find the answer to this strange behavior. Turns out this problem appears when executing a stored procedure contaning a PREPARE statement. Why would one do this you might ask, well it has to do with MySQL inability to handle variables in the LIMIT clause. The only way to do paging with a stored procedure in MySQL is to use a PREPARE statement inside the procedure.

DELIMITER $$
CREATE PROCEDURE paging (IN pageSize INT, IN position INT)
BEGIN
	PREPARE stmt FROM CONCAT("SELECT * FROM table LIMIT ", position ,", ", pageSize);
	EXECUTE stmt;
END $$
DELIMITER ;

Since this problem only occured on the production server the solution was pretty clear, simply update MySQL and PHP to the latest stable releases and you’re fine.

Related links: Bug report on php.net, Bug report on Mysql.com.