| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
| |
simpletests for the (new) permission handling. At last.
|
| |
|
|
|
|
|
|
|
|
|
| |
flobruit
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.
|
| | |
|
| |
|
|
| |
variables.
|
| |
|
|
| |
committed to D6.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 ...
|
| | |
|
| | |
|
| |
|
|
| |
discussion we've decided to make the concatenation operator consistent with the other operators.
|
| |
|
|
|
|
|
|
|
|
|
| |
from numeric block IDs to string IDs.
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.
|
| |
|
|
| |
accomplished using hook form_alter.
|
| |
|
|
|
|
|
|
|
|
|
| |
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!
|
| |
|
|
| |
at admin/user/user.
|
| | |
|
| |
|
|
| |
descriptions for permissions on the permission administration page.
|
| |
|
|
| |
user_save(). Factored the relevant code out to a separate function.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
module phpdoc blocks
|
| | |
|
| |
|
|
| |
logs in
|
| |
|
|
| |
checkbox for authenticated role
|
| |
|
|
| |
provide the same as the public facing user search anyway
|
| | |
|
| |
|
|
| |
user_roles() call cleanups
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
by hswong3i: some indexes added before Drupal 6 RC1 were too unique, and our code did not back them, so we should not add those indexes
|
| | |
|
| |
|
|
| |
changes, so user names in email address format (eg. site_network module) will still work
|
| |
|
|
| |
year. Fiew. Thanks all, and see you on the other side. :)
|
| | |
|
| |
|
|
| |
not updated to latest login process
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
fixed)
|
| | |
|
| |
|
|
| |
uploaded one uses a different format
|
| | |
|
| |
|
|
| |
indicies for common queries.
|
| |
|
|
| |
not reflected in two remaining permission checks
|
| |
|
|
| |
to 'User account' as it was in Drupal 5, instead of the bugos 'Log in'
|
| |
|
|
| |
do not mislead our users
|
| |
|
|
| |
help texts, as the handbook we referred to before was renamed
|
| |
|
|
| |
description wording in installer and runtime interface
|
| |
|
|
| |
login tasks, such as session id regeneration were not performed in all cases, so centralize this
|
