drupal planet

We're opening up the entire online video library (over 24 hours of video) for free on March 11th for the Drupalcon sprint day. If you plan on participating in any of the sprints, this is a great opportunity to have a quick visual reference library at your fingertips. If you won't be at Drupalcon, you still have full access and can use the day to build some new skills.

First videos in the Drupal Theming Essentials series

This week we released the first 5 videos in the new Drupal Theming Essentials series. In this series, we're going to give you all the tools that you need to modify the output of virtually anything in Drupal, from blocks to nodes to links. More importantly, we'll help you answer some common questions like "Where do I put this modification?" or "Do I use a module or a theme for this" or "How to I hide that pesky RSS icon".

Here are some additional topics that we'll be covering over the next several weeks:

  • How to build a theme from scratch
  • The right way to modify or extend a theme
  • How to use sub-themes
  • Using template files and theming functions
  • Conceptual groundwork to get a better idea of where coding and designing end and where theming starts.
  • Lots, lots more!

And below is the list of new videos, in which we cover issues around the ambiguous nature of theming:

Who these theming videos are for and what they do (and don't) cover
In this video, we explain what these theming videos are doing on a site geared towards module building, and what we purposefully exclude in order to focus on the most common and important concepts and techniques. (FREE)

What is the difference between designing, theming and coding, and why do they overlap so much?
This video answers the question of why it is so difficult to draw a line between these different roles, and why do these roles exist in the first place. (FREE)

What are all of the different ways to modify Drupal output?
If you've ever found your head spinning as you attempt to figure out how to modify some output, it might be because there are so many possible approaches. In this video, we discuss different approaches including using CSS, installing contributed modules, and using alter functions within a module. (subscriber-only)

How to determine which method to use when modifying output
Once you're aware of the different approaches for modifying output, this video will help you answer the question of which method to chose for various situations. (subscriber-only)

A conceptual introduction to the Features module for exporting configuration options as code
In general, making output modifications with configuration changes is difficult to maintain and copy from one site to another. However, the Features module offers one solution for this, which may influence whether you take a modular or configuration-based approach to your modifications. (subscriber-only)



Over the last two weeks, Build a Module.com has released 17 videos on how to use the File API in Drupal 7. This week we wrap the series up with 7 more videos, completing the final example where we build an image gallery with managed files completely outside of the node system. We also added a video on X-sendfile, the Apache mod that makes the private file system scream, and we open up the black box of stream wrapper code.

In addition to this release, the full collection of all 24 File API videos is also now available as a purchasable download.

How to use the EntityFieldQuery class to match certain criteria and display the results

In case you missed the previous announcements, below are the videos that are free for all visitors plus a couple that are available to mailing list subscribers:

The new videos

And below are the new videos. At this time, they're only available to subscribers, but we occasionally open up subscriber-only videos to the public for special occasions, so keep your ears out (or follow us on Twitter).



If the new Drupal 7 File API has you befuddled with terms like stream wrappers, unmanaged files and URIs, then here's a little something to help clear the air. 7 new videos were added to Build a Module.com today to answer some tough questions about working with unmanaged files and how to protect your files with the private file system.

This follows hot on the heels of our previous release of File API videos where we set the groundwork for working with files in Drupal.

In addition, this weekend all of our Coding Standards videos are free to all, so if you need to brush up a little, now's a great time. We cover everything from working with arrays to working with white space and writing good comments.

Below are the list of File API videos we added. Several of them are available for anonymous users and mailing list subscribers, but I've gone ahead and marked the subscriber-only ones with a little *. Enjoy!



Working with files in Drupal 7 can seem complicated, especially with new the managed / unmanaged system, stream wrappers, and lots of new File API features. This new series of videos aims to demonstrate a clear example of working with files every step of the way, from managing uploads outside of nodes to working with private and public files, using files across different modules and tons more.

Some essential concepts around files are also covered, like the difference between a URI and a URL and how to set up PHP to properly handle uploads.

Today the first 10 videos of the File API series were released at Build a Module.com. Parts 1, 2 and 9 are available to everyone, and the other videos are accessible to subscribers.

Below is a list of shortcuts to each section. Enjoy!

  1. What this video covers and a demo of our node-free image gallery module>
  2. What the difference is between a URI and a URL
  3. What stream wrappers are and how they work
  4. How the private file system works
  5. How file and folder permissions work, and best practices
  6. How to set up PHP to properly handle file uploading
  7. How to create a simple form with an unmanaged file input
  8. How to use a form validation function to validate a file
  9. How to use hook_file_validate() to validate an uploaded file
  10. How to use core file validation functions and define your own validator


Want to learn Drupal 7 development, but haven't had the time yet? Have a development team that needs to get on board with Drupal 7 fast? Are you teaching Drupal and need training material for your students?

Build a Module.com V.2 has been officially released, complete with over 12 hours and 130 new Drupal 7 development video tutorials. The training takes you all the way from building your first Drupal 7 module to really digging deep into the new Database API, the menu system, building forms, and there's even nearly 2 hours dedicated to getting up to speed with jQuery and JavaScript in Drupal 7.

The Build a Module.com site has been entirely revamped to include a super-clean interface for watching and browsing videos, new video organization, and a community forum for subscriber-to-subscriber support.

Tons of free Drupal development training material

There's over 5 hours of free videos available so you can learn a ton without having to purchase anything, though subscriptions, HD downloads as well as DVDs are available for full access to the videos. Once a purchase has been made, the entire source code for the examples used in the videos will be available for download so you can easily follow along.

Here's a sample of the free videos:

Introduction to Module Building

Coding standards, the Form API and the menu system:

Theming and the Database API

Working with users and nodes

Working with jQuery and JavaScript in Drupal 7

A few extras for newsletter subscribers

Signing up for the newsletter also gets you access to a number of other free videos, including:

Adding usability with the #state attribute
Learn how to build awesomely usable forms using the #state attribute to show and hide elements on demand.

Modifying forms with hook_form_alter()
Ever wanted to change a Drupal form, but didn't know how? Look no further, here's how.

Adding autocomplete to a text input
Take a look behind the magic of autocomplete inputs - awesome for search boxes, usernames and more.

Using the #ajax attribute for dynamic form building
How to build forms dynamically - add checkboxes, remove textareas, load new fieldsets, you name it. And all without a page reload. Slick!

How to use render arrays and tabs
I bet you're at least a bit curious about render arrays. They're a big deal, like you! Learn how to use them to allow your pages to be modified by other modules.

How to use sub-tabs
Tabs are nice, but what about tabs of tabs? Well, here you go.

How to load JavaScript after a page is done loading
Ever wanted to add Javascript and CSS on the fly, Ajax-style? It's super easy with Drupal 7, check it out.

Questions?

If you have any questions or have any material you'd like to see covered, please drop me a line.



I wanted to use taxonomy terms as triggers to perform certain actions with the Drupal Rules module (There really should be a "Drupal Rules!" module), but there was no preset condition for this. No problem, it's really easy to add new conditions and actions (a post about creating an action is forthcoming).     

To do so, we need to add 3 functions:

  1. Add a hook_rules_condition_info() hook in our module
  2. Add a function for the condition
  3. Add a function for the condition form

Here's the code:

/**
 * Implementation of hook_rules_condition_info()
 */
function custom_misc_rules_condition_info() {
  $defaults = array(
    'arguments' => array(
      'node' => array('type' => 'node', 'label' => t('Content')),
    ),
    'module' => 'Taxonomy',
  );
  $items['rules_condition_content_has_term'] = $defaults + array(
    'label' => t('Content has term'),
  );
  return $items;
}


/**
 * Condition: Check if the node is published
 */
function rules_condition_content_has_term(&$node, $settings) {
  if (!is_numeric($settings['term'])) {
    $settings['term'] = db_result(db_query("SELECT tid FROM {term_data} WHERE name = '%s'", $settings['term']));
  }
  if ($row = db_fetch_array(db_query("SELECT * FROM {term_node} WHERE nid = '%d' AND tid = '%d'", $node->nid, $settings['term']))) {
    return true;
  }
  return false;
}


/**
 * Check for a term configuration form.
 */
function rules_condition_content_has_term_form($settings, &$form, $form_state) {
  $form['settings']['term'] = array(
    '#type' => 'textfield',
    '#title' => t('Term ID or text of term'),
    '#default_value' => isset($settings['term']) ? $settings['term'] : '',
    '#description' => t("Provide a number for a term ID (tid) or a string for matching text."),
    '#required' => TRUE,
  );
}


It took me two years, but galdarnit, I did it. I migrated a project over to Git and got to see what I've been missing this whole time. And it made me feel like a moron for waiting so long. If you're a late majority holdout like me, there's probably not much I can do to convince you to move over that hasn't been tried already. But when you get there, you can put me on the list of people that said "I told you so".

Alternately, if you're reading this because you were one of the people that told me so, and don't know about it already, you can help the Drupal Git migration team by teaching your fellow Drupalists in meetups and camps. I'm behind you all the way, though it will probably take a couple more years for me to start teaching it myself (late majority).

A lot has been written about the benefits of using Git, but there were some things I didn't run across until I started using it myself. Below is a little list to compare my Git experience with SVN:

  • Messages are way more helpful. Misspelled 'status' and it said 'Did you mean status?'. 'git status' gives you suggestions on what to do to add new files in and such.
  • Patch syntax makes more sense. "git apply" instead of "patch -p0"
  • Multi-line commit messages in a default text editor.
  • Colorful messages (I'm a sucker)
  • gitk command is really cool - Shows a graphical representation of commits over time, the interaction fo branches, nicely browsable.
  • Active IRC channel (600 people)
  • In a conflict, no files get created. There's just conflict messages in the file. You resolve and commit. SVN produces several files which can be confusing. Also don't need to mark resolved.
  • Commits contain real name and e-mail address, instead of just a username
  • Nicer progress reports when pushing - shows you percentage completed.
  • Much simpler to change remote repository hosting providers without losing data.

And here's a few resources I used to get started:

Enjoy!



Rocking the docs with rainbows

This post is intended as one repository for the lessons learned over two solid months of documentation writing, and the other is BeauityMyDocs.com, which I put together as a free service to other doc writers to instantly add usability and consistency to docs. You paste a doc in, churn it through, and it comes out the other side with sweet features like clickable, linkable headers, a table of contents, a "see also" section, unified header levels and more. It's also just kind of fun to use (i.e. there's rainbows and stars). To see samples, all of the docs for Open Atrium and Managing News have been run through the Beautifier.

Docs are the new code

The last two months I spent writing docs for Open Atrium and Managing News was part of a project sponsored by a client who needed better docs for their organization, but who also recognized the value of contributing this effort back to the community. It was amazing opportunity to become intimately familiar with two bleeding edge projects and to work closely with the Development Seed folks who both live on and sharpen that edge.

This sponsorship came as a bit of a surprise to me. Apparently there is so much power behind Drupal, her contributed modules and distributions that the scarcity of clear, usable, or just plain existing documentation is a genuine bottleneck that is getting some attention and funding. Just a couple days ago someone posted a docs job sponsored by the Knight Foundation, and I'm wondering if these are signs of a trend.

The challenges

If Drupal is a blank piece of paper, a Development Seed distribution is an origami Voltron, and there was a long ways to go before I understood the subtleties of all the folds and creases. As webchick pointed out recently, writing docs is a practice best executed as you're learning, while experiences are fresh, and since I didn't have a lot of experience with either platform, this made for a perfect doc-writing environment.

The two projects posed some interesting challenges:

  1. While I had a blank slate for Managing News, there were existing Open Atrium docs. So how do you make a full documentation project consistent when you have existing docs that run the gambit in quality and technique?
  2. Next, while the docs for Open Atrium are on an Open Atrium site where Markdown is the norm, they would eventually get pushed to Drupal.org where docs are written in HTML. That begs the question of how to switch rapidly between working in Markdown and HTML.
  3. On both projects, we wanted docs to include a table of contents an a "see also" section with links to outside resources. I found that building these was a time-consuming and error prone process, so how do you add these nice chunks of usability without sacrificing your sanity?

For answers to these questions and more, read on Macduff!

Starting with expert outlines

One of the old-timers at Development Seed and all-around nice fellow Ian Ward started me off with outlines, and this established scaffolding around areas where the creators identified important features or potential problem areas. It was years of experience summarized in a short hierarchical list. This left me - the relative noob - free to fill it in with fresh experience without worrying about spending unnecessary time documenting less significant areas.

As I learned more about the projects, this outline went through several iterations. In the end, both projects ended up with a basic structure similar to this:

  • How to use this documentation - The parent page, containing short descriptions of each of the sections, rich with links to sub-pages.
  • Getting started - A section containing a guide for folks just installing or thinking about installing the product.
    • What is [insert product here]? - A general description of what the product does.
    • Quickstart guide - Takes the user on a guided tour of the first few steps of working with the product.
    • Case studies - Examples of how the product is or can be used in the wild.
  • Installation and upgrading - Includes sections on installing, upgrading and troubleshooting.
  • Content and configuration - A section includes anything that can be done via configuration (i.e. no code).
  • Customization and development - Modifying or extending in ways that involve code.
  • How to contribute - Ways to contribute code, translations or documentation.
  • Support - How to find or ask for support.
    •  FAQs - On one of the sites, we split this up into several areas. For example, FAQs for configuration and FAQs for development.
    •  Glossary - Odd terms that are either Drupal- or product-centric.
  • Appendix - Anything that's not active documentation.
    • Archive - Documents that are still applicable to older version of the product.
    • Marked for deletion - Docs that shouldn't be docs, or that get absorbed into other docs are moved here with a short explanation as to why the doc should be removed.

The screenshotgun

Sometimes what make a good doc a really good doc are useful screenshots. The added pizazz and usability of screenshots comes at a cost, though. Whenever a product updates it's look and feel, the screenshots are instantly out of date. And depending on how you do screenshots, they can take a lot of time.

I opted for more screenshots rather than less because a visual representation of a step is quicker to process than text, and getting up to speed as fast as possible is important. It also has the added bonus of giving users who are just browsing a more realistic walkthrough of a process.

In order to rapidly create screenshots, I used a combination of Skitch, Evernote and the Mac-based screengrabber tool. When I was writing a doc, I would compose it in Evernote for two reasons: 1) it saves as you go, and 2) you can paste images or even image data straight into your composition. So, when a doc is done in Evernote, it looks pretty close to what it will look like when posted on the final site, and you can't get that effect composing in Drupal without some WYSIWIG help. When I was ready to create a screenshot, I would do the following (these are Mac-centric instructions, but the ideas should be portable):

  1. Navigate to the page I wanted a screenshot of.
  2. Use the key combination CMD+CTRL+SHIFT+3 (tricky to do with one hand) to launch the partial-screen grabber.
  3. Click and drag a box around the area to capture and let go.
  4. The image data is now in the clipboard. If the screenshot is good as is, I go to my doc in Evernote and paste it in. If it needs some annotations, I paste it into Skitch.
  5. In Skitch, I make my annotations in red. If I need to reference something in the text, I use numbers instead of text to make it translatable (thanks for that suggestion, Ian).
  6. When I'm done, I copy the image to the clipboard (just click CTL+C while in Skitch to copy the whole thing), and then paste it into Evernote.

