To follow up I39b0825c, this change replaces the existing non-unique
index on the column with a unique index, to help avoid some of these
sort of bugs in the future.
Bug: T193180
Change-Id: I932478c9c6a13210bc9dff75286d0f08da56682c
Adds a maintenance script to populate the field, has that be
automatically run during update.php, and drops the no-longer-needed
default value on the column (where possible: mssql has some sort of
constraint thing going on that I have no idea how it works).
Bug: T59176
Change-Id: I971edf013a1a39466aca3b6e34c915cb24fd3aa7
Table defining tag names for IDs. Also stores hit counts to avoid expensive queries on change_tag
See T185355 for more information
Bug: T193867
Bug: T185355
Change-Id: I4fd943589b3ed304471304c8beda15327a8edbcf
PostgreSQL allows setting an "owner" column for a sequence, so if that
column is dropped then the sequence will be dropped too. We should
certainly take advantage of that when creating duplicate tables for unit
testing (particularly when $temporary is false), and we may as well do
it for our permanent tables too.
Change-Id: I4822ac33298e3f3ef59f4372a24aa0866a6e66ae
MediaWiki doesn't support PostgreSQL < 9.2, so drop the support for
older versions.
At the same time, since we're messing with the DatabasePostgres::insert()
code anyway, let's start using ON CONFLICT DO NOTHING for PG >= 9.5.
And since we're doing that, let's do the same for
DatabasePostgres::nativeInsertSelect().
Change-Id: I7bf13c3272917ebafeaff11eb116714a099afdf3
This should have been done long ago. Now it is being done.
This also changes ar_text_id to NOT NULL, since it should never be null
anymore, and DEFAULT 0 in preparation for MCR stopping writing it.
Bug: T33223
Change-Id: I18f1c740b7537c7dc3cfeba9b241d0a9f31caa34
Revisions deleted before MediaWiki 1.5 do not have a value in this
field. This is going to be a problem for migration to the MCR schema, so
provide a maintenance script to clean this up.
Then, for good measure, change the schema to make the field
non-nullable.
Bug: T182678
Change-Id: Ie2e11f12a30f379db32c3e074658012c6f93adb0
The site stats table holds a bunch of metric fields, two of which are of
data type "bigint unsigned", 3 are "bigint" (signed) and one is int
(signed). Also the default values differ widely: It is 0 on the
"unsigned" fields and the "int" field, but -1 on the three others. This
patch makes all of this more consistent:
Set all fields (except the ss_row_id, which isn't changed) data type to
"bigint unsigned". Also set NULL as the default value for all those
fields. Obviously -1 isn't a possible default value any more. Also, 0
can easily be mistaken for a real value (e.g. ss_active_users=0 -->
"there is nobody active on this wiki"). NULL, by it's definition, is the
value of choice for a value to insert into fields of which we don't know
a correct value.
The respective patch files were tested locally against MySql, Sqlite,
Postgres and SQL Server 2016. Neither oracle nor the upgrade with
update.php was tested.
Bug: T56888
Change-Id: I7d42aae434852a56b6f8dd559d8a5f3bce416021
This begins the process of merging image_comment_temp into the image
table by adding the needed column. Iab5f5215 will adjust the code
to use it and to add the necessary migration script.
Note this patch puts the new schema change in the 1.30 section rather
than the 1.31 section. This allows Iab5f5215 to have migrateComments.php
migrate the comments directly to the new field instead of having to
populate and then depopulate the temporary table.
Bug: T188132
Change-Id: I2485c5a758bf03bb2b4991eea920abd9d0d30bda
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
Schema additions/updates for MySQL, SQLite, PostgreSQL, MSSQL
and Oracle to add new tables:
* content
* content_models
* slots
* slot_roles
See also https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema
Bug: T174028
Change-Id: I30a3a9834d54d0e6957553d91908b2b73b2c802f
As discussed in I7d42aae434852a56b6f8dd559d8a5f3bce416021 primary keys
are needed to perform various schema changes on the site_stats table.
This patch aims to introduce primary keys for all supported dbms.
The respective *.sql patch files were tested locally against Postgres
and SQL Server 2016. Please note that neither the patch file for Oracle
DB nor the mediawiki upgrade through update.php was tested.
Bug: T56888
Change-Id: Id10e221f0dc120bc09afc22596fd1dbecbf6a61d
* Fix schema for image_comment_temp.
* Provide values in CommentStoreTest::provideInsertRoundTrip() for
columns where the PG schema doesn't have a default value but the MySQL
schema does.
* Call nextSequenceValue() from CommentStoreTest::testInsertRoundTrip().
* Correctly handle $options being the string 'FOR UPDATE' in
DatabasePostgres::selectSQLText()
* Correctly handle the initial table in DatabasePostgres::selectSQLText() FOR
UPDATE mangling.
* Correctly handle aliases in DatabasePostgres::selectSQLText() FOR
UPDATE mangling.
Tests in PG are still going to be broken thanks to the fact that
nextSequenceValue() and insertId() can't be separated by another
nextSequenceValue()/insertId() pair. That should be taken care of by
T164898/T164900.
Change-Id: Ia770a003ca9170ab8bcc1436d8afe30700e00ada
This reverts commit b67f40e5b0.
There was an issue that the web installer, when inserting initial
values into the db table site_stats, would not insert any value for
ss_active_users. That lead to some places, most notably
Special:CreateAccount, to show off -1 recent contributors.
The commit to revert solved this by setting a default value of 1 for
the ss_active_users field in the database schema. However, while the
default schema has been changed, there hasn't been any schema update
procedure implemented. Also, the default of 1 is inconsistent with
other defaults in that table.
Revert that schema change completely. Instead, make the web installer
insert 0 to the field ss_active_users (just like it does with all other
fields in that table).
Bug: T56888
Change-Id: I4298754c2238f6e5447a5df77a4ada722ba302b2
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
This will allow for replacing the limit-and-offset queries with queries
that page in a sensible manner.
Bug: T59176
Change-Id: If5c137f68496772f3fff3a735b7b0c388426e518
The plan here is to take it out of 1.27.0-wmf.12 and put it back in
1.27.0-wmf.13.
Since BotPasswords depends on SessionManager, that's getting temporarily
removed too.
This reverts the following commits:
* 6acd424e0d SessionManager: Notify AuthPlugin before calling hooks
* 4d1ad32d8a Close a loophole in CookieSessionProvider
* fcdd643a46 SessionManager: Don't save non-persisted sessions to backend storage
* 058aec4c76 MessageCache: Don't get a ParserOptions for $wgUser before the end of Setup.php
* b5c0c03bb7 SessionManager: Save user name to metadata even if the user doesn't exist locally
* 13f2f09a19 SECURITY: Fix User::setToken() call on User::newSystemUser
* 305bc75b27 SessionManager: Don't generate user tokens when checking the tokens
* 7c4bd85d21 RequestContext::exportSession() should only export persisted session IDs
* 296ccfd4a9 SessionManager: Save 'persisted' flag in session metadata
* 94ba53f677 Move CSRF token handling into MediaWiki\Session\Session
* 46a565d6b0 Avoid false "added in both Session and $_SESSION" when value is null
* c00d0b5d94 Log backtrace for "User::loadFromSession called before the end of Setup.php"
* 4eeff5b559 Use $wgSecureCookie to decide whether to actually mark secure cookies as 'secure'
* 7491b52f70 Call session_cache_limiter() before starting a session
* 2c34aeea72 SessionManager: Abstract forceHTTPS cookie setting
* 9aa53627a5 Ignore auth cookies with value 'deleted'
* 43f904b51a SessionManager: Kill getPersistedSessionId()
* 50c5256352 SessionManager: Add SessionBackend::setProviderMetadata()
* f640d40315 SessionManager: Notify AuthPlugin when auto-creating accounts
* 70b05d1ac1 Add checks of $wgEnableBotPasswords in more places
* bfed32eb78 Do not raise a PHP warning when session write fails
* 722a7331ad Only check LoggedOut timestamp on the user loaded from session
* 4f5057b84b SessionManager: Change behavior of getSessionById()
* 66e82e614e Fix typo in [[MediaWiki:Botpasswords-editexisting/en]]
* f9fd9516d9 Add "bot passwords"
* d7716f1df0 Add missing argument for wfDebugLog
* a73c5b7395 Add SessionManager
Change-Id: I2389a8133e25ab929e9f27f41fa9a05df8147a50
Bot passwords are something like OAuth-lite, or Google's application
passwords: the bot can use API action=login to log in with the special
username and password, and will then be allowed to use the API with a
restricted set of rights.
This is intended to provide an easy migration path for legacy bots and
for bots on wikis without OAuth, since AuthManager is going to greatly
complicate non-interactive authentication. If OAuth is available, an
owner-only consumer would be a better choice.
Bug: T121113
Change-Id: Iaa4015e00edbfbfaedcc8b2d27a2d3fd25009159
Depends-On: I7e15331efb162275c4116bcae61f19d6b884cbe3
Change I1c7f3a84f10df05d6b37dccbad4c8232edf51580 causes
an existing foreign key assumption (under PostgreSQL) to be
violated upon deleting a page. This foreign key assumption does not
explicitly exist in MySQL, and is not implied via documentation. So
it was probably never needed in the first place.
Don't create the foreign key constraint in PostgreSQL, and drop it
if it already exists when running update.php.
The constraint was previously created with an implicit name, so
drop the constraint involving the specified column name (rc_cur_id),
rather than hard-coding the name of the constraint itself.
This bug probably exists under Oracle and MSSQL as well, but no attempt
was made to address it there.
Bug: T76254
Change-Id: I2abd650c8ce83c5b725aec0545fff14a927a305a
* Also tweaked the query so MySQL avoids doing a page_name
index scan when it should start with the link table index
* Added population script (triggered by update.php)
* Also removed uniqueness from some indexes where it is redundant
* Renamed two confusing variables
Bug: 60618
Change-Id: Icca99b6ae0ef76cb77695faf82c615516191da36
Special page PageLanguage to set the page language of a page.
To enable the feature, set $wgPageLanguageUseDB to true
and assign the 'pagelang' user right to a user group.
Bug: 35489
Change-Id: I0f82b146fbe948f917c1c5d29f7469644d797e80
Change-Id I427c6de5a0a29b43cff755db0eb8a750db620173 increases the
probability that a null byte will attempt to be stored in the
lc_value column. PostgreSQL does not allow that byte in a text
column, so convert the column to bytea.
If the column already contains corrupted data, the upgrade routine
might fail. To prevent this, delete the contents of the table before
changing the type.
Bug: 62098
Change-Id: Ie8368bde398b2ae4d3cfc9ee7bf35874bd2ded68
Follows up I217c42656fb877ff35a36eb446a22bdaf119faac
That change introduced a syntax error during update. I have verified
that this fixes the syntax problem so that update.php runs, but have
not verified that the new functionality behaves as intended.
Also, the PostgreSQL schema changes introduced during the update
process were not present at all in a fresh install to PostgreSQL. Add
analogous changes to tables.sql.
Bug: 64807
Change-Id: I736344839ec478216402fdfe260968afbd663498
The column recentchanges.rc_cur_time is no longer populated by SQL,
so PostgreSQL must be changed to allow the NULL value for it.
In MySQL, the empty string is used as a surrogate for NULL, but that
is not allowed in PostgreSQL.
Bug: 61318
Change-Id: I6733ef11152d545382bec087d992515dcf9aec0b
Add functionality to expire users' passwords:
* Adds column to the user table to keep a password expiration
* Adds $wgPasswordExpirationDays, which will force users to reset
their passwords after a set number of days. By default, this set
to false, so passwords never expire.
* Adds a default grace period of 7 days, where if the user's password
is expired, they can still login, but are encouraged to reset their
password.
* Adds hook 'LoginPasswordResetMessage' to update reset message, in
case an extension wants to vary the message on a particular reset
event.
* Adds hook 'ResetPasswordExpiration' to allow extensions to change
the expiration date when the user resets their password. E.g., if
an extension wants to vary the expiration based on the user's group.
If the user is in the grace period, they get a password reset form
added to the login successful page. If an extension prevents showing
the login successful page (like CentralAuth), it should be updated to
show a password change form during the grace period. After the grace
period, the user will not be able to login without changing their
password.
Also prevents a successful reset if the user is "changing" their
password to their existing password.
No passwords will expire by default. Sites will have to call
User->expirePassword() from their own maintenance script to trigger a
password reset for a user.
Bug: 54997
Change-Id: I92a9fc63b409b182b1d7b48781d73fc7216f8061
Fixing bug #54404 requires querying against logging.log_user_text, which
is currently unindexed. Add an index, to prevent performance from being
adversely affected by the fix.
Bug: 54432
Change-Id: I6b2af65c75bbee57377cb1ec2e75ea41a5091f80
