Add this blog to Del.icio.us, Digg or Furl | Create Watchlist for this blog

Archive for the ‘Admin’ Category

Drupal localization and string adjustment

Monday, September 17th, 2007

Sometimes when setting up a drupal site, the situation appears, that I need a “special translation” for a standard module. I.e. I need a blogging functionality - but I don’t want to call the system a “blog”.
That’s when I need a customized translation of the blogging module. This article is about how to customize drupal strings with the localization feature.

Find the strings to translate

What you need first the the GNU gettext package (it’s contained in every linux distro). From this package you need the program “xgettext”. This program is able to extract the strings from the module code that can be translated (if the module is programed very well, this should be all strings in the code).
Now go the the module’s location (usualy /modules/blog) and type:

xgettext.exe --keyword=t -L PHP blog.module

The L tells xgettext, that this code is PHP code, the keyword tells xgettext, that function “t()” is used for gettext translations. The output of xgettext is by default a file called messages.po. This file contains all translateable strings of blog.module.

...
#: blog.module:137
msgid "Post new blog entry."
msgstr ""

#: blog.module:140
msgid "You are not allowed to post a new blog entry."
msgstr ""

#: blog.module:178
msgid "RSS - blogs"
msgstr ""

#: blog.module:222 blog.module:257
msgid "Blogs"
msgstr ""

#: blog.module:239
msgid "@username's blog"
msgstr ""

#: blog.module:261
msgid "My blog"
msgstr ""

#: blog.module:277 blog.module:286
msgid "Recent blog posts"
msgstr ""

#: blog.module:285
msgid "more"
msgstr ""

#: blog.module:285
msgid "Read the latest blog entries."
msgstr ""
...

Translate the strings

Keep each string in messages.po that you want to translate, delete the one’s you don’t want to translate, rename the file to i.e. myBlogStrings.po. Now put your translation of each string into the “msgstr” field.
I.e.

#: blog.module:222 blog.module:257
msgid "Blogs"
msgstr "Articles"

#: blog.module:239
msgid "@username's blog"
msgstr "@username's articles"

#: blog.module:261
msgid "My blog"
msgstr "My articles"

Then save the file myBlogStrings.po.

Activate the drupal localization module

Go to Administer / Site building / Modules and activate the “Locale” menu.

Import your “translation” of the blog.module

Go to Administer / Site configuration / Localization and choose “importing a translation”.
Use the file selector to choose your “myBlogStrings.po” file, choose to import to your current language (most times it’s english (en)). And check “Strings in the uploaded file replace existing ones, new ones are added”. Then import the strings with button “import”.

You’re done, your blog is now a article collection.

Things to watch out

The character-set of your file must be correct (i.e. UTF-8). That means, you need an editor that’s capable of saving files in UTF-8 (I use PSPad) and don’t forget to change the CHARSET in line “Content-Type: text/plain; charset=CHARSET\n” of the xgettext program’s output.

Five most important drupal modules

Sunday, August 26th, 2007

drupal rules Drupal ships with a lot of necessary modules like Blog, Forum, Taxonomy, Poll, Locale …
They do most necessary tasks when building a website. But some modules I frequently need are provided by third parties.

Here is my list of five important third-party modules when building a site with drupal:

  • CCK - The Content Construction Kit allows you create and customize UI fields that can be added to any content types (Example: When building a song review database you could add a field like “Best top-ten rating” to your song-review content type.).
  • Views - The views module provides a flexible method to control how lists of content (nodes) are presented. It is essentially a smart query builder that, given enough information, can build the proper query, execute it, and display the results - including but not limited to CCK fields (Example: Create a node that displays song title and best top-ten rating).
  • Google Analytics - sophisticated integration of google’s urchin tracker code for your drupal site.
  • Google AdSense - Very good integration of Google AdSense for drupal. Allows grouping by ad format and utilization of Google’s ad channels.
  • Meta Tags - Even if Google ignores meta, it might be important once. At least there’s no harm. This module allows you to set some meta tags for each node, view or panels page.

