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
* New fields: ar_id, el_id. el_id is presently not used for
anything, but will help with online schema changes.
Bug: 15441
Bug: 39675
Change-Id: Ib6b0fc3736d173fa4ba7b786ecfc710b2f4711bb
No feature flag, and also not deployed on WMF wikis. Asking for schema changes by the time we branch tomorrow is just unfair
This reverts commit e478c230f6.
Change-Id: I125c30e76fa04679cc04ae7b8728ae3a61f35194
The existing field to differentiate between kinds of recentchanges rows is
the rc_type field. We want to allow extensions to insert their own custom
data into recentchanges, but we have learned via the NS_* series of constants
that requiring extensions to "register" a specific number is very error prone.
The solution, which this commit implements the first phase of, is to utilize
a new 16 byte string field rc_source. Within that field change types will be
prefixed strings such as 'mw.edit' and 'mw.new'.
This commit adds the new field and begins populating it with data. At some
point in the future the rc_type field will be dropped. While WMF wiki's will
simply wait out the 30 day recentchanges history, other wiki's have the option
of letting update.php populate rc_source, or manually applying the db change and
utilizing the PopulateRecentChangeSource maintenance script.
Change-Id: Iaddd6c446373a68d31586ed54346db7d04e13b2c
this:
CREATE TABLE profiling (
pf_count INTEGER NOT NULL DEFAULT 0,
pf_time FLOAT NOT NULL DEFAULT 0,
pf_memory FLOAT NOT NULL DEFAULT 0,
pf_name TEXT NOT NULL,
pf_server TEXT NULL
);
The current use of NUMERIC(18,10) very rapidly overflows the pf_memory column,
generating errors. Also, the NUMERIC is very much slower than float, and in
this case it has no advantages.
Bug: 55722
Change-Id: I48b00d55aaed821a4ceb9365033817a3b477d71a
Follow-up I68e8c0bb23f185c0f996a8905f6d437db3080aa1
Deleting those fields also from tables.sql definition
for mssql, oracle and postgres
Bug: 34960
Change-Id: I1867536c9161abed0b23428d3c840d16a05cba56
This was an experimental authentication system intoduced a couple
of years ago with a pretty narrow use-case. It's been pretty much
ignored since introduction, and makes login more complicated than
it needs to be.
I didn't drop the external_user table on the off-chance someone
out there actually has data in it, but they should use AuthPlugin
for their external authentication needs.
Change-Id: I794338dbb75961ee033d41fa44bb7aa22e54f447
The iwlinks and langlinks modules continue parameters imply ordering by
page then prefix then title. But in certain modes, the actual queries
use a different ordering, which may result in skipped or repeated
results.
This changeset fixes that. To do so, it needs to re-add an index
iwl_prefix_from_title which was mistakenly removed in 2010 (r69721). And
while it's doing that, it cleans up errors in the sqlite and postgresql
handling of the iwlinks indexes too.
Also, per Asher, make the iwl_prefix_from_title and
iwl_prefix_title_from indexes non-UNIQUE.
Change-Id: I607e8bf9183a2d8152a6127a81c83a0b5bba0c61
Create ContentHandler field for PostgreSQL
(for installer and the update).
TEXT was chosen as replacement for MySQL VARBINARY(32)
Change-Id: Ia86ae79d37517630e1767dfb976604bbb174104b
Previously, whenever we blocked a user, its IP address would be
autoblocked whenever he tries to edit a page. Thus when later unblocking
the username, he would be automatically blocked again if we forgot to
clean up is IP.
This patch introduces a the ipb_parent_block_id column in ipblocks table
to track which block triggered the autoblock command. Thus, when deleting
the original block we can easily remove all subsequentautoblocks.
Schema updaters for MySQL, SQLite and postgres have been added to the
patch but not for the other database types such as ibm_db2, mssql and
Oracle.
Change-Id: I4aa820ae9bbd962a12d0b48b6c638a1b6ff4efc9
* More allowed data type conversions from MySQL to PostgreSQL
* Allow for data type SMALLINT: seen for first time!
* Handle CREATE TYPE: check for dupes, and allow the name as a valid data type.
* Remove the now-deprecated user_options column.
* Add new table "config"
Change-Id: I18e67bcb131b88bfaea7e736f302dd79ebfc9b82
The 'math' table will no longer be created on a default install unless you've explicitly enabled the Math plugin at install time; the usual update.php procedure will add it in.
Postgres, Oracle, MSSQL, and DB2 variants are included -- broken out from the core files -- but have not been tested.
I know there has been some code duplication in parser test infrastructure but could only find one instance of the parser test temporary table setup to remove the 'math' table from (the extension adds it back via the hook). If the phpunit-based runner breaks, please track it down and fix it there too.
* NOTE: this commit removes any semblence of tsearch compatibility with pre-8.3 PostgreSQL
* Make new-installer work against PostgreSQL
* Remove SearchPostgres.php's call to pg_fetch_result. I think this is the only one outside of the vestigtial old installer code.
