Nick Lewis: The Blog

Sometimes you need to override more than a theme function: the entire page needs to be overridden. Drupal 6 makes it rather easy to do this.

In the example below, we call hook_menu_alter(&$callback) to override the display of every single node page view.

Instead of returning a node page, we return "[author's username] is great... for me to poop on.".

There is one way to let drupal know about a theme function or template. There are two ways to send variables to a template, but one of them has a lot of disadvantages.

We'll use two theme functions, with an identical template setup to illustrate these methods:

Creating Theme Functions and Routing Them to a Template

There's only one way, hook_theme()

When creating a menu [ admin/build/menu/add ] there's a field for "Menu name". We use that value to load whatever array of menu links we want. In this example, we're using "secondary-links" which comes default on most drupal installs.

Discussion

This is a particularly nice technique to use along with hook_preprocessor_page. You can easily send your menu links to your page.tpl.php file from a module like this:

I reviewed 5 WYSIWYG editor modules for drupal 6: FCKEditor, TinyMCE, WYMeditor, jwysiwyg, HTMLBox. The latter three aren't yet mature, so I saved the in depth reviews for the big guys, tinyMCE and FCKeditor. Truth be told, I decided to have low expectations, and rated these modules against the following:

Spoiler: FCKEditor wins hands down.

1. The plugin is free and doesn't require you to subject yourself to all sorts of nonsense marketing emails to download (sorry xstandard lite, and EditOnPro)
2. It works
3. It works without JS or PHP errors
4. It takes me more than 30 seconds of dummy testing before i screw up its html tags (this is a ritual where I hit the return, and delete keys a lot, select, copy and paste, change cursor location, and basically stress test it against how people actually write.
5. The module authors themselves don't warn against using the editor on a production site
6. Minimized the number of steps required to get the module working.

I tested these modules with drupal 6.4.

Before plunging into the abyss, a shout out is in order for a certain project: WYSIWYG API. This project is taking on the extremely unsexy, and unfun problems that any WYSIWYG js script is going to run into when included into a drupal page. Their roadmap is ambitious, maybe more ambitious than it needs to be.

If you're frustrated with WYSIWYG editors in drupal, I urge you to show solidarity with Daniel Kudwien (sun) and Nathan Haug (quicksketch) efforts. Regardless of whether you agree with particular decisions (i'm on the fence about the fact that it doesn't come with a single working WYSIWYG editor), I think we can all agree its in drupal's best interest to organize community efforts to make the the platform more friendly to WYSIWYG editors as a whole. I hope maintainers of a WYSIWYG modules will let these guys do work for them, instead of fighting them. A sign of to the difficulty of this problem is seen in how many previous maintainers this project has. 

TinyMCE

Tested: tinymce 6.x-1.1-dev

JS: version 3.2.0.2

VERDICT: Once configured, its a solid editor. Recommended for consultants who want to pad their hours with long, byzantine configuration steps. Is likely to make new users hate drupal.

I click on the recommended release for drupal 6, and immediately read:

First functioning version of TinyMCE for Drupal 6. Still has issues. Not recommended for a production site.

At least they've covered their ass...

Lets say you're building a drupal website for Bill's Widget Company. You create a custom theme, and a custom module. Now lets also say you are as dumb as me, and decided to name both your theme and module the same thing: bwc. Its a small mistake you'd never make if you thought for a second: "Should my module and theme share the same drupal namespace?" It sounds dangerous, even if you don't know why. Here's why it is dangerous:

The first sign of trouble happened as soon as I added an implementation of hook_form() "bwc_form" to bwc.module. Not only did my form not work, but NO form worked. All forms returned as "array", and frequently had incorrect data types being passed (stdClass's where there should have been an array and vice versa). It was a bit embarrassing how long it took me to figure out the obvious cause:

Since my theme (themes/bwc/bwc.info) shared the same namespace as my module (bwc.module), the theme system mistakenly interpreted bwc_form(&$node) as an override to theme functions: 1. phptemplate_form, and 2). theme_form.

Hopefully, whoever makes this mistake next will find this answer.

If there is one thing I hate more than breath and martial arts (all kinds...), its writing copy within a php array. So for a recent project that required text-heavy forms, and a bunch of emails, I created an element that mimics php template. The usage and theme function are rather simple: (and rather stolen from phptemplate_render().

Today, I was working with drupal 6's AHAH form elements. Initially, I was delighted at how well they worked. That delight turned to confusion once I realized that the form elements I had put in the menu callback of the #ahah['path'] was missing its name attribute. After doing a bit of research in how the poll module handled the formapi voodoo, I created a generalized function to aid in building AHAH callbacks. If there is a better way to do this, I wasn't able to find it. <?php

On the #drupal IRC channel, Excallibur points out that there are no coding standards for CSS. I'd like to propose some straightforward ones.

Note that I am not intentionally omitting indentation within rules, but am having trouble with my code filter.

I. CSS is not Java.

This java-style of CSS does not make the code easier to read:

It just adds an unnecessary space. Below is the correct way, which is consistent with core CSS.

II. Two selectors = Two lines.

While the following code is more compact, it's also more difficult to scan.

The right way is separate lines.

This small rule can make a big difference in complex themes (ever tried to debug some old civicspace themes?).

III. Single Line Rules

Single line rules are acceptable when there is only one selector and one property.

Can you think of any others? Disagree?

The other day, I was tasked with building a data scraper. Having never built such a contraption, I naturally turned to the Internets for preexisting code. I was horrified with what I found.

The “free” PHP scripts (that’s “free” as in “free baby vomit”) were all infested with the worst sorts of newfangled regex, and PHP 4 era DOM traversing.

Making matters worse, the scripts didn’t offer much of an API, or interface for data mining – rather they provided a rigid, and worthless example – leaving their hapless users to mutilate whatever useful lines they could find, and create an even more horrid fraken-script.*

GOD OFFERED SIMPLEXML, AND IT WAS GOOD

It didn’t take me long to realize that PHP 5’s simpleXML was the answer. And indeed, after an hour of practice, simpleXML turned me into a scraping Ninja.

Below, is a very simple example [for drupal 6] that parses the drupal planet blogroll, and makes this neat little table out of it. Hopefully, you’ll find this method as easy, and useful as I did.

*Disclosure: I am not among the sadistic few that think Perl’s regular expressions are the greatest invention since sex. So you call simpleXML a crutch, and I’ll call you sick.

In our last episode of enabling new modules via update.php, Steve McKenzie pointed me to a better method: module_enable(). A quick test found, however, that it didn't run the install files, and didn't rebuild the module files cache. So after spending 5 minutes in system.module, I found all the missing pieces. The example update function below will install and enable the new module, as well as rebuild all the css, node type, and menu caches. In simple language, it does everything that happens when the modules admin page is submitted. Enjoy.