Drupal 7.11 and 6.23, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 7.12 and 6.24 also fix other issues reported through the bug tracking system.

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement, more information on the 6.x releases can be found in the Drupal 6.0 release announcement. Drupal 5 is no longer maintained, upgrading to Drupal 6 is recommended.

Changelog

Drupal 7.11 only includes fixes for security issues. Drupal 7.12 also includes bugfixes. The full list of changes between the 7.10 and 7.12 releases can be found by reading the 7.12 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.23 only includes fixes for security issues. Drupal 6.24 also includes bugfixes. The full list of changes between the 6.22 and 6.24 releases can be found by reading the 6.24 release notes. A complete list of all bug fixes in the stable 6.x branch can be found at git commit log.

Security vulnerabilities

Drupal 7.11 and 6.23 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2012-001

To fix the security problem, please upgrade Drupal.

What is included with each release?

We made two versions of both Drupal 7 and 6 available, so you can choose to only include security fixes (Drupal 7.11 and 6.23 respectively) or security fixes and bugfixes (Drupal 7.12 and 6.24). You can choose your preferred version. We are trying to make it easier and quicker to roll out security updates by making security-only releases available as well as ones with bugfixes included. We hope this helps you roll out the fixes as soon as possible. Read more details in the handbook.

Update notes

The default.settings.php file was changed in Drupal 7.12, to add documentation about PDO attribute override capabilities that were added as a result of #1309278: Make PDO connection options configurable.

The robots.txt file was changed in Drupal 6.24 to block filter tips from search engines. The .htaccess and (default.)settings.php files were not changed in Drupal 6. Additionally, indexes were added to the node_comment_statistics and comment tables, for performance.

Known issues #

Drupal 7

Bug fixes in 7.12 release cause problems with the Internationalization (i18n) module. Users of these modules are encouraged to update to 7.11 to get the security fixes, and hold off on the 7.12 upgrade until the 7.x-1.4 release.

Drupal 7.12 is also only compatible with Menu Block 7.x-2.3 and higher.

Drupal 6

In Drupal 6.24, if you have the contributed user_delete module enabled on your site, the update will fail with a Cannot redeclare user_delete_access() error. An update of user_delete module is being worked on.

In Drupal 6.24 if you had locale module enabled earlier, but it is not currently turned on, the update will fail with Call to undefined function locale_inc_callback(). A fix is being worked on for Drupal core.

In Drupal 6.24 if you run your updates with Drush, you might experience duplicate entry errors in your system table. See the ongoing discussion at http://drupal.org/node/1425868