When I'm done write a doc and am ready to import it to a Drupal page, I do the following:

  1. I select the note in Evernote, and go to File > Export to export all of the images into a single folder.
  2. I then open the folder and rename the images to give them useful descriptions (optional, but helpful)
  3. I create a new page in the Drupal site, and upload the images via the Upload module.
  4. When a file is uploaded, it displays the URL to the image. I select this URL, paste it into the Evernote document to replace the image and surround it with the Markdown or HTML image tag.
  5. When I'm done, I paste the whole document over to the new Drupal page and preview it to make sure it's squared. Then I submit it for real.

Bonus: To capture full screens that go beyond my 1280 x 960 display, I use Paparazzi! If you're accessing a page where you need to be logged in, you need to use the "Capture from Safari" option and log in via Safari. To capture a screen where I want to get some mouse motion (and so you can't use the mouse to drag a box), I use CTRL+CMD+SHIFT+3 (also tough with one hand) to grab the full screen, paste it in Sktich and drag the borders to crop it. The screenshot guidelines in the Open Atrium docs may also be useful.

Ruthlessness and thievery

Using Google to scour Development Seed's blog, I uncovered the meat we needed for several docs and used these as a starting (and sometimes ending) point. This saved me hours. The lesson here is like with most things, great artists steal. Or is it that stealing is the highest form of flattery? I don't know, but just take it (as long as you ask first).

