module to v46. There's a new block in the admin dashboard which
controls whether automatic checking happens, and lets you check
immediately. If a newer version is detected, a site status message
appears for admins providing upgrade instructions.
Automatic checking is not yet implemented (even though the UI claims
that it exists). This is all for #1605.
Note: The effective maximum length of a VARCHAR in MySQL 5.0.3 and later is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used.
In contrast to CHAR, VARCHAR values are stored as a one-byte or two-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.
random::hash()
random::string()
random::percent()
random::int()
So that we don't have lots of different ways to get random values all
over the code. Follow-on to #1527.
name=_cache row. If that overflows, it will cause us to be unable to
load variables, and we can't recover from that.
Instead, use the Cache table. Bump the gallery module to v40. Fixes
ticket #1405.
provide a "show_user_profiles_to" setting to allow admins to open it
up to everybody (choices there are "registered_users", "admin_users"
or "everybody"). Fixes ticket #1378.
"example.com" when we are using the CLI so we'll get inconsistent
behavior between CLI and the web interface.
For now hardcode it to be example.com so that it's clear. But to do
it right we need an after_install step which actually fixes it up.
And probably an after_upgrade step as well.
module ordering, which is currently being done in the moduleorder
contrib module.
By default, the weight will be the same as the id of the row which
means that new modules will get added at the end of the list. This is
covered in the upgrade case as well.
The one gotcha is that we need to make sure that we don't try to sort
by the weight column if the gallery module version is < 32, which is
something we haven't done before.
Fixes ticket #1272.
links on the Admin > Maintenance page to allow you to turn it on and
off. This should be efficient since we cache all vars and look them
up on every request anyway.
This also allows us to have the Fix task enable maintenance mode while
it's running which greatly reduces the chances that somebody will come
along and hork the database while we're tinkering with MPTT pointers.
Fixes ticket #1259.
separate from a successful or failed login.
1) Rename user_login_failed event to user_authenticate_failed
2) Rename failed_logins table to failed_auth (bump Gallery module to
v27 to rename the table)
3) auth::too_many_failed_logins -> auth::too_many_failures
4) auth::record_failed_auth_attempts -> auth::record_failed_attempts
auth::clear_failed_auth_attempts -> auth::clear_failed_attempts
In the graphics_rules table height and width set the maximum height and width
values and should be equal. Initially, the height on the resize target rule was
less than the height, which artificially constrained images in portrait mode.
**Note"" this fix requires an upgrade to version 22. All the resizes will be flagged
dirty.
