Drupaler.co.uk
Six Reasons To Get A Handbook Page For Your Module
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.
Nodes As NIDs
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?)
Creating A Set Of Fields In One Swell Foop
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) {
The Contrib Conundrum
Edit: Please read this blog post, but also please jump in on this thread - the idea is already proposed but needs community support:
http://drupal.org/node/484034
And so again today it happened, as it does so many days. Someone needs to be able to do something. They Google. They search Drupal.org. They find nothing but a few open issues or an unsuitable/unsupported contrib module. They're a developer, so after an hour of searching they think "ach, to hell with this - I'll just write something".
Translation: Proving Complicated
Editor's note: Joachim appreciates this may be a bit of a rant, and hopes people who read this and know more about the translation of Drupal than he will contribute via the Comments and tell him why he's being an idiot. But we decided to run with it because he makes some really valid points. I don't know if the translation interface was a part of the UI work for Drupal 7, but reading Joachim's experiences, I would hope so!
Rant starts here:
Small Core, Big Drupal, Tighter Contrib: Outer Core?
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.
Altering A Views Query: Tackling The Node Type Filter Bug
I happened across a wee bug in Views 2 today. I think I've noticed it before, and I'd be a monkey's uncle if it isn't already in the queue, but this is a synopsis:
If you expose the Node Type filter in Views 2 and set it to "Optional", but also with "Limit list to selected items" checked, you might expect it to continue to restrict the results to the selected items it refers to, right? (Well I did.) It does not. If your use selects the "< Any >" option from the resulting UI they will get *everything*
Doh!!
Cleaning Up Node Edit Forms
Every time you build a new application in Drupal you *always* have to carefully govern the number of options available to normal site editors, or their heads will explode. (Literally. I've seen it.)
Almost every module you install will put something more on the node forms, until you end up scrolling forever just to reach the Save button. Not to mention most of this stuff you won't want them playing with anyway.
Drupal 6.x And Ubuntu 8.04 (Hardy)
A few weeks ago I wrote a post about how to bring a stock CentOS 5 server up to spec to run Drupal 6. It seems only fair I do the same for Debian and Ubuntu, since it seems they too are not without their little issues when a stock install. This quick post was written after configuring a server running Ubuntu 8.04.2 (or Hardy Heron, as it was codenamed).
The first (and main) problem with a stock Debian install is it does not include the necessary GD support for manipulating images. There is a long internal squabble in the Debian ticketing system here:
Do We Have To Put Corks On All The Knives?
Yay! My first blog post with the 7.x tag! It's coming up fast, folks... Shame this one is a gripe.
Courtesy of an issue I raised some months back regarding the update system registering updates in the system table, even if they fail, I came across an interesting and (IMHO) bad decision regarding update.php in Drupal 7:
http://drupal.org/node/595550
Sometimes The API Just Won't Do It
So I've been having lots of fun (read: horrible pain) this week thanks to some quirks of Drupal that only really present themselves when you are looping through, loading, saving and manipulating nodes quickly. The scenario for this sort of thing is normally (yup, you've probably guessed it) importing.
Theming Ubercart, Some Tips And Tricks
First, a note on "compatibility" (for want of a better word). This piece is written after some extensive theming work in Ubercart 5.x-1.7. Much of this is still useful information for the Drupal 6.x version of Ubercart, but it may not be wholly accurate.
I should also note that this is not really a hand-holding step-by-step piece. It's more for people who are already pretty familiar with theming Drupal and just want to know where to look.
Drupal 6.x And CentOS 5.x
This is more a bookmark for my reference than anything, but if you have a stock CentOS 5.x installation (maybe from a VPS image or a clean install on a dedicated box) you're going to have issues with Drupal 6.x.
It comes down to PHP version. It ships with PHP 5.1.6 and Drupal these days pretty much depends on PHP 5.2.x upwards to work. Utilities like Drush do too, so leaving PHP as it is, you'll find, is not really an option. To confirm you will have this problem, execute this command to check your PHP version:
$ php -v
Framework, Product Or Both?
Ask any Scottish whisky maker, distilling is not an easy process. Only when the hot gases cool can you see the real results of your labours. And (in the case of whisky, at least) you often have to leave the resulting liquids to sit for a long time, observing them carefully and testing them regularly, to get a really perfect product at the end.
This Author Sees A Long Drupal Slope
I'm prompted to write a post that is a bit less technical and more of a muse on the state of the Drupal project. Anyone who follows the community will know much is made of a developer/designer divide. To be honest, I still don't quite get why this is. I don't personally feel it.
Never Write A Line Of Code Again!
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.)