When it came to merging existing documents with the new style and structure, I used the principle of ruthlessness without loss of usefulness. So, anything went as long as no useful information was lost. A lot of the docs were re-written, and many of them were removed or merged into other documents, but any important or useful information in those docs were captured. The idea here is that the goal of docs are to make the way easier for those who are walking down established paths. Signage is important, but consistency helps people find the signs.

Automating everything you can

Tee oh cee

After a while, I started seeing patterns in the documentation I was writing. Nothing as exciting as Mother Mary or Elvis, but for example, to make a table of contents I would copy each heading and paste it into a list at the top of the page.  Then, halfway through I realized that it would be a lot easier for people to link to individual sections in a doc if the headings were clickable. I started to work through each doc again to add the clickable headings and then realized that I must be nuts. Why should I be doing this tedious, repetitive task when I can write a script to do it? And I wouldn't have to worry about changing the structure later on, I could just update my script. And aren't I a developer, shouldn't I be developing? Please, give me some code to write!

So, I wrote a script to add the table of contents and clickable headings. You could roll a doc through it again if you changed some headings or structure, and it would refresh everything. Okay, cool. Now what else could I automate?

See regex run also

We wanted a "see also" section at the bottom of each doc to point users to other related resources. At first, I would read through the doc and pull out the links I found, navigate to the page, figure out what the page was about, and add it to the section. And I thought the table of contents was tedious!

