et al. Can you say 'registry'? Drupal now maintains an internal registry of
all functions or classes in the system, allowing it to lazy-load code files as
needed (reducing the amount of code that must be parsed on each request). The
list of included files is cached per menu callback for subsequent loading by
the menu router. This way, a given page request will have all the code it needs
but little else, minimizing time spent parsing unneeded code.
Drupal core! This is an important milestone for the project so enable
the module and check it out ... :)
Thanks to Rok Žlender, Károly Négyesi, Jimmy Berry, Kevin Bridges, Charlie
Gordon, Douglas Hubler, Miglius Alaburda, Andy Kirkham, Dimitri13, Kieran
Lal, Moshe Weitzman, and the many other people that helped with testing
over the past years and that drove this home.
It all works but it is still rough around the edges (i.e. documentation
is still being written, the coding style is not 100% yet, a number of
tests still fail) but we spent the entire weekend working on it in Paris
and made a ton of progress. The best way to help and to get up to speed,
is to start writing and contributing some tests ... as well as fixing
some of the failures.
For those willing to help with improving the test framework, here are
some next steps and issues to resolve:
- How to best approach unit tests and mock functions?
- How to test drupal_mail() and drupal_http_request()?
- How to improve the admin UI so we have a nice progress bar?
- How best to do code coverage?
- See http://g.d.o/node/10099 for more ...
The short explanation is that Drupal uses a lot of numeric deltas in the block system; blocks are identified by the 'module' and the 'delta'. In early Drupal, delta was numeric, but somewhere along the line it was changed to be possibly a string. In modern Drupal, block overrides are easily done via block-MODULE-DELTA.tpl.php. The primary motivation to switch to string IDs everywhere is to make these deltas friendlier to themers:
block-user-0.tpl.php --> block-user-navigation.tpl.php
block-user-1.tpl.php --> block-user-login.tpl.php
You get the picture.
The access rules capability of user module has been stripped down to a
simple method for blocking IP addresses. E-mail and username restrictions
are now available in a contributed module. IP address range blocking is
no longer supported and should be done at the server level.
This patch is partly motiviated by the fact that at the usability testing,
it frequently came up that users went to "access rules" when trying to
configure their site settings.
This is a big and important patch for Drupal's security. We are switching
to much stronger password hashes that are also compatible with the Portable
PHP password hashing framework.
The new password hashes defeat a number of attacks, including:
- The ability to try candidate passwords against multiple hashes at once.
- The ability to use pre-hashed lists of candidate passwords.
- The ability to determine whether two users have the same (or different)
password without actually having to guess one of the passwords.
Also implemented a pluggable password hashing API (similar to how an alternate
cache mechanism can be used) to allow developers to readily substitute an
alternative hashing and authentication scheme.
Thanks all!
Dries Buytaert
Gábor Hojtsy