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:
On the development domain, all worked fine. On the subsite domain, nothing.
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?
This (fairly long) one-liner counts the number of implementations of each hook in your Drupal installation:
ack "Implements? hook_" | perl -e 'while (<>) { m[(hook_\w+)] and $hooks{$1}++; } foreach (keys %hooks) { print "$_ - $hooks{$_}\n"; }'To count only install file hooks, which was what I was doing, give ack the option "-G '.install'" thus:
ack "Implements? hook_" -G '.install' | perl -e 'while (<>) { m[(hook_\w+)] and $hooks{$1}++; } foreach (keys %hooks) { print "$_ - $hooks{$_}\n"; }'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:
Is it just me who finds this poor style and potentially confusing:
<?phpfunction 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?)
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) {
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.
Okay, so I lied. But module builder can save you a lot of time when writing custom modules.
And it now works with drush, too. I added support for drush a few weeks ago, which let you do things like "$ drush mb mymodule cron init menu nodeapi --write" and hey presto, a new module folder is created, with an info file and a module file, with hook implementations ready to do your (evil) bidding. (Note: this blog does not sanction use of Drupal, module builder, or drush for evil.)