I updated the script to scour the doc for links (a little regex action), and then go out and fetch the title from each page and create a list. As an added bonus, it would check if the page was another local documentation page and add that to a separate "related pages" section.

Crummy bread

Another thing that was tedious and difficult to pin down was breadcrumb / path styling. I wish I had run into this section of the drupal.org handbook style guide before hitting this bump.  But, after some experimenting, it seemed like the Administer > Site  building > Modules (admin/build/modules) structure was the easiest to read (this style was inspired by some docs written by Young). It still was a little painful to write out, and what would we do if we wanted to change the style to something else later? To answer this, I added another bit to the script to search for paths within 

<span class="crumb"></span>

tags and format it. So, you start with: 

<span class="crumb">admin/build/modules</span>

 and it turns it into the full breadcrumb. If the formatting changes, I just change the script and we roll the doc through it again. Easy peasy.

Markdown to HTML to Markdown to HTML to...

Next was the issue of how to post Markdown-based docs on Drupal.org, which only supports HTML. And, what if we wanted to run the new HTML docs through this script to update the table of contents or see also section? Up to this point, it only supported Markdown.

The answer was pretty straightforward. I integrated the Markdown for Markdown to HTML conversion as well as Markdownify for converting HTML to Markdown. I had to do a little hacking of Markdownify because it would use a Markdown syntax that uses URL references instead of inline URLs, which I find makes editing URLs a huge pain.

