Dave Reid

Today I'm pleased to share that Dries Buytaert, the project lead of Drupal has invited Oliver Reid to become his first Drupal 9 co-maintainer, and Oliver has accepted! For the duration of one release cycle, he will help Dries coordinate Drupal 9 development.

Dries is quoted about his new co-maintainer and the direction of Drupal 9:

While Oliver hasn't been involved with Drupal as long as most contributors, he brings our community a fresh and newborn perspective of Drupal and our processes. What he lacks in fine motor skills, he makes up for in his creativity and ability to just bang at a keyboard for several hours straight. Some of his code is just so complex but perfect that even I have a hard time understanding it! His experience with working with other babies will really be useful for helping hash out disagreements in the issue queues.

Yes, some people think I'm crazy for selecting a baby. With our newer contributors getting younger every year, Dmitri Gaskin being a great example, I asked myself, why can't we push the boundaries and find someone even younger? And how can you resist that cute, little, squishy face? Who's a good maintainer? Oliver is! That's who!

One of the aspects that I like best about Oliver is that his schedule is pretty wide open for the next couple of years. Finding a new core maintainer is always a tough choice, especially when all the top candidates have full-time jobs, families, and responsibilities outside of Drupal. Even though Drupal 8 hasn't been released yet, it was important to me to select someone who is able to take over pretty much everything I do and has the free time to do it. Except during his nap time. Maybe even mandatory naps would be a good thing to implement when things get heated in core development... Hrm, I'll have to think about that.

Drupal 9 will become a great platform for our future, especially in his tiny little hands.

Congratulations Oliver! Read more