Other webmasters, other opinions, so here are some links to several drupal module top lists:
Troy Schneider’s top ten
Daan’s list of used drupal modules
A SEO view on modules from fiLi
And 5 musts from Keith’s marketing perspective

Running tons of development servers on one linux host

Sunday, August 5th, 2007

I drive about 25 domains with different technologies like wordpress, drupal, b2evolution, lussumo vanilla, phpCMS etc. Most of that need a typical LAMP. That is a Linux, an Apache, a MySQL and a PHP. It’s common sense to have kind of test systems, systems where you can test your development work before bringing it up to production. For that I use one linux machine running OpenSuSE Linux 10.2 (basically some partitions on my laptop I use with a boot manager).

Goals of the development and testing environment

There are several goal to be met by my dev-env:

  • Having production-near environment (Tools, Versions, OS)
  • Having same code for testing as in production
  • Having production-like network structure
  • Having a permanent installation

How to setup lot’s of virtual servers on the development host

My first and most important hint: Don’t use yast2 for setting up the virtual apache hosts. That module is still buggy. Use it only to set up apache the first time.

Prerequisites

I assume you have apache2, MySQL4 or MySQL 5 and PHP4 or PHP5 up and running. All you need now is a virtual host, a new database and a new database user to run the dev-env. What you get from your production hosting provider is a domain, a database server, a database name and a database user.

Example: www.geekland.de

As an example I use my domain geekland.de. It is hosted by 1&1 and has the following attributes (not really exactly these :-) ):

domain: geekland.de
db-host: db1234.1und1.de
db-user: dbo12345678
db-pwd: qwertz123
database: db12345678
CMS: wordpress 2.1
Tools: PHP5, MySQL 5, Apache 2

Setting up the local development domain

Because I don’t want to mingle the real domains, I use a TLD “.test” on my local machine. For the example that means, I set up the domain “geekland.test” on my host.

Setting up a virtual network interface

That’s an easy task within unix. As root use

ifconfig lo:1 127.0.0.2

and add in /etc/hosts

127.0.0.2 geekland.test www.geekland.test

Starting an apache virtual server on this virtual interface

Add the virtual server in your apache’s httpd.conf file:

NameVirtualHost 127.0.0.2
<VirtualHost 127.0.0.2>
ServerName www.geekland.test
DocumentRoot /srv/www/vhosts/geekland
</VirtualHost>

Now put your htdocs file into /srv/www/vhosts/geekland and don’t forget to restart your apache!

Create a database on your local MySQL server

Login in to your MySQL server via mysql command, then issue the following command:

CREATE DATABASE `db12345678` ;

Create a database user on your local MySQL server

Now create a database user and grant login rights:

CREATE USER 'dbo12345678'@'localhost'
IDENTIFIED BY 'qwertz123';

GRANT USAGE
ON * . * TO 'dbo12345678'@'localhost'
IDENTIFIED BY 'qwertz123'
WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0
MAX_UPDATES_PER_HOUR 0
MAX_USER_CONNECTIONS 0 ;

Now grant special rights (all) to the new user for the new database:

GRANT ALL PRIVILEGES
ON `db12345678` . *
TO 'dbo12345678'@'localhost'
WITH GRANT OPTION ;

Alias the DB-Server to localhost

As I don’t need any access to the hoster’s DB machine db1234.1und1.de. I alias that host to my localhost. With that simple trick I can use the same config (like wp-config.php) file on my dev-env as on the production environment.
In /etc/hosts modify the localhost line to contain the DB Server:
127.0.0.1 localhost db1234.1und1.de

Now you’re done. You can use all the same files on your production plattform and your development plattform now. The only thing you need to take care is to change the top level domain if necessary (i.e. in DB dump files of wordpress).

The next project

Your next project can be set up in exactly the same way, just change the virtual interface to lo:2 127.0.0.3 and the apache config accordingly.