Headings and stuff

Oh yeah, and you know how in community documentation, headings seem to be all over the place? H2 here, H9 there? Well, I added a setting to convert all headings to the heading of your choice. Also, have you noticed that some of us use "quotes" for emphasis? There's also a setting to turn all in-text quotes to bolding. An em tag would make more semantic sense, but when you're reading through a doc, the bold seems to work better for actual emphasis.

Beautify your docs too!

All this automation was too much to squander on a measly hundred docs, so I cleaned up the script interface, added some clouds and rainbows, and spent a day turning it into BeautifyMyDocs.com. This means that if you want to leverage these tools for docs on drupal.org, or your own doc project, you can! It kind of makes you feel good, too.

I will be posting more about BeautifyMyDocs.com soon.

Attribution

In any good doc, it's good to attribute your sources, either to give them thanks or to lend your doc credibility. In this case, I'm invoking the Development Seed name to give thanks. I really enjoyed getting to know Open Atrium and Managing News, and the DS folks made it happen, so many thanks to them. Special thanks to Ian Ward for fielding all my questions (of which there were more than a few).



From time to time there's a bit of a sour post in an issue queue or blog post that makes it clear that there are misunderstandings about how the Drupal community works, and in this case it was a disgruntled post regarding lack of support for a particular module. It got my blood a-boil, and this was my response after I calmed down a bit:


Mr. Anonymous,

Perhaps it's the language gap, but your posts are coming across pretty harsh. Or, maybe you're just figuring out how parts of the Drupal space actually works and you're frustrated by it. That's understandable - it's tough realizing that Drupal isn't actually run by a team of tireless developers with infinite patience and no bills to pay - and I don't mind bearing the brunt of your frustration if I can help you and other folks in your shoes come to terms with a more accurate perspective.

From a user's point of view, in the ideal world every developer would have the time and desire to regularly pummel their issue queues into submission (like some people). In the developer's world, things look a little different. Most of us have enough going on that we have to prioritize what gets done, and that depends on a huge number of factors, including but not limited to:

  • Can the module / community work be integrated into client work? (i.e. killing two birds with one stone)
  • What kind of time is there beyond client work (i.e. bill-paying work) is there to work on other projects?
  • Out of the numerous projects that you have on your plate, which ones are the most important strategically in getting you closer to your longer-term goals?
  • How many people will be affected by your work?
  • Who are the people will be affected by your work?
  • How educational or exciting is the work going to be?

