Archive for Computery

Drupal discovers the world of public-access wiki editing

200811192054.jpgThose wonderful people in the Drupal community have been awesome citizens and have stepped up to the plate after the Drupal documentation team opened the doors for anyone to contribute to the official online “handbook” documentation.

The previous situation only allowed certain individuals to edit pages, so if while strolling along through the pages you happened to notice an inaccuracy or something you thought you could explain better you had to either write a comment or email the person in charge of it.

Now, after a month-long experiment has worked out nicely, the powers that be have decided to leave the open-editing on so everyone can benefit from the continued goodwill.

Yay! :-D

Comments

Learn Drupal by practice, itterations

I’ve found that web development as a whole works best by iterative development, using many concepts from Getting Real and other agile theories. This is definitely true of Drupal. When you start off with Drupal you’ll start building content types, views and panels galore, and there’s nothing wrong with this, it’s the best way of getting your ideas out so you can see how they work. You’ll also then start dipping your toes into other modules and then writing your own, using books and documentation along the way. Good times.

The thing to remember is to revisit your previous work and improve upon your work: export views to files to speed them up and add an element of revision control; rewrite some clunky SQL queries with improved architecture and views; merge two modules you wrote before and make one that’s better; add extra text to node titles for improved search engine accuracy; clean up the CSS and views to work faster and produce more sane output. And on and on..

There’s lots to do, lots to learn, don’t stop!

Comments

Drupal modules: release early, release often (please)

Something I see quite a good amount of with Drupal modules is a tendency to hold onto fixes committed to CVS for some time. I believe this is counter productive. While yes, it is good to hold onto new, big features until they have simmered for a while and proven to be stable, smaller updates and especially bug fixes, should be rolled out regularly.

A case in point is my recent discovery that certain letters can break customized Views if you use the APIs to change the query from an equality statement to an approximation / SQL “LIKE” statement. The wizard that he is, Earl Miles, who is the lead developer on some of Drupal’s most powerful modules including Views itself, took time out of his busy day and replied to my post with a link to a discussion on drupal.org which even included a patch to fix the issue. This was totally wonderful, expected, and I truly appreciate Earl’s efforts for doing this.

The frustrating part for me, though, is that Earl himself provided the first patch for this issue back on September 5th, 2007. A whole fourteen months ago! And it still hasn’t been rolled into an official release. A known bug, with a patch available from the main author itself, sits unreleased for a year? That’s just a little bit crazy.

I believe that the Drupal development community needs to get real and become more agile with their code releases. An active project should not sit for over a year with no releases, there should have been several releases, if only bug fix point releases (Views 5.x-1.6.1 anyone?). And if the project teams can’t handle the added workload, perhaps they could ask for some help? I honestly believe this would greatly help the community.

Comments

Drupal views queries don’t like “silly” arguments

I had a weird problem with Drupal the other day.

I’m using a module I wrote which uses the views_query_alter() hook to change a views’ query from doing “node.title = blah” to “node.title like blah” for a super-simple search engine. Should be simple enough. Well, it turned out that people testing it were having erratic results depending on what they tried to search. At first it was thought that the search was not being case insensitive because searching for “silly” returned no results while searching for “Silly” worked fine, but the database tables were configured correctly (MySQL, table collation set to “utf8_general_ci”), so it had to be something else.

The original query WHERE statement was “node.title = ‘%s’”, so I wrote a function that looked something like this:

function mymodule_views_query_alter(&$query, $view, $summary, $level) {
if ($view->name == ‘mycustomsearch’) {
$query->where[2] = “node.title like ‘%%%s%%’”;
}
}

Normally this would be processed by the Views module and would turn the query WHERE statement into “node.title like ‘%silly%’”, which is what we wanted. Except that in certain circumstances it wasn’t happening like that.

After some digging, thanks to the Devel module, I discovered that the query was actually ending up as “node.title like ‘nodeilly%’” if the word entered was “silly”. You’ll note, first off, that instead of the first percentage sign it says “node”. You’ll also note that the first “s” is missing. As soon as I saw this I realized what was going on - somewhere the Views module was ending up with the string “node.title like ‘%silly%’” and for some reason the “%s” part was getting replaced with the table name, i.e. “node”. Go figure.

So then came the fix.

As I was in a slight time crunch I didn’t feel I had the time to dig further unto the Views code to work out a fix, so for now I just searched for alternative SQL syntax. This seemed odd to me, though, as I was basically looking for another way in MySQL for doing an SQL “LIKE” statement. As it turns out, there is another way - regular expressions.

