drupal

Basically, an initial patch went in, we opened followup issues for cleanup, the followup issues never got followed up, so what's in HEAD is a bit of a mess. — catch, in a recent issue comment

This happens far too often. I'm not linking to the specific issue in the Drupal 7 queue because I don't want to point fingers; this suffices to exemplify my point.

I wasn't anywhere near the sausage factory back when Drupal 6 was coming out, so I've no idea if this is a problem that's getting worse, but I feel this is a problem that happens a lot, and that it needs to happen a lot less.

I think that our move to distributed version control may help, as we can leave new developments on a branch until everything is cleaned up (and documented!), but as everyone knows, technological solutions are no substitute for good communication and organization.

Ultimately, we need people to take on the roles of roadmappers and project managers.

This is apparently a dirty word; there is a widespread notion that you can't organize volunteers. I can with confidence state that this is utter rubbish, because I've done it, and volunteer organizations around the world do it.

It's maybe harder because it's online rather than face to face (we do it fairly well at code sprints, after all), and maybe harder because we're mostly a bunch of fairly headstrong smart people who are used to managing our own activities (which is one of the things that makes us good programmers). But we clearly recognize the need to be organized on a smaller scale, and the need to work with rules. Managing Core is going to be a mammoth task, of which we are right to be apprehensive, but is it so different to what we already do?

Regardless, it is necessary, and I think we are also of necessity often pragmatists. This is one occasion we need to recognize the need for some medicine that in some cases might not be entirely to our palate.

Spoonful of sugar anyone?

I am now batting nodes, complete with imagefield, between separate instances of Drupal with merriment and glee. For yes, I do have a working beta of Content distribution.

I'm about to quickly write a service to get CCK's content_fields() array from the remote, distributing site, so that the retrieving site can show a UI of possible values for a Views nodereference argument. Try it. It all makes sense once you do.

But I remember a couple of months ago, when Services was a total mystery to me. I installed it, knowing that this was what I needed to achieve this task, but I was baffled by it. What was a Service? And how come I needed a server as well? Surely a service is a kind of server? Argh! And so on.

The penny dropped a few weeks ago, when I suddenly realized that a service is really just another kind of hook_menu() item.

