Aug 14 2012
Aug 14

Drupal's standard node options cover quite a bit of ground: content editors can control the publication date, author name, revision status, revision log message, "sticky" flag, published status, and front page promotion status of every piece of content! Of course, there's no way to give content editors access to just one of those options. If you want an editor to control the "published" flag but none of the others, you're out of luck. It's all or nothing, and the resulting array of checkboxes and form elements can easily overwhelm users who are new to Drupal. Unless, of course, you install the Override Node Options module...

Screenshot of administration screen

Setting up the module couldn't be simpler; a new set of permissions to control access to each of the standard node options, on a per-content-type basis. That means a site builder can give specific user roles access to a restricted content type's options without affecting the others. In addition, there's no need to bring out the sledgehammer option of Drupal's "Administer Nodes" permission for most content creators.

Screenshot of resulting change to site

While it's possible to achieve some of the same results using custom hook_form_alter() code, the full suite of node options requires quite a bit of special logic to override effectively. Override Node Options is a quick, simple solution to the problem, and it makes a great addition to a site builder's toolbox.

Feb 08 2011
Feb 08
Drupal API function argument list Drupal API function name auto-completion

In general I'm a happy vim user, but now and again I am asked why I'm using such an antiquated environment. Editor preference is of course a topic over which many long and pointless arguments have been waged - often from intractable dug-in positions of dogma. I think it's good to poke your head above the trench occasionally and see what else is available.

I suppose the other end of the spectrum to something as lightweight (albeit extensible) as vim is a full IDE such as Eclipse. There are undoubtedly many great things about the Eclipse environment, but I just can't get over the annoyance of my rhythm being interrupted as I type; it feels like it's just trying to do too much for me.

It was in this spirit that I recently gave Geany a try. It's a lightweight cross-platform editor based on GTK, with some basic IDE features.

As a Drupal developer one of the first pleasant surprises was that I didn't need to tell it to treat .module and .install files as PHP scripts - it's smart enough to see the opening <?php tag and give me syntax highlighting etc... straight away.

It does a few simple things which make life easier - code folding if you want, a list of functions in the current file, and the facility to jump to the definition of a given function or constant, or search for the usage of whatever your cursor is over within the current document, or all open documents. It also does simple code completion, auto indentation, and has a tag library of PHP's built in functions. For PHP files, the compile button checks the syntax of the current file using php -l which is particularly useful when working on install or update hooks in Drupal.

Working with Drupal we're often not using built-in PHP functions, but rather those from the Drupal API. It's possible to get some help from Geany here too. Whilst I've seen this done with Eclipse and other IDEs before, this is one of the areas where they can become very cumbersome - for example as they try to re-index a few mb of source files for the project in the background while you're typing. The approach I'm trying out with Geany is more along the lines of using ctags with vim (or emacs).

The idea is to scan through the source code of the project (Drupal core in this case) just once, and make a list of all the function names (and constants if you like) with a few helpful details such as the argument lists. Rather annoyingly Geany uses the slightly obscure tagmanager format for its tags. The docs suggest that you can use Geany itself to generate your list of tags:

So, inside a freshly drushed copy of Drupal6 core, I tried

geany -g /tmp/drupal6.php.tags $(find . -type f -name '*.php' -o -name '*.module' -o -name '*.inc' -o -name '*.install' -o -name '*.engine')

...(using the unix find command to provide geany with a list of all the files with the common file extensions Drupal uses for PHP files).

This produced a file in tagmanager format, which geany was happy to use. This gave me auto-completion for Drupal function names, but it was missing a very useful feature - the argument list (which are provided for PHP's built-in functions).

Luckily Geany supports an alternative tag format - pipe-delimited - which is easier to manipulate than the tagmanager format. There is a contributed tags file available for Drupal which includes basic argument lists, but from the timestamp on the file I think this is probably for Drupal 5.

So how about rolling our own? Looking at the tags file which exuberent ctags produces for Drupal core, and at what we need to provide in the basic pipe-delimited tags file, ctags does most of the work for us.

ctags output

drupal_set_message  includes/  /^function drupal_set_message($message = NULL, $type = 'status', $repeat = TRUE) {$/
drupal_set_title  includes/ /^function drupal_set_title($title = NULL) {$/

geany pipe-delimited format

function_name|return_type|argument, list|

I'm sure someone could come up with an awk one-liner to do this, but I resorted to a quick php cli script.

$lines = file('tags');
foreach ($lines as $line) {
  if (preg_match_all('[function (.*)\((.*)\) ]U', $line, $matches)) {
    print $matches[1][0] . '||' . $matches[2][0] . "|\n";

Unfortunately ctags is not clever enough to give us the return type, which might be there in doxygen-style comments (as will better info about the arguments), but this gives us:

drupal_set_message||$message = NULL, $type = 'status', $repeat = TRUE|
drupal_set_title||$title = NULL|

...which is pretty useful as a quick reminder.

With the addition of the Drupal tags file, I'm finding Geany a really good compromise between the light-weight speed of something like vim whilst offering some really useful IDE-type features for Drupal development. Why not help yourself to the tags file and give it a go.

added after some comments and feedback on IRC:
You can enable the tag files (it only really makes sense to use one of them at a time) by placing them in:

~/.config/geany/tags will also have to rename the files to remove the underscore, as otherwise geany will refuse to use them.

If you have any problems, try launching geany from the commandline with the -v ( --verbose) option.

Attachment Size drupal6.php_.tags 75.68 KB drupal7.php_.tags 185.38 KB
Mar 27 2006
Mar 27

Recently, I've had the pleasure to try out something new - reviewing a book before it is published.

I have been acting as technical editor/reviewer (or whatever that's called in English) for the first German book about Drupal, written by Hagen Graf: "Drupal: Community-Websites entwickeln und verwalten mit dem Open Source-CMS". The book covers the Drupal 4.7-beta series and is a good introduction to Drupal and it's concepts. It's a nice book for people who want to learn more about creating websites with Drupal. More details in this post over at

Reviewing books is a lot of fun - I might do that more often in future ;)

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web