Hello from Jennifer, your friendly Drupal Documentation Team leader! It’s time for a quarterly update on what’s happening in the Documentation team. As you probably heard, Ariane’s role in the Documentation Team has changed, and she is no longer my co-leader (sob!), so I’m looking for a new deputy leader or co-leader (watch http://groups.drupal.org/documentation-team for details). Here’s what Ariane and I oversaw in the Documentation Team at the end of 2011, with a look forward to 2012.

September – December Events

• The Documentation Team is holding weekly ”Documentation Office Hours”—one-hour IRC meetings on Tuesday afternoon (North American time), open to anyone for questions and discussions about contributing to documentation. It seems like it’s been very helpful to have a definite time when people can get together on IRC, and we plan to continue with this schedule for the foreseeable future.
• In October, I was able to attend the Friday of the Bay Area Drupal Camp (BADCamp). We had a small documentation sprint, and a few people got up to speed on writing API documentation patches. Also, Kathy (kathyh) spent the afternoon writing a new guide for novice contributors to Drupal core, based on her experiences as a novice contributor — thanks Kathy!
• We started an API documentation cleanup sprint in November, to bring the Drupal 8 and Drupal 7 core API documentation much more in line with our documentation standards (see meta issue). My big hopes for this sprint:
  1. Lots of documentation cleanup — YES! The sprint is not finished yet, but MUCH more of our documentation is up to standards. In the process, a lot of weird wording has been fixed, and the documentation is clearer and easier to scan. Also, people usually copy/paste an existing documentation header when creating new documentation (or at least use an existing one as a model), so the more we clean up existing documentation, the better future documentation is likely to be.
  2. Lots of participants — YES! My hope was that some people new to contributing to Drupal API documentation would see the sprint as a good way to get up to speed on making Drupal patches, and on the API documentation standards. And they did!
  3. Build a Drupal Core Documentation Issue Queue Squad — Yes! Part-way through the sprint, I put out a call for participants to start reviewing other people’s patches as well as creating patches, and they did! And now some of them are helping out with the “documentation” component of the Drupal Core issue queue — watching for new issues, making patches, reviewing other’s patches — which was my secret hope all along (for the last several years, it’s been a rather lonely issue queue, since I have had to either write or review nearly every patch in it — that model is not sustainable, so I’m really happy to have some company).

  Thanks to xjm, xenophyle, sven.lauer, Lars Toomre, aenw, rc_100, jn2, aspilicious, chris.leversuch, barlantz, synth3tk, agentrickard, … and probably more who joined after I made this list — sorry if I forgot your name! This sprint is still going on, so if you’d like to participate, visit the meta issue, which has full instructions (novice contributors welcome!).

Documentation Infrastructure Updates

The last quarter of 2011 saw some changes to Drupal.org that are quite beneficial to Documentation writers, editors, and users — and more are on the way! Here’s a list:

• After much discussion, we came up with an overview plan for how to restructure Drupal documentation into Community, Curated/Help, API, and External Index documentation in September of 2011 (see http://groups.drupal.org/node/175174). During this quarter, we started putting the transformation into place. The first step was a mammoth design issue (190+ comments!) for the Community Documentation (which is a rename of the existing Documentation on Drupal.org in the early fall. The results of that process are partly deployed (read on for details), and more are coming soon.
• One of the main conclusions of the mammoth design issue was that one of the biggest barriers we see to people contributing to the online documentation on drupal.org is reluctance to click the Edit button — people just aren’t sure whether it’s really OK. So, the redesign of the documentation pages that was deployed in January 2012 included:
  • The existing Documentation pages on Drupal.org have now been renamed “Community Documentation”, to reduce the perception that you have to be part of the “documentation team” in order to edit.
  • The page status and other meta-information has been moved to the sidebar
  • At the top, there’s a list of several people who have edited the page, with a clear invitation for you to edit the page.

  Hopefully these changes will help overcome this barrier — we’ll see!

• We added two taxonomies to Drupal.org documentation pages: keywords and experience level. Right now, they have only been selected on a few pages, but hopefully going forward the keywords will help people find related pages, and the level will help set expectations for the knowledge level needed to understand the page.
• Everyone can now upload images to Drupal.org (issue). Angie/webchick and Daniel/sun made a module that made it safe for people to upload images, and it was deployed in October of 2011. There are followup plans to remove the restrictive Documentation input format from most pages (i.e., to unlock those pages), and to get rid of the Documentation Admin role — no one should need this role now, since everyone can now upload images and use tables using the default Filtered HTML input format.
• BUEditor was deployed on Drupal.org in October of 2011. This module adds a small toolbar with HTML shortcuts to rich text fields (documentation node bodies, comments, etc.). While this falls short of being a WYSIWYG editor, due to security concerns with existing WYSIWYG modules, this is probably as close as we’ll get for the foreseeable future.
• Neil Drumm and Jennifer spearheaded an effort to commit and deploy some updates to the software for api.drupal.org in November 2011 — thanks to aenw, solotandem, and Greyside for contributing patches for that deployment! If you would like to work on the API module, check out the issue queue (http://drupal.org/project/issues/api) or find jhodgdon in IRC to get oriented. A new deployment to api.drupal.org should be coming shortly, with a lot of user interface updates and more new contributors. Stay tuned!

Next Steps

If you’re interested in helping with Drupal documentation:

• New contributors: start at http://drupal.org/contribute/documentation to learn all about contributing to documentation, or come to the weekly office hours (see Events section above) to ask questions and get started. (Jennifer recently edited this whole section, so it should be up to date.)
• Drupal Documentation announcements, discussions, and events are posted on http://groups.drupal.org/documentation-team and on Twitter (@drupaldocs).
• API documentation cleanup sprint (for programmer-documenters): http://drupal.org/node/1310084
• Work on the API module: http://drupal.org/project/issues/api — the issues are all prioritized, so look for ones with priority “major” for the current priorities. Or pick up any issue you’re interested in — we won’t say No to a good patch.

Hi everybody -

Hope you all had a great holiday, and are easing into 2012 nicely! I’ll cut right to the chase with this announcement: effective pretty well immediately (as this has been in the works for a little while now), I’m stepping down as Documentation Co-lead.

Awwww, sad, I know! It’s been quite the experience, and I feel like along with Jennifer and the other docs enthusiasts, we’ve gotten a lot done over the course of the last year and a bit of official leadership term. It’s been great helping set the direction of the documentation plans, and working with everyone who’s been interested in improving the documentation, as well as many of the core and contrib development teams.

After taking some time off in the summer to decompress and figure out where I wanted to go with all of this, I realized that despite feeling like I’ve been effective in the position, it’s taken a lot of my time away from other things in my life, and from actually writing docs and working on other areas of Drupal. And that was definitely okay for a certain timeframe, but it’s not something I want to do forever. Now that the Community Documentation infrastructure changes have been rolled out, my side of the leadership role is effectively being put on hiatus. We’ve talked this over with Dries, and he also feels it’s fine for Jennifer to continue managing the API docs and infra solo.

What does this mean to you all? Probably not any huge changes, I’ll still poke my head in on the issue queue, IRC, etc. now and then. But my “official responsibilities” will no longer exist, including hosting Documentation sprints, attending meetings and docs hour, doing docs conference sessions, etc. And when I do work on Docs, it’ll more often be in a writing/editing capacity. I’m also hoping to spend some more time doing other fun things like patch reviews for Drupal core, and continuing to attend Drupal events. …And also, spending more time knitting, socializing, doing yoga, and all those other things I neglected while I was spending all my evenings online!

My time helping lead the project’s documentation team has had high points and low points, but overall I feel like I’ve learned a ton, gotten a lot done, and am leaving the state of the docs in a better place than when I started. That’s really all I could hope for! Thanks so much to Jennifer for being an amazing co-lead with whom to share a brain, and to all the fantastic Drupal and docs enthusiasts who’ve made this experience a positive one.

I hope to see the tentative docs infrastructure plans come to fruition during the coming year. This will result in a small team of dedicated core docs maintainers (including myself) taking over the helm of the future “curated” core docs section, and also see docs maintainers appointed for other contrib projects’ curated documentation. And of course, work on API documentation and docs infrastructure will continue; Jennifer and other team members have been focused on this for a while now.

Keep rocking the docs folks, thanks for everything, and I will see you around!

————-

Jennifer here… I’d like to thank Ariane for a great year of co-leadership! I’m currently planning on staying on as Documentation Team Leader for 2012.

What I’d like to do is take on a deputy leader or co-leader sometime soon (watch http://groups.drupal.org/documentation-team for details and an official call for interest/applications). This way we can have a smooth transition to the next documentation leader, and start the trend of time-limited leadership for positions like this in the Drupal community (to prevent burn-out, let new people have a chance to lead, etc.). Anyway, rest assured I’ll still be asking Ariane for advice and help, and I’m excited that she’s still excited about being involved in documentation in her new capacity!

The Drupal Security Team was originally created in 2005. Though we handled security issues before that, we didn’t have a team with proper infrastructure until then. At that time, Károly Négyesi (chx) was the team leader. In July 2006 chx changed his role in the team and I promoted Heine Deelstra to be the security team lead. Heine recently stepped down as the security team lead, and I’m pleased to announce that Greg Knaddison (or greggles on drupal.org) will be filling this role.

Greg has been a consistent member of the security team and both Heine Deelstra, the security team members, and myself unanimously agreed that Greg is the logical person to head the Drupal Security Team.

For those who don’t know Greg, Greg helped write our free handbooks on security and wrote a book about Drupal Security. He has also talked about security and Drupal at many DrupalCons. Greg believes in my idea to automate where possible and empower project maintainers. In the coming weeks he will write blog posts to detail some changes made in the last year toward that vision and some tasks that still remain.

As the Drupal Security Team lead, Greg will be the point person for the team. He’ll be responsible for coordinating the security team’s activities and for making decisions when consensus doesn’t arise.

Greg and I agreed on a target of 2 years for him to be in this role. If appropriate, he may continue in this role longer or be replaced before then, but this target helps to set an expectation about the time period. Setting this expectation should help Greg maintain enthusiasm for this role and increase the likelihood that our community will have continuity when that time is up. Greg works at Acquia and will be given 20% of his time to dedicate to the security team (in addition to using his own spare time).

Please join me in thanking Heine for all the great work he did, and in welcoming Greg.

git.drupal.org, drupal.org and our sub-sites have a scheduled maintenance window on Tuesday November 15th from 5PM PST to 7PM PST (UTC-8). Note that this is not a downtime window for drupal.org, but a period of possible instability. git.drupal.org and git.drupalcode.org will have an actual downtime during this window. Watch drupal_infra on Twitter for real-time status updates.

This maintenance window is to re-rack and re-VLAN our servers. Thank you for your patience.

It is with great excitement that I can announce “subscribe” comments on Drupal.org issues are now dead! Long live issue following! Issue e-mail notifications are also improved.

Almost exactly 6 years after #34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment was originally posted, this feature is finally done and deployed on Drupal.org. If you notice any problems, please go to #1306554: QA for issue following on Drupal.org and comment there.

Summary of changes

In the past, you had to comment on an issue in order to keep track of it, commonly done by posting “subscribe” (or variations thereof). Popular issues gained plenty of such comments, making it hard for contributors to distill the important and useful information in an issue.

You are now able to “follow” issues by clicking a button, without commenting on them. You can also “unfollow” issues, even ones you had to comment on but you are not really interested in. Lastly, you can now configure for which projects and issues you want to get e-mail notifications.

Sponsors

First, I’d like to thank the sponsors that made this possible:

The 88 members of the community that contributed to the 2 chip-ins to raise a total of $2777.27 towards the original goal of $7,000.

This sponsorship allowed 3281d Consulting to focus on this project and get it deployed ASAP.

Changes to how we work in the issue queues

There are two big inter-related changes as part of this effort: how we interact with issues on Drupal.org, and changes to the issue e-mail notification functionality.

Working with issues on Drupal.org

The most obvious change is that when you’re viewing an issue on Drupal.org, you will now see a large green “Follow” button in the upper right corner:

Clicking the “Follow” button will use AJAX to flag the issue as one you are following. This will trigger two things: 1) the issue appears in the “Your Posts” and “Your Issues” lists (both on your dashboard and the separate tabs on your profile), and 2), the “Follow” button will be replaced with “Following”, to indicate you’re now following the issue.

If you hover over or put the keyboard focus on this “Following” link, it will turn into an “Unfollow” button:

You can even unfollow issues if you wrote them or commented on them. Whenever you click the “Unfollow” button the issue will disappear from your tracker and you will stop getting e-mail notifications about it (if you get e-mail notifications at all).

Issue e-mail notifications

You can optionally configure Drupal.org to send you an e-mail notification about updates to issues you care about. In the past, this functionality has been somewhat hidden, so a lot of users do not make use of this feature. Now, there is a centralized page to manage all of your issue e-mail notification settings, on the new “Notifications” tab on your account profile page:

This page lets you opt-in to e-mail notifications for issues on Drupal.org. By default, you get no e-mail at all. You can define both a site-wide default and per-project overrides. A very common configuration would be to just set the Default notification to “Issues you follow”:

If you maintain some projects on Drupal.org or are otherwise particularly interested in their issue queues, you can also specify per-project overrides of the site-wide default. So for example, another common configuration might be to get notifications for all issues you follow, but to also get notifications about “All issues” in a few specific projects you most care about:

In the past, there was no way to define a site-wide setting, so users often had to configure e-mail notifications across a large number of projects. If you used to be subscribed to 50 or more projects with the “Own issues” setting, that was converted as part of the deployment into a single site-wide default.

The final change to the e-mail notification functionality is that you can now customize the contents of the e-mails themselves. Previously, you always got the entire issue history included in each notification. If you expand the “Configure e-mail contents” fieldset, you’ll see the ability to only get the new content in each notification and some checkboxes to control what appears in the subject line of the messages:

There are more ideas to further improve the issue e-mail notification experience, so be sure to read the “Future work” section below.

Thanks

While the financial sponsorship was critical to allowing me to spend the time I needed to drive this home, tons of other people contributed to help make this a reality.

• Daniel F. Kudwien (sun) and Chad Phillips (hunmonk) wrote and reviewed many patches related to this effort.
• Leisa Reichelt (leisareichelt) started the Prairie Initiative which has been instrumental in raising awareness about the need to fix the collaboration tools on Drupal.org. She also provided lots of extremely helpful user experience (UX) and user interface (UI) feedback.
• Roy Scholten (yoroy) and Bojhan Somers (Bojhan) provided extensive usability, user interface and user experience reviews and suggestions.
• Everett Zufelt (Everett Zufelt) provided accessibility reviews and feedback.
• Angela Byron (webchick) helped herding cats, reviewing things, testing, giving feedback, and generally was awesome (as always).
• Narayan Newton (nnewton), Gerhard Killesreiter (killes) and Neil Drumm (drumm) did performance reviews, got the staging site up, and provided general Infrastructure Team goodness.
• Nathan Haug (quicksketch) answered a lot of questions about the internals of the Flag module for the data migration, and helped trying to get the new follow UI working smoothly.
• Jerad Bitner (sirkitree) and Moshe Weitzman (moshe weitzman) wrote the initial patches for a couple of the key issues.
• dereine, amateescu, eliza411, ksenzee, Caligan, xjm, Crell, jhodgdon, pillarsdotnet, timplunkett, naught101, kathyh__, wizonesolutions, techninja, hefox, jwalling, joshuabud, otseld, and torthu helped test the upgrade-while-live data migration code.
• Lisa Rex (lisarex) helped edit this post.
• Everyone else who contributed reviews, testing or implementation suggestions for all the issues related to getting this done.

Future work

As exciting as all of this is, of course there’s always more work to do. Generally, we’ve been using the flag integration issue tag to keep track of things related to this effort. See also the drupal.org notifications tag. You can also check out the Expand “follow” functionality on Drupal.org community initiative page.

Unfortunately, I’m going to have to return to other commitments, so I can’t just continue to pour unlimited time into getting all of these issues done, UX reviews, code reviews, etc. So, if anyone wants to step up and claim any of these issues to drive them to completion, that would be greatly appreciated.

Thanks!
-Derek Wright (dww)

p.s. Additional history is available at The history of how we killed “subscribe” comments on Drupal.org for the interested reader…

git.drupal.org is scheduled for downtime, Thursday September 8th at 3PM PDT (2200 UTC). We will be performing standard maintenance on git.drupal.org and its associated services. We expect 20 to 30 minutes of downtime, but are reserving an hour for the maintenance window.

Thank you for your patience.

The last time I organized a State of Drupal survey was in 2008. The results of the 2008 survey were instrumental in shaping Drupal 7 as well as directing the work of the Drupal Association on drupal.org.

Now three years later, I created a new survey. The results of this survey will guide thousands of people in the Drupal community over the next two years.

Take the State of Drupal 2011 survey now.

It shouldn’t take more than ten minutes to fill out. Don’t worry if you’re new to Drupal: every voice counts!

I’ll present the results during my DrupalCon keynote in London; the video and the presentation slides will be downloadable after. Please do tell us what you think these days about Drupal: your views will shape Drupal 8 and beyond. Thanks!

Drupal 7.1 and 6.21, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 7.2 and 6.22 also fix other issues reported through the bug tracking system.

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement, more information on the 6.x releases can be found in the Drupal 6.0 release announcement. Drupal 5 is no longer maintained, upgrading to Drupal 6 is recommended.

Changelog

Drupal 7.1 only includes fixes for security issues. Drupal 7.2 also includes bugfixes. The full list of changes between the 7.0 and 7.2 releases can be found by reading the 7.2 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.21 only includes fixes for security issues. Drupal 6.22 also includes bugfixes. The full list of changes between the 6.20 and 6.22 releases can be found by reading the 6.22 release notes. A complete list of all bug fixes in the stable 6.x branch can be found at git commit log.

Security vulnerabilities

Drupal 7.1 and 6.21 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

• SA-CORE-2011-001

To fix the security problem, please upgrade Drupal.

What is included with each release?

We made two versions of both Drupal 7 and 6 available, so you can choose to only include security fixes (Drupal 7.1 and 6.21 respectively) or security fixes and bugfixes (Drupal 7.2 and 6.22). You can choose your preferred version. We are trying to make it easier and quicker to roll out security updates by making security-only releases available as well as ones with bugfixes included. We hope this helps you roll out the fixes as soon as possible. Read more details in the handbook.

Update notes

The .htaccess file was changed in Drupal 7.2 to allow for simpler server configuration, while the (default.)settings.php just got a minor documentation fix that should not affect any copies. The robots.txt file did not change in Drupal 7.

The robots.txt file was changed in Drupal 6.22 to allow crawlers to index the contact page. The .htaccess and (default.)settings.php files were not changed in Drupal 6.

Known issues

When updating to Drupal 6.22, you might loose some of your block configuration. Follow #1173012: Blocks lose settings during update.php and cache clears for more information. If you need to update to Drupal 6.22 and experience this issue in testing, you can roll back the patch from #235673: Changes to block caching mode not caught.

With only a few days to DrupalCon Chicago, what better time to launch our traditional battle plan discussion. It is time for us to start talking about Drupal 8. If you plan to work on something, or if you are going to contribute to Drupal in one way or another, please share your “personal battle plan” in the comments. A “personal battle plan” is a summary or itemized list of things you are going to work on during the next 12 months or so.

Important guidelines

In this thread, we are only interested in what you plan to contribute, and not what you’d like other people to work on. This is not the place to request features, to talk about implementation details or to discuss Drupal’s general direction. This thread is meant to be a collection of things people are actually going to work on. If you are not going to contribute to Drupal 8 development, don’t post any comments. Thanks for your understanding.