[development] Announcing DRUPAL-7-0-UNSTABLE-9

Angela Byron drupal-devel at webchick.net
Tue Sep 15 06:23:16 UTC 2009

Tonight seemed like as good a night as any to roll another interim  
unstable release for Drupal 7, so say hello to DRUPAL-7-0-UNSTABLE-9.  
I'll detail the exciting changes in a bit here, but first a few  
procedural things.

For those who missed Dries's keynote at Drupalcon Paris (http://www.archive.org/details/TheStateofDrupal 
), I'll give a recap of the parts that pertain to Drupal 7's  
development/release cycle:

* Code freeze was extended an extra week until 9/8 to allow people in  
Paris (as well as abroad) to collaborate on last-minute frenzied  
features. Dries and I are working through last week's RTBC queue now  
that we're both home for a couple of days. ;)

* We're now in a "code slush" phase, which means that Drupal 7 is  
feature frozen, apart from a few hand-selected exceptions, as well as  
API and markup clean-ups for existing features. Additionally, we allow  
improvements to Drupal's usability (minor changes), accessibility,  
performance, testing framework, documentation, and user interface text  
during this phase. Code slush is time-boxed until Oct. 15, at which  
point we'll enter a "hard" freeze. Then, no more XHTML markup changes,  
no more function signature changes, and no more database changes.

* That means it'd be a /really/ good idea to begin poking at your  
Drupal 7 module/theme porting, oh... now-ish... so that if we missed  
something blatantly obvious during development of D7, we can fix it  
while the code is still somewhat malleable. Coder has a 7.x version to  
help with this: http://drupal.org/project/coder, and also consider  
taking the #D7CX pledge for your project: http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&display=table

* From Oct. 15 to Nov. 15 will be the "strictly polish" phase, where  
we can continue to do things such as minor accessibility and usability  
improvements, performance improvements, and documentation and string  
improvements. November 15 will then mark both a string *and* UI  
freeze, so that the documentation and translation teams can get busy  
preparing for the Drupal 7 release.

*  Patches that expand Drupal's automated test coverage, as well as  
bug fixes, can be accepted at any time up through release.

* Drupal 7 will be released "when it's ready", which is when all  
critical issues are resolved. Keep your eyes on http://drupal.org/project/issues/search/drupal?status 
or enable the "Contributor block" in your drupal.org user profile to  
get a handy count (currently at 400).

Here are some "hit lists" along with helpful deadlines for you all:

* Feature freeze exceptions (Oct. 15):
* API clean-ups for existing features (Oct. 15):
* XHTML markup (Oct. 15):
* Testing framework (Oct. 15):
* Minor usability improvements (Nov. 15):
   [some of] http://drupal.org/project/issues/search/drupal?issue_tags=Usability
* Accessibility (Nov. 15):
* Performance patches (Nov. 15):
* Documentation improvements (Nov. 15):
* String fixes (Nov. 15):
* Test coverage (Any time):

Ok, now that the whip-cracking is out of the way, here are the changes  
in this snapshot! :D As always, the full change log is attached below.

Changes for developers:
* Database-wise, core is now fully DBTNG-compliant! YAY! We also added  
basic support for 'date' and 'time' types to Schema API, update_sql()  
is dead, dead, dead, AND now hook_uninstall() and hook_install() will  
automatically handle your schema definitions. Ahhh.

* The File API now uses stream wrappers for accessing files, which  
basically means that all functions that used to take a file path now  
take a URI like public://old_photos/banana.jpg. Core ships with three  
default stream wrappers: temp://, public://, and private:// (which  
means that public and private files FINALLY co-exist!) with support  
for contrib to offer wrappers such as s3:// for Amazon S3, flickr://  
for getting data into/out of Flickr, and so on. We also added a  
hook_file_url_alter() for content delivery network (CDN) support. w00t!