I have been a big fan of the Tomato open source firmware for my Linksys WRT54GL wireless router (why still just 802.11g? I don't need higher wireless speeds since most of my work happens connected via 100 Mbit/s ethernet). When I updated to Ubuntu 10.10 on my desktop, which has IPv6 enabled by default (and will not connect to any network connection without IPv6 - going IPv4 only has been its own separate challenge), I went to go check if there was an updated version of Tomato. Unfortunately not. There as not been a new release of Tomato since June 28, 2010 (HOLY CRAP 15 months seems forever). The project is essentially dead. Read more

Now that everyone should be getting comfortable with Git (even me, one of the crazy people that actually liked CVS), we're all finding little tricks and tips on our workflow. I wanted to share some Git aliases I figured out today with everyone, and I'd encourage you to share your own as well!

When working on core issues, I have only one core checkout per major Drupal version. For Drupal 8, that directory is ~/Sites/drupal8dev. When working on an issue, I create a local development branch with the name issuenumber-description-of-issue. For example, for http://drupal.org/node/1174630, I ran git checkout -b 1174630-html5-url-element to create my local issue branch. Read more

Oh hey there. It's been more than a week hasn't it? Well shoot. Here's part two of my (now semi-) weekly series about a 'helpful lesser-known Drupal 7 functions' (HLKD7F Of The Week). I'm sharing fun Drupal 7 tidbits that I've discovered along the way; because even though they are obscure, they can be very helpful as a module or core developer.

Now I present... *drumroll* ...
element_get_visible_children()

Given a form or render-able page array element, it will return an array of the keys of the visible children 'contained' inside the element. It knows what sub-elements there are by use of the also-handy element_children() function. Typically you would use this for fieldset and container elements (the latter being new to Drupal 7). The return value can easily be cast into a boolean TRUE/FALSE value for use with '#access' properties.

Real world example

The Override Node Options module (led by timmillwood, and co-maintained by joachim and myself) makes a good example for how to use this function:

By selectively setting access to elements in node form's fieldsets, it would not be good if we hide all of a fieldset's elements, but still display an empty fieldset. That would be confusing. So for each fieldset the module alters, it also checks to see if there are any visible items left. It use the boolean OR operator (|=) on the Authoring information fieldset's access property because node.module's node_form() already defines $form['author']['#access'] = user_access('administer nodes'); and we want to only see the fieldset it if either the original access value is TRUE or the return value from element_get_visible_children() is TRUE.

In this case, here's is how the function gets its results:

Best practices with hiding items

The above code from Override Node Options also highlights some best practices when you want to 'hide' elements on a form or page array. You should always use $form['myitem']['#access'] = FALSE; rather than unset($form['myitem']); as other modules that are altering the same form or page may also be altering that same element. When you use unset() the array no longer exists, so it would cause a PHP notice if a later form alter tried to do something like $form['myitem']['#title'] = t('My changed title');.

Add visibility checking by default for Drupal 8?

Maybe we should add a core patch for Drupal 8 to automatically check element_get_visible_children() before any container elements are rendered? Once a form has been altered it would be silly to output an empty fieldset, and it would be nice to not have this burden placed on every module that alters forms or page output. Read more

Today chx and timplunkett inspired me to start a regular, short weekly blog post about my experience and knowledge with 'helpful lesser-known Drupal 7 functions' (HLKD7F Of The Week). So I'd like to start sharing these fun Drupal 7 tidbits because even though they are obscure, they can be very helpful as a module or core developer. So with that short introduction, I present... *drumroll* field_get_items().

Trying to get the raw data from a node's field can be confusing and complicated; field data is stored at least two levels deep from the entity object itself. For example, a simple taxonomy field stores its node data on the node object with the following structure:

We cannot know for certain that the data in the 'field_tags' array is always associated with the unknown language ('und'), so this is where field_get_items() comes in handy. All we need to provide it with is an entity type, the entity object itself, and the field name and it will automatically determine what language the field's data is and return the array of items for you.

Results:

It's important to note that if the specified entity has that field attached to it, but does not currently have any data, this will return an empty array(). But if the entity does not have that field attached (e.g. if my article content type did not have a field named 'field_tags'), then it will return FALSE. I highly recommend using this function rather than trying to get the values directly using statements like $items = $node->field_tags[LANGUAGE_NONE];. Read more

Hooray! It was way back in April when I was attending DrupalCon San Francisco and the first day I was interviewed by @kentbye for the Drupal Voices podcast. I talked about the various efforts I've been doing with both core and contrib and I felt like a nervous wreck the entire time. Yesterday it was finally published, and I actually think it turned out fairly well. Thanks Kent and all the Lullabots for all their hard work recording and producing podcasts for the Drupal community.

You listen to it here: http://www.lullabot.com/podcasts/drupal-voices-167-dave-reid-on-his-drup...

Attachments: 

DrupalVoices167.mp3

In the last week leading up to the end of the Drupal 7 code slush, there has been a flurry of work and love going into core's Contact module. I'd like to share what has been going on with everyone else.

Anonymous user access to personal contact forms

Contact module provides personal contact forms that allow users to contact other users on the site (e.g. user/1/contact). Unfortunately if you wanted to allow anonymous users to be able to contact users in the same manner, it just wasn't possible. In Drupal core, we should not limit functionality from anonymous users, but rather features should be linked to permissions for the site administrator to choose who can do what.

This feature request was originally posted on April 11, 2006 and was nearing a rivalry with the DBTNG issue for the highest number of comments for an issue. Obviously lots of people were interested in or needed this feature. I'm proud to announce that on the issue's exact three-and-a-half year anniversary, it has finally been committed to core! For those of you interested in this for Drupal 6, I am working on back-porting this functionality into the Anonymous Contact module.

This was Contact module's own personal node/8 so we can finally let it rest in peace. There were tons of people helping with that issue and I'd like to help recognize them. The following users all helped post patches and kept the issue driving: karschsp, matt@antinomia, David Lesieur, Owen Barton, pwolanin, TBarregren, coltrane, mrtoner, deviantintegral, rleigh, swaroopch, and jonhinkle. Several other people helped review: mfer, scottrigby, greg.harvey, binford2k. I could go on forever so I apologize if I left you out.

Official maintainer

I've been posting and reviewing patches for contact.module for a while now and was starting to feel personally responsible for it, so I asked to be added as the official maintainer and it was approved! I'm excited to be helping drive long-needed improvements and bug fixes to a module that doesn't get as much recognition as it's bigger brother modules. I'd also like to thank users gpk and andypost for helping out in several issues. Read more

Note: this is a serious post, but I had to have a little fun and wanted to parody Barack Obama's 2009 State of the Union speech.

I've come here today not only to address the distinguished men and women in this great community, but to speak frankly and directly about everyone's favorite Drupal module, XML sitemap. I know that for many Drupalers reading right now, the state of the module is a concern. And rightly so. If you haven't been personally affected by this module, you probably know someone who has--a friend; a neighbor; a co-worker. But while the module's reputation may be weakened and our confidence shaken, tonight I want every Drupaler to know this: We will rebuild, we will recover, and the XML sitemap module will emerge stronger than before.

So how did things get this bad?

For those of you who haven't had the pleasure of using XML sitemap yet, I think Angie Byron (webchick) and Jeff Eaton said it best:

webchick: "Dear XMLSiteMap module: Please die. And not in that cute, friendly way. I mean I literally hope you get hit by a bus. Twice."
eaton: "Uhoh. Brainstorming a #drupal site assessment drinking game with @quicksketch ... "XMLSitemap? Finish your drink."

The last stable/official release of the module was the 5.x-1.6 version from almost a year ago. There is a 5.x-2.x version that was supposed to fix problems in 5.x-1.6. For over a year, the 6.x-1.x-dev version has been a work-in progress port of the unfinished 5.x-2.x version. Despite there not being any stable 6.x release, there are over 10,000 people using development builds which are buggy, frequently failed on updates, and could not scale to large sites. This of course, leads to several issues in the queue with over 200 replies with recurring themes of frustration and impatience.

Much like the current US/world recession, I can't assign blame to any one person or problem. The current maintainer, Kiam was very active and would keep hacking away at the module, fixing problems, but sometimes introducing new ones. For the 25th most popular Drupal module, there was a lack of regulation (peer code review) that we usually see in other popular or large modules. There was no way to say that a change won't work, or something is a bad idea until after the code had been changed. Some developers that needed a working module for their clients would take one look at the code and issue queue and would promptly run away, seeing no other short-term solution besides writing their own custom implementation. The people who's input and time could help the most did not need or want to help contribute back. Those who did make honest efforts were frustrated with language barriers or misunderstandings. There was no test coverage for the module, which I also can't blame since writing SimpleTests for an existing, largish module which you didn't originally write is really hard. But new features would be added and bugs would be fixed without ensuring that they would work correctly. Read more

I know it seems like a far distance away and as much as you'd like to ignore it, Drupal 7 is coming and it will be awesome. Some ambitious developers have actually started with Drupal 7 version of their modules, but what if you just want to get a little head start? I'll show you a few ways that you can help prepare your Drupal 6 modules now to help make life easier when you full port to Drupal 7 later on. To see a list of all the current 6.x to 7.x module changes, view http://drupal.org/node/224333. Read more

On a random whim, I signed myself up to get the LEGO catalog, a long lost friend I haven't seen since my elementary school days. The LEGO catalog is as glorious as I remember, but the prices are not. I always loved the City LEGOs, especially the emergency-response LEGOs and I always had a complete city put together.

I also miss K'Nex. Specifically, the first large-scale K'Nex roller coaster (see picture) that took up my entire room. Man was that was one big box of fun!

It's times like there that I'm sad that I sold all my LEGOs and K'Nex and no longer have them around. I guess it's for the best, but sometimes I just want to be a little kid again. If I had the money, I would be getting some LEGO MindStorm kits ASAP. Read more