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 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.
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.
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:
<?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?)
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.