Consider: in hook_menu(), you define which function Drupal should call when it gets an HTTP request at a certain path, say, 'node/1'. And in hook_service(), you define which function Drupal should call when it gets a service method request, in this case via XMLRPC (which is still black magic to me, but with Services module, I don't need to know, because it Just Works). For that matter, in Drush's hook_drush_command(), you define... etc etc. They are all the same!

This has me wondering whether for Drupal 8 we should abstract this out to a general hook_callback(), where we define what function Drupal should call when it receives any kind of external input.

I used to write on Wikipedia, years ago when it was a wild frontier, we had barely 30 thousand articles, and not even my geek friends had heard of it from a source other than my blathering on about it.

It was quick and simple, deserving the origin of its name [1]. And it was quick not just to edit the content of pages, but their place in hierarchies and their order within lists. A whole section of the site that wasn't to our liking could be rejigged in a handful of browser tabs. Pages didn't belong to anyone, but the edit history and the attached talk pages gave you a clue of who was involved, and once you'd made edits to a page you could spot it in the Recent Changes list or your personal watchlist of bookmarks.

Now over to Drupal handbooks, where I find the process slow and laborious and confusing. I ask myself (and you!) — why?

We have Recent Changes of a sort: the tracker; we even have a tracker just for documentation changes, but I forget it exists because it's tucked down at the bottom of the site blocks. We have page revisions and diffs of pages, just like Wikipedia.

The differences I can see are:

1. HTML is slower. I know purists dislike wiki markup, but it's undeniably quicker to type ''italic'' and [[clean URLs]] than to muck around with opening and closing tags and finding the right URL. Granted, there is no one standard (though I would say that used at UseMod comes close) and Wikipedia has now bloated it so much with complex syntax to create all manner of things. But the handful of basic wiki syntax elements are good.

2. Structure is divorced from content. It's very handy the way Book module builds menus and trees for you. But it makes moving a page to another part of a book feel like a big destructive (and irreversible?) act. Furthermore, only a small number of admins can change the order of child pages, something which frequently makes all the difference between a clear read and a mess. On wiki, structure ''is'' content (italics, remember?): you want to make a list of child pages? You write a bullet list of page names. You want to move a page to a different part of the hierarchy? You just find what links to it and edit. Granted, this can often lead to an almighty tangled mess; not for nothing it is the full term a 'wiki-wiki-web' — not a tree.

3. Every article has an associated talk page. One day you find a section has all been changed and you're confused as to why? Find the answer in the talk page. You're pondering a big reorganization yourself, and you want to make sure other writers who are interested in this page get wind of it and have a chance to discuss it? The talk page. It's a bit more anarchic to what we're used to on drupal.org, but it keeps the discussion and the document side by side. I'm only an occasional participant in the documentation team, I'm not on the mailing list[2] and so I often find ''everything'' has been turned upside down and I can't fathom why, and I can't tell if it's work in progress that I should help with or just an almighty mess. Talk pages aren't perfect, and it's hard to follow discussions spread across many places, or even to know if you might be missing something. But there is an immediacy about the 'talk' tab at the top of a page.

4. Lastly, on Wikipedia it felt like there was a collective ownership of pages and sections. On drupal.org, I feel I'm treading on toes if I make too many changes. I don't know why that is; maybe we don't have the critical mass of documentation editors to turn into a community.

In conclusion: I don't have answers. I know that editing and more to the point, organizing our documentation is a big job, and I think the tools are not quite up to the job. As a first step, we should make book hierarchy editable by the documentation team. After that, start upon the inevitable debate about wiki syntax, and think about ways to better tie isues to the documentation pages they are about.

Footnotes:

[1] 'wiki' meaning 'quick' in Hawaiian, coined by Ward Cunningham for the original wiki.
[2] I hate mailing lists. Don't get me started on them. The 1980s called: they want their communication technology back is all I'm going to say.

I had a fun afternoon a few months back when all the imagecache images broke on a site I'd just taken live. I've just figured it out, so I'm telling you about it.

This was the situation:

• subsite.client.com was where I was developing the site, one of a family of multisites.
• subsite.com was a parked domain that went to just this site. It was this I'd just pointed to the IP of the box and that wasn't showing any images.

On the development domain, all worked fine. On the subsite domain, nothing.

The problem is that if you go to admin/settings/file-system you get a different thing depending on the domain! Each time, you get 'sites/CURRENT_DOMAIN/files', and the reason is this function:

So if the files directory has not been explicitly set and you're just relying on defaults, you're getting the wrong one.

I don't follow the internal workings of the file system or imagecache (or even symlinks which I consider dark magic on the commandline) to know if this breaking of imagecache is a bug or not.

But at least this is a ten-second fix on future sites. You'll find me here reading this post when I next have to set one up.

I've been putting off setting up multisite on my localhost for ages, mostly because in the past I've found getting Apache virtual hosts to work can be a bit tricky: not impossible, but the sort of thing where I could easily lose an hour on a minor thing I've forgotten to do. And after all, with a shiny new iMac and a hard drive whose proportions I can't even remember, why not just 'drush dl' all over again?

But I'm actually working on a multisite project at the moment, and suddenly getting this to work becomes more interesting than having another SVN copy of my code kicking around.

Given multisite can respond to subfolders, I was wondering if this could work when Drupal itself is in a subfolder, like this:

Turns out it can. Suppose you want a new subsite called 'drupal-subsite'. Here's what to do in your webroot:

Your lolcathost(*) sees just another subfolder that's a site; the symbolic link sends you to the existing Drupal folder; and finally, the multisite system sees that you're browsing 'localhost/drupal-subsite' and selects the localhost.drupal-subsite folder as the one holding your site.

You can also have your subsite explicitly sit below the main site like this:

In which case your sites folder is localhost.drupal-multisite.drupal-subsite and the symlink should be inside the multisite folder:

So when I next get a moment I'll consolidate the various test sites I have, and when I have more than one patch on the go that I want to keep segregated, I can just add a multisite, get a fresh CVS copy of the code, and get going.

I've added details to the documentation too.

(*) yes, I keep typing it like that.

This (fairly long) one-liner counts the number of implementations of each hook in your Drupal installation:

To count only install file hooks, which was what I was doing, give ack the option "-G '.install'" thus:

You can probably adapt this for grep. Ack is far better though (proper regular expressions and sensible assumptions for starters).

Unfortunately, now I've taken ten minutes to do this, I've completely forgotten what I needed to count hooks for. So I'm posting this so by the time I remember I can come back to it!

Edit: Oh yes. I was generating a list of hooks implemented in .install files (just a list, the count is bonus) to check I'd covered everything in my patch for hook locations in the documentation.

Checkout view being currently disabled in ViewVC is a very good opportunity to remind everyone that linking to your README.txt file in CVS does not count as documentation on your project page!

Here are some things I, or anyone else, can do with a proper documentation page in what used to be called the handbooks section of drupal.org:

• Correct it.
• Expand on it.
• Clarify things for newbies.
• Add a section listing modules that works with yours that users might be interested to know about, thus helping a tiny tiny bit to make sense of the Big Lego Box.
• Share some of the things I've done to theme your module.
• Add to a section on troubleshooting, and hopefully keep some of the more recurring issues out of your queue (or at least give you somewhere to point to in slightly self-righteous manner ;)

In short, with a little bit of seeding (some basic explanations of the concepts of your module and some instructions), you open it up to a whole community of potential writers and editors. Which is a concept we should all be familiar with!

If you say that keeping a documentation book page in sync with your CVS readme file is too much of a hassle (and who said it should be in sync anyway?) then it's because you've not thought about the benefits.

Is it just me who finds this poor style and potentially confusing:

<?php
function my_function($nodes) {
  foreach ($nodes as $nid) {
    // do stuff
  }
}
?>

To me, a variable names $nodes will be an array of nodes -- that is, node objects. If it's an array of nids, I would call it $nids to avoid confusion about what we have there.

I'm curious if other people agree (in other words, is it worth my time writing a patch for core or will it just lead to bikeshedding?)

In general, though, I think it's a good idea for variables to be named in such a way that describes what they hold; also for the same data to have the same variable name as it travels through functions. In other words, avoid this:

<?php
function foo() {
  bar($ponies);
}

function bar($caterpillars) {

}
?>

Unless there's a good reason, say if bar() is generic and can accept any animal. In which case, call its parameter $animals, obviously.

Situation: you need a heap of imagefields that more or less have the same setup. Let's not go into why.

You could spend half an hour bored witless clicking through the interface.

Or you could create just the one field, export the content type with content copy, and then doctor the code a little before importing it back in. Like this....

<?php
// The usual content type stuff here.
// Set of image fields
$image_fields = array(
  'field_image_1' => 'Image 1',
  'field_image_2' => 'Image 2',
  // etc
);

foreach ($image_fields as $name => $label) {
  $content['fields'][] = array (
    'label' => $label,
    'field_name' => $name,
    'type' => 'filefield',
    'widget_type' => 'imagefield_widget',
    'change' => 'Change basic information',
    'weight' => '-3',
    // the rest of your field export code here
    // don't forget to fix the brackets, as export code
    // comes out as a numerically keyed array.
    // and don't forget the closing }!
?>

Hey presto, heap of fields created in one go. Don't forget to set their weights nicely afterwards.

I've been mulling this idea since Paris, trying to figure out the best way to present it.

But basically:

We want a smaller, slimmer, efficient core.
But we also want Drupal to, like, be useful.
We want contrib, at least the high-use end of contrib, to be smoother, more organized, released on time with core.
It's been suggested we have a contrib maintainer, who would have the unenviable task of managing a huge kaboodle.

So on the one hand we want to move things out of core, into contrib: things like poll, blog, even forum and profile. However, moving out to contrib is currently recognized as being a death sentence for the code itself, and dooming users to the curse of a million Lego bricks (to quote webchick).

On the other hand, we want better underpinning for the contrib modules that really make Drupal what it is: views, CCK (what's left of it out of core), panels, flag, voting, token, and so on.

These two things actually seem the same to me: define an Outer Core. This would be a fairly loose collection of modules, not simply the 40 most popular, but those that provide important functions, play well together. Outer Core would get a maintainer or two, to ensure good use of APIs, generalization and abstraction of common code where possible, no duplication of code or features, and plan releases.

Drupal the framework would be just the core.
Drupal the product would be core + outer core. We'd release both simultaneously, available as a single download.

End result, I hope: we tame a sizable part of the Big Lego Brick Box.