drupal5

This may be old hat to some of you, but it was a near-revelation to me (and tough to find through Googling) so I thought I'd share it and potentially save others some hair pulling.

If your Drupal 5 site goes crazy when you turn on CSS aggregation, try examining your stylesheet(s) for absolutely-addressed url()s. There was (and is) a bug in Drupal 5's CSS aggregator code — since aggregated CSS has to live in a different directory from the original stylesheets, all those URLs have to be rewritten. The function that rewrites them expects them all to be relative, though. So:

background-image: url(/sites/all/themes/zen/xxx/images/something.gif);

gets turned into:

background-image: url(/sites/all/themes/zen/xxx//sites/all/themes/zen/xxx/images/something.gif);

That's obviously no good. Instead, simply make sure that your URLs are all relatively-addressed:

background-image: url(./images/something.gif);

That should be rewritten properly by the aggregator.

The more complete solution, of course, is to fix drupal_build_css_cache(). There is a patch available, but since the issue has been more thoroughly addressed in Drupal 6 and 7, not much attention is being paid to fixing it in 5. And that's probably okay: in most cases it's going to be quicker and easier to simply edit your stylesheet to use relative paths. It's best to avoid patching core when possible, and this is no exception.

Out of all the modules in Drupal Core, Profile has always seemed me to be the most half-assed. It's clear that something needs to happen to it — using CCK field types at the least, maybe removing profile data from the user object, and, if I had my way, permanently node-ifying users. I haven't poked around Drupal 6 as thoroughly as I ought to, but based upon what I've heard from Phil's writeup and the Lullabot podcast, I may have to wait a bit longer to see meaningful change come to Profile.

So others may find themselves in the situation I did yesterday for a bit longer: trying to embed a profile form somewhere that Profile.module doesn't think it ought to go — for instance, yesterday I needed to let users edit their name and address on their user_profile page, rather than expecting them to mess around with a bunch of tabs and only-vaguely-different categories.

You'd think there'd be a way to call drupal_get_form() to collect your users' addresses and names whereever you might care to. But you'd be wrong, so far as I can tell — profile.module acts as a user.module parasite, accomplishing what it does through hook_user() and the abuse of arg().

But it's very easy to re-wrap Profile's form-generating functions in your own module and then call drupal_get_form() against it. Here's the example that I came up with:

At last! The answer to a persistent problem that's been stymying my Drupal 5 efforts. First, some brief background for the non-techies:

A very common way of developing code for use on the web is to run a local copy of the site on your own machine's webserver while tunneling traffic to a central development database. The dev writes his code and saves it on his machine. He then points his web browser at his own machine. The web server picks up the request and runs the code. Whenever it needs to talk to the database, it does so by talking to a central DB server over an encrypted tunnel. This is made possible by SSH, a handy program that can let you securely pipe TCP traffic between servers like magic.

This is useful because when multiple people are working on a site, it's important to be able to combine their work while simultaneously preventing them from stepping on one another's toes. There are a number of well-developed tools for combining files within a project (we use Subversion). But it's very hard to have people work on separate copies of a database and then combine their work into something useful. It's much easier to just have everyone work off the same development database. It's also not as big a deal, because if someone makes an incorrect change to the database it's generally less likely to negatively affect other developers (well, unless they did something really unwise). Tunneling makes it easy for devs to keep their code separate and their databases unified.