* Remember that awesome code registry I talked about back in  
UNSTABLE-1 or so that was going to solve all of our performance woes?  
Yeeeah... Turns out, it caused severe developer experience issues, in  
addition to not offering performance improvements on par with more  
well-supported systems such as APC, so this got partially rolled back.  
The registry no longer caches functions, though we do still offer a  
class registry, which means that $foo = new Foo; will work from  

* Field API improvements: Taxonomy terms are now fields, comments and  
taxonomy terms are fieldable, and fields are also now translatable.

* In terms of clean-ups, we now have the R part of a real CRUD API in  
core with standardized, swappable entity loaders. We also have a  
*real* user and permissions API, as well as a filter API. We also  
renamed 'box' to 'custom_block' in the name of sanity.

* Performance-wise, we now ship with "smushed" images that are lighter  
on bandwidth, and we've now added a caching system to the render API  
which is currently implemented by blocks, and because it happens early  
in the page render cycle, it works for both authenticated users and  
with node access modules. Yum.

* Install profile improvements! Shock! Install profiles are now  
basically modules with .install files, .info files to declare  
dependencies, etc. If you can write a module, you can write an install  
profile, and you can also do everything from install profiles you can  
do with modules including use the full Drupal API and write update  
functions to move from one version to another. Speaking of versions,  
you can now specify version-level dependencies in your .info files, so  
you can say your module depends on at least Views 2.0-rc1 but less  
than Views 3.0. And finally, you can run update.php and install.php  
from the command line without Drush having to do unholy things. Yay!

* In terms of our testing framework, there's now a debug() function  
which can be used as a 'lite' version of dsm(), and also prints  
debugging data as SimpleTest assertions. There's also a new "verbose"  
mode which logs screen captures of the pages SimpleTest hit on its way  
through, along with the assertion messages. This should make figuring  
out why tests are failing MUCH easier! Thanks to the testing sprint in  
LA back in mid-August, we also greatly grew our test coverage and  
cleaned up a lot of lingering test patches from back in Szeged.

Changes for themers:
* Regions $sidebar_left and $sidebar_right are now called  
$sidebar_first and $sidebar_second, for better semantics and to make  
them more RTL-friendly.

* The AJAX framework from CTools is now in core, and core now supports  
a new .once() method for ensuring that a behaviour applies only a  
single time. I don't really know what any of this means, but the JS  
folks are really excited about it. ;)

* You can now use a "wildcard" operator in tpl.php files, for example  
page-user-%.tpl.php to affect any user/xxx while letting page- 
user.tpl.php affect only the actual page /user.

* In accessibility news, there are now system-wide classes for marking  
elements as either completely hidden (.element-hidden: equivalent to  
jQuery's hide() function) or invisible (.element-invisible: visible  
only to screen readers). We're now working to apply those classes to  
various points in core, as well as other important accessibility  

Changes for end-users:

* CC-FREAKING-K IN CORE! OH YEAH! :D Not to mention Token, FileField,  
and Poormanscron!

* As a trade-off, lots of extraneous features were removed from core  
in favour of either contributed modules or field API alternatives:  
minimum number of words on the body field, related terms for taxonomy  
terms, per-user theme selection, Blog API module.

* The D7UX IA is fully in place; no more confusing "half the items are  
in 'Site configuration' and half under 'Configuration & Modules'"  
stuff. Thanks for bearing with us while we went through that transition!

* Some nice security improvements. Users are now prompted at install  
time to get notified via e-mail about security updates for their  
sites. This is great because I'm pretty sure almost no one realizes  
this is a setting in Drupal 5 and 6. :P We also now limit the number  
of login attempts to help prevent brute force attacks. And running  
update.php is now tied to a permission rather than having to open it  
up to the entire universe if you don't like sharing your user 1  
password. Oh, and last but not least, SSL support in core! :D

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/development/attachments/20090915/03c42ea1/attachment-0001.html>
-------------- next part --------------

More information about the development mailing list