| Commit message (Collapse) | Author | Age |
|
|
|
| |
multisite support feature.
|
|
|
|
| |
instructions.
|
| |
|
| |
|
|
|
|
| |
user/user_role for consistency.
|
|
|
|
| |
sites/all/themes directory. Hooraycvs diff :D
|
|
|
|
| |
default.settings.php.
|
| |
|
|
|
|
| |
settings.php because (i) we don't want a user to change it and (ii) it gets executed a bit earlier in the Drupal bootstrap.
|
|
|
|
| |
check database settings.
|
|
|
|
| |
generation database layer for Drupal 7.
|
|
|
|
| |
documentation. Candidate for Most Trivial Patch of the Month Award.
|
| |
|
|
|
|
| |
online vs on-line.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
default.settings.php file.
|
| |
|
| |
|
|
|
|
| |
configuration options are fixed, and cannot be modified on the web interface
|
|
|
|
| |
maintenance pages (regression)
|
|
|
|
| |
settings.php, because these need to be used before Drupal has the variables loaded from the database
|
|
|
|
| |
so we can check whether it is wide open, and we have one place for settings
|
| |
|
|
|
|
| |
with sites/default/default.settings.php.
|
|
|
|
| |
by Moshe Weitzman, webernet, chx, erdemkose and myself
|
|
|
|
| |
domain problems.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
session.cookie_domain settings.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
automatic domain extraction -- prevents users from logging in.
|
| |
|
|
|
|
| |
Thanks.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
README.txt
|
| |
|
|
|
|
| |
page.
|
| |
|
| |
|