I may be speaking just for myself, but I'm not positively influenced by how upset a single community user gets about poor support. That sort of reaction means that the user probably has some other pressures in their life impacting their overall happiness and they aren't going to get an awful lot happier through you responding to their demands. So posts like yours above beget the opposite reaction to what you were probably hoping for. I'm actually less enthusiastic about tackling the issues you mentioned, not out of spite, but just because I can't help but get a little bummed out.

Each module on Drupal.org has a backstory, and some of those stories involve a developer who actually is tireless and is doing this work only because of a pure desire to make Drupal better and push their own skills, and it's this focus that allows them to put a strong focus on supporting the module, regardless of who asks or what they're getting paid.

There are other situations where a developer creates a module because they are asked to do so for a client - as with this particular module. What I was actually asked for was a particular feature, and upon my suggestion the client generously agreed to sponsor the extra time that would be required to make the feature modular and share it on Drupal.org - i.e. they understood the value of sharing. I wouldn't have built this module without the financial support because I don't have enough use cases to justify the time required. So my motives are around making the client happy while sharing as much of the work as I can with others.

Now here's the next part of the equation, which is where you come in. You found a good use case for the module - which is great, but doesn't mean that it changes how or when I can work on it. Because the code is open source and free to use, however, you now have the ability to actually go in and fix those problems you've found, or find someone who has the skill set to do so. You're free! You're not beholden to my currently limited ability to offer support, you can actually take action and get something done. And I'd say that in contrast to what you suggested Drupal was all about, that this is a lot closer. It's people doing what they can, when they can, as they need to, and sharing it all.

Good luck!
Chris



Upgrading Drupal from one minor version to the next can be time-consuming and error prone. A lot of folks use Drush for this, but a good second choice for the commandlinophobic is to use a patch file. 

Bernhard Fürst creates patches from all previous minor versions of Drupal 5 and 6 to the current release and posts them here. I've used this method several times, and it's gone really smooth.

First, go to your sites /admin/reports/updates page and see what version of Drupal you're running. Here's what mine looks like:

So, I'm on 6.16 and need to upgrade to 6.17.

Next, go to the list of patch files and find the one that matches up with your version. Click on it to download:

Move the downloaded patch to your Drupal site's base directory.

Now, we need to move to the command line. Sorry, commandlinophobes.

First, cd to the directory where you just put the patch file.

Before we run the patch for real, we're going to do a quick dry run to make sure that we don't get any errors. You'll need to use the actual patch file name you downloaded:

patch -p1 --dry-run < drupal-6.16-to-6.17.patch

You'll see a list of everything that gets patched. If you see any errors having to do with HUNKs, then you should probably use another method to upgrade.

If everything looks good, then run the patch for reals:

patch -p1 < drupal-6.16-to-6.17.patch

Now, run /update.php.

Update: Check out an article Kalid posted in the comments that shows how to automate this process via the command line. It's more command line-heavy, and if you're going to get that heavy it's just a tiny step over to using Drush, but is still pretty cool.

Here's some additional information about upgrading if you run into issues:

The drupal.org handbook page on upgrading with patches
The drupal.org handbook page on upgrading in general
The list of patch files
* Also reference the UPDATE.txt file in your Drupal site's main directory for more information

OCR-ed content: 
Prupal 6.16 Update available Recommended version: 6.17 (2010-Jun-02) Download Release notes Includes: Block, Color, Comment, Database logging, Filter, Garland, Help, Menu, Node, PHP filter. Path, Search, Statistics, System, Taxonomy, Trigger, Update status. User 6.16 VERSION 17 [2010- Jun- 02) (2010-Jun-02) 16 Y.1 drupal-6.12-to-6. 17. patch drupal-6.13-to-6. 17. patch drupal-6.14-to-6. 17. patch drupal-6.15-to-6. 17. patch drupal- 12- to- drupal- 14 to- dru al-6 15-to 6.17 tch drupal- 16- to- 17 patch dru 6.17 16-to-6.17 6.12 dru S.13 DRU pa 6.13 17.ua-.ch 616 17. patch G.14 G.1Z pa G.Ij 6.16 r&lt;i


Syndicate content