Dear Drupal maintainer-news subscriber,

One of the goals of the Drupal Security Team is promoting education on security topics. In this email, we on the Drupal Security Team provide some “best practice” guidelines for configuration of Drupal’s text formats, to help you keep your sites secure. Despite Drupal core having sensible security defaults, it's quite easy to introduce insecure misconfigurations and in so doing open your site up to attack. If you’re building Drupal sites it’s important to understand Text Formats as an example of safely using user input.

One of the most frequently encountered vulnerabilities on the web and the number one vulnerability improperly built Drupal sites is cross-site scripting (XSS). You should be aware of how Drupal’s Text Formats system protects you against XSS, to avoid unknowingly opening your site up to attack (see https://www.owasp.org/index.php/Cross_Site_Scripting_Flaw).

The Drupal.org CVS -> Git migration has been completed during the evening of February 24, though the morning of February 25 2011! If you see a member of the git migration team online or at Drupalcon, be sure to thank them.

The Drupal.org CVS -> Git migration is nearly upon us! There are just *hours* left now until the big day (Thursday, February 24)!

We will be doing a final verification of migrated code integrity before launch, but while http://git-dev.drupal.org is open for testing we invite you to spot-check your projects. If you have time, comprehensive instructions for verifying project data (as well as other steps you can take to help test and prepare yourself for the migration) are available at http://groups.drupal.org/node/128294. The migration team has taken numerous steps to ensure the accuracy of migrated project data, but there is no substitute for the attention a project maintainer can give to her or his own code.

Additionally, please be advised that starting at Thursday, February 24, 23:00 UTC (3PM PST, 6PM EST), there will be approximately *12 hours* of downtime while the migration completes. This is the most comprehensive and extensive change to Drupal.org in recent memory - perhaps ever. Therefore, the Infrastructure & Git Migration teams need an extended buffer of time to perform the migration, verify the data, and check for and resolve any issues. For more information on what exactly this downtime entails, please see http://drupal.org/node/1068664.

For those not following the Drupal.org home page, the Drupal.org CVS -> Git migration we told you about last newsletter is scheduled to launch February 17. There are a number of things that ALL CVS account holders MUST do ASAP in order to prepare for the migration.

Once the migration is complete, that's it; CVS will be cut off, Git will be in place. It is absolutely imperative that each and every one of you perform these steps in advance of the migration. Thanks for your immediate attention to this.

Key points:

It is that time again! Drupal 7 is nearing completion, drupal.org project spaces were redesigned and we are switching version control systems. There are lots of new things to learn, and great new opportunities to use. We'd like to inform you about these developments, so you are best equipped.

Drupal 7 is around the corner

Drupal 7.0 RC1 was just released on December 1st, 2010. This means a release is not far off, perhaps as soon as 7-10 days from now. Moshe Weitzman started off the Drupal 7 Contrib Experience (D7CX) movement almost one and a half years ago with the goal to get as many contributed modules ported to Drupal 7 as possible by the time Drupal 7.0 is released. This among other factors lead to the availability of over 700 modules for Drupal 7 (compared to 7000 overall) - at varying levels of completeness.

There is of course more work to do, and you might have one or two modules or themes not ported yet. We have documentation detailing all the changes in the API with before/after examples for most items. The Coder module is of great help in this migration as well, and now it includes the Coder Upgrade module, which attempts to do automated code conversion for you. If you made a D7CX pledge, this week is the time to tag your final release.

Related links:

• Drupal 7.0 RC1 release: http://drupal.org/node/985946
• D7CX announcement: http://cyrve.com/d7cx
• D7CX progress tracking: http://d7cx.com/
• Converting modules to 7.x: http://drupal.org/update/modules/6/7
• Coder module: http://drupal.org/project/coder

Drupal.org project spaces get new features

You probably already noticed that drupal.org was redesigned earlier this year. If you have not seen that already, now is the time to pause reading and go wander around on the new site!

The redesign affected project spaces as well. Here are some tips to use the new features more effectively:

1. Each project now has a 'Maintenance status' and a 'Development status' flag, which you can use to inform users about the state of your work. Categories are also prominently displayed now. These are all good to provide users with the information necessary to choose the right modules. Make sure to set yours properly.
2. There is entirely new maintainer management for each project! You'll see the 'Maintainers' tab on projects you own, which now allows you to add maintainers inline and grant fine grained permissions like 'maintain issues' or 'edit project' separately.
3. The new dashboard on drupal.org helps you keep tabs on your project issues. You can add a block with all issues you are involved in (across all projects) or individual project issue overviews.

CVS is being replaced with GIT

Drupal.org is moving off of CVS for project version control! The Drupal Association sponsored the project to help move drupal.org to a more modern system enabling the community to do even smoother collaboration. Your new helper will be git (originally written to manage the Linux kernel code). The team is hard at work to accomplish the migration before Drupalcon Chicago. Mid-Februrary is the tentative launch date.

What does moving to git mean for Drupal.org? Read more at http://groups.drupal.org/node/106224

We made the existing source of drupal.org projects available under git.drupal.org in a ready-only mode, so you can use it to roll patches or just check out code already.

It's very important to understand that the migration will not be a gradual process - when the flip is switched, CVS will become instantly read-only, and git will replace it entirely. So the sooner you familiarize yourself with git, the better! Get books for the holidays, read some great tutorials. Here are some of our tips:

• http://gitref.org/
• http://gitready.com/
• http://book.git-scm.com/
• http://www.archive.org/details/GitFundamentals
• http://peepcode.com/products/git
• http://groups.drupal.org/drupal-org-git-migration-team

Translations decoupling from projects

Translations have long been an integral part of the drupal.org project space, using the same CVS version control system and issue queues. Drupal core translations had their own projects and distinct project translations (think Views, Fivestar, etc) got their .po files hosted with the projects themselves.

This resulted in a long list of issues, including translators needing to know CVS or project maintainers needing to distinguish between an outdated translation and an updated one. It is a burden for project maintainers to generate translation templates and keep them up to date, and there is no opportunity for translators to keep their translations complete with project releases. Finally, the tools were missing to maintain an up to date translation database on actual Drupal sites with module updates and removals.

This is all changing since we are decoupling translations from the module, theme and installation profile projects themselves. What does this mean for you?

A. If you are a translation maintainer: you've already been contacted, and your team is in the process of moving from drupal.org to localize.drupal.org.

B. If you are a translator: stop working on .po files in CVS (either for Drupal core or contrib), instead import existing .po files from CVS to localize.drupal.org (if not already), remove the imported file from CVS and work on localize.drupal.org from now on.

C. If you are a drupal.org project maintainer: do not accept .po files anymore in your issue queues and remove your .pot files from CVS; tell people to use localize.drupal.org.

For more background information, follow the news feed for localize.drupal.org at http://localize.drupal.org/news

------------------------------------------------------------------------------

You are getting this newsletter because you are a CVS account holder on drupal.org. See http://drupal.org/node/243389 for more information.

We hope these news items were useful for you. We wish you happy holidays, and looking forward to an even more eventful 2011.

Yours,
The Drupal.org infrastructure team

This is a notification of two recent Drupal 7 API Changes. Since many of you are developing contrib and custom modules for Drupal 7, and since Drupal 7 still has occasional required API changes, it seems reasonable to notify the developer public.

HOWEVER: This is the *only* planned API change notification to this newsletter (Maintainer News). Future announcements of API changes will go only to the Development Mailing List. If you would like to receive this occasional service, you'll need to be subscribed: http://drupal.org/mailing-lists. Each announcement will be titled "Drupal 7 API Change notification", so if you want to filter, you can.

1. hook_block_info_alter() has been renamed to hook_block_list_alter(). If your D7 module was using hook_block_info_alter() it will need to be updated. Issue: #560746: Rename hook_block_info_alter() to hook_block_list_alter() and add hook_block_info_alter(). See block_example.module for sample usage.
2. Content types no longer have a body field unless one is explicitly added. This means that:
   • If your content type requires a body field, you must call node_add_body_field() in hook_install(). Example in node_example.install.