MySQL supports a set of commands for doing regular-expression-based comparisons using the command REGEXP or RLIKE (one is an alias for the other). The syntax ended up like the following:

$query->where[1] = “node.title rlike ‘.*%s.*’”;

Before I could unleash that upon the world I wanted to filter the input a bit more to avoid potential for security problems. In a rather heavy-handed fashion I set the input string to be filtered as follows, which only allows numbers, letters and spaces through:

$query->where_args[4] = ereg_replace(”[^A-Za-z0-9 ]“, “”, trim($query->where_args[$]));

Putting it all together I finally had a search engine that finally let people search for the word “silly”. Go figure.

Note: I do intend delving into the code to work out a hopeful fix for the root problem rather than a workaround in my module, but I felt completing the project sooner was more important than having a 100% correct fix, which will come later.

Comments (1)

Overriding CSS can be a pain

One of the difficulties with Drupal is that with so many modules needed to make a good site you can end up with a dozen or more different CSS files. On occasions when you need to tweak the CSS to match a specific design, or fix something for IE6, it can take quite a while to dig down to the exact definition you need. You might try throwing random snippets of CSS at the problem to try to make it go away, but they usually won’t work.

What I’ve found is that to successfully override CSS you have to repeat the exact same definition as the original, no matter how obtuse it my seem. So if you want to override one simple paragraph you may have to assign some pretty strange CSS, eg.:

* html .span-6 {margin-right: 5px;}

If that’s what is already being used, then that’s what you have to do to override it.

It may be a bit frustrating, but following that simple guideline has saved my bacon several times.

Comments

Rails tip: restful_authentication without a username

I’ve personal never understood the point of having a username for web sites when 99% of them also require an email address that is unique to you - just use the email address! In the world of Rails development many developers use the excellent restful_authentication to provide the user login structure, but again out of the box it uses a username. Silly thing. So instead, here’s how to make restful_authentication sit rather happy with just an email address.

The first issue is the create_users migration. By default a :login attribute is added which can be simply removed - yes, that’s it. Next off is the User model. The first part of this is to remove all references to “login” from the validation statements, so e.g. instead of validates_presence_of :login, :email you have validates_presence_of :email

The second part is a little tricker: all methods that use :login have to be changed to use :email, e.g. the encrypt_password() method uses the login to make the security a little stronger, and, more importantly, the self.authentication() method is based off :login.

Once those changes have been done you can proceed to the next step. The next step is to update the views, both the users/new.rhtml and sessions/new.rhtml files need to tweaked. For users/new.rhtml just remove the paragraph that has the login field and you’re done. For the sessions/new.rhtml file you need to replace all references of “login” to “email”. The final part is to update the sessions controller, and once again just replace “login” with “email”. That should do it. Now load up your app and enjoy simpler authentication!

Bonus Tip:

Now, make your user model even more useful and add first_name and last_name fields to the migration and app/views/user/new.rhtml file. One little thing to watch for - due to how restful_authentication works you’ll want to also add those two fields to the attr_accessible line in your User.rb model file. Other than that, you’ll make life much easier for both you and your users.

Comments

Problems with Drupal 5 - database table sequences/counters

A key design flaw in Drupal 5, especially for anyone dealing with large quantities of data, is that it doesn’t use the database’s built in auto-incrementing counters for its table primary keys, instead it manually tracks an per-table integer in a table called “sequences” which is updated each time new records are added. This is a bad design in all sorts of ways and really should have died a horrible death many years ago. Unfortunately it has still made its way through to v5 and is guaranteed to pose problems for anyone trying to peek beneath the surface of this really awesome CMS.

Thankfully, as with many Drupal 5 shortcomings, this has been fixed in Drupal 6. Now all tables have an automatically incrementing counter, if needed, that is controlled by the database. Now we don’t need to worry about multiple record insertions conflicting, the sequences getting out of sync, or set them to do weird things like jump by two or ten instead of the default of one (occasionally useful). Or just because it’s one less thing for developers to worry about, therefore less likely to cause a bug.

Comments

Bug in Drupal Panels v2.0rc1a to watch for

There’s a bug in Drupal module Panels v2.0rc1a which you may need to keep an eye out for. If you happen to be using the default_panel_minis() hook to programmatically load minipanels you won’t be able to edit or export the minipanel once it has been loaded:

The only way I’ve found to work with the minipanel from that point is to paste the exact same code from the default_panel_minis() hook into the importer. A bit of a bug, you might say.

I haven’t tried any of the other default_panel hooks, but the minis one does at least exhibit this problem.

I’ll post a follow-up if I find a fix someone else has committed or end up doing one myself.

Comments