| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I5c0e7f096261251bc036263248774b4ef812905d
|
|
|
|
|
| |
Bug: T253188
Change-Id: Ic358946099a3424a3d1c2615feb14e74b6336a0e
|
|\ |
|
| |
| |
| |
| |
| | |
Follow up to Id258b1ec2ae7008fc4d586d0647a5131ec889fe6
Change-Id: Iafbfc084efd096165dafcec403d34ccb67edc1ec
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: T259738
Change-Id: Id76f7c5179fa351a4aba4d5226437ef6338bbdce
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If a block cannot be inserted, it is assumed that there is an
existing block against the target. That block is then retrieved
from a replica database using DatabaseBlock::newFromTarget. We are
seeing errors as a result of assuming that newFromTarget always
returns a block object in this situation.
Sometimes a block could not be inserted because there is an existing
block, but the existing block could not be retrieved. This could
happen if:
* there is an existing block but it is not in the replicas yet
* an existing block was removed after the insert attempt, but before
the retrieve attempt
Check whether DatabaseBlock::newFromTarget returns a block object,
and display a message explaining the situation if not.
Bug: T259212
Change-Id: I1737e3a69748ebaa743e87b185ba1e3b92afec8c
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Test Plan:
* Logged-in, preview a change adding {{subst:CURRENTYEAR}}
to User:You/common.css, User:You/common.js and Main_Page.
* Observe that it expands to 2020 in all cases.
* Run `(new mw.Api).saveOption('pst-cssjs', '0')`
* Try again. Observe that the first two are now left unchanged.
Bug: T236828
Change-Id: Ic13e2ff3b90f0c3587cdb1e97fffcd96be650e0e
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: Ieef94c8a7da60df235a307f085b7d5afc5b1c884
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Submitted by: joernc_unibi (Joern C.)
Bug: T30162
Bug: T245387
Change-Id: I99f0ae363096da49b3f840af999821a81767584e
|
|\ \ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Do not use bit operator on bool as it does not work the same way.
|= is not a short form of bool or (||) and assignment (=).
It is the short form of bitwise or (|) and assignment (=)
Change-Id: I64988cd3aeb8f4cbc53b0b866f1ac96f12976cca
|
|\ \ \ \ \ \ |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
loadOOUIDefinition() may return false when an extension is (ab)using
the ResourceLoaderOOUIImageModule class to define custom icons (e.g.
VisualEditor), and it doesn't include definitions for all of the
available themes, perhaps because your skin is using a custom theme.
As noted in a code comment elsewhere in this file: "that's okay, it
will just use the defaults".
Bug: T260059
Change-Id: I5468906b5efc4b727c6967ab5958fa6657e355ee
|
|\ \ \ \ \ \ \
| |_|_|/ / / /
|/| | | | | |
| | | | | | | |
filtered GTID list"
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
filtered GTID list
This is less confusing as it only mentions GTIDs that were actually waited on.
Bug: T221159
Change-Id: Ib821e63512d40fa38df8843cc8bb24add77a0d1b
|
|\ \ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This removes invalid values from the query and cast everything to int
The database field is known as integer and there is no need to pass
strings to the database
In case of all namespaces are invalid the parameter is ignored and all
namespaces are returned
Bug: T253098
Change-Id: I166ef53aed669de61c20db42e3da75783ebc3970
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
https://en.wikipedia.org/wiki/FNV_hash_function was renamed,
update the url.
Change-Id: Ib06b8f939dc1b2456e2263c6649d032d0def0d44
|
|\ \ \ \ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | | |
Code exists in CreditAction class
Change-Id: Ideeecb19b484ef7b76f18745258aa550aa0acbe0
|
|\ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
When MediaWiki is not behind an intranet, it is completely safe to
add the Access-Control-Allow-Origin: * header to responses and allow
cross-origin sites to access the REST API.
Bug: T232176
Change-Id: Ic0658039a6a46ee4f50c76f5d100450fdef7525a
|
|\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Bug: T257990
Depends-On: I132513a897e40162acd973b9817b3103f4a33333
Depends-On: I363f8c9e39298ab9f74274d288681f2ef88a1894
Change-Id: I13bedd8c14de419ff1a88d5087f5669652cd3123
|
|\ \ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|/ / /
|/| | | | | | | | | | |
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
The static function is using the global SpecialPageFactory
Change-Id: I378d7dcf92b6e38f712de1138673bc77e2934f51
|
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | |
| | | | | | | | | | | |
Change-Id: I51802fa4c3511c22346fb2440dc6038bc340d6cf
|
|\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
For easier searching, add the matching tooltip-ca-* variants
of the watching messages.
Bug: T253135
Change-Id: I286372a608d79e34404a62a3a4487bdaf2e95017
|
|\ \ \ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|/ / / /
|/| | | | | | | | | | | |
|
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | | |
* Suppress the "Multiple unclosed formatting tags on the page" errors,
they always appear with "Missing end tag" errors and are redundant
* When displaying "Missing end tag" error, show the HTML syntax for
closing tags, rather than just the name.
* When there are multiple linter errors, show them in a numbered list
rather than bulleted, as they might otherwise look identical.
Bug: T259570
Change-Id: I204a6466005cba1d6681dcf9884b5d3098f83371
|
|\ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Right now, for autoloading, it depends on a complex logic of
DirectoryIterator and a hard-coded set of extension.json names.
This is not useful and also doesn't pick up Wikibase extension.json
files because they are extension-repo.json and extension-client.json
which in turn causes all sorts of warnings
This patch fixes that
Bug: T243124
Change-Id: Iaf47a6f485f4ba2769b4e384278c8121366dd9a5
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
concatenateChunks can fail for many reasons, including
- corrupt files
- don't pass abusefilter
- exceeds file limits
etc.
When we're unable to concatenate the chunks, it shouldn't be
considered a job failure. It just didn't pass whatever requirements,
and the user should be informed about it, but the job actually
did what it had to do and it's not the software's fault that the
file isn't any good.
Besides, this job is only triggered on async uploads.
Synchronous uploads call concatenateChunks directly, and no exceptions
are thrown there when it fails to concatenate: we simply inform the
users what happened - same as what's already happening for these async
uploads as well.
TL;DR: The job did what it has to do.
Bug: T204881
Change-Id: Idf166d2fb509211080fb9e5f0e085467ef7d7ef2
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Same rationale for excluding package.json.
Change-Id: Ia56c02ac38db29de02c7ea983adc81f9b632a419
|
|\| | | | | | | | | | | | | | |
|
| | |_|_|_|/ / / / / / / / /
| |/| | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
We already exclude package.json so having Gruntfile.js is kind of useless
since you don't know what versions of packages to install.
Change-Id: I15dcb68e45a94c35c3500711eafb6573824dd472
|
| |_|_|_|/ / / / / / / / /
|/| | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
Change-Id: I1f30f66881f842682085d7c81af5fb6967376346
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
OutputPage::headElement calls OutputPage::getRlClient, which should be
delayed for as long as practical, as it prevents the addition of any
further ResourceLoader modules. One such module is
ext.echo.styles.alert, which is added during a hook run during
SkinVector::getTemplateData.
Fixes regression introduced in 8acef095b9f23674e41ccc008ce00d1e9ef06594
Bug: T259872
Change-Id: Ibe1f07346cb19a7e40b00db3f72a615bb9cde6a5
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
This copies all of the non-Wikimedia specific entries from Wikimedia's
firejail profile, incluing disallowing access to /sbin and its variants,
important system files and various system utilities. Notably it blocks
access to /run which typically has UNIX sockets that allow for sandbox escape.
The one entry not copied over is disallowing /home because firejail does
that already, and it can cause problems if your development setup is
inside /home, but FirejailCommand already handles all of that appropriately.
Change-Id: I4fd1d3005f18c249b45c9b9a72dff2bef6542b61
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|/ / / / / / / /
|/| | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
Also, fixing two data type drifts in Postgres:
- lc_key was varchar (with no binary flag) in MySQL but TEXT in
Postgres while PG supports varchar. Changing PG to varchar.
- lc_value was BYTEA but the rest of varbinary fields are mapped to
TEXT, changing it to TEXT data type.
And fixing primary key of these tables in Postgres too as it was a unique index instead.
Bug: T198811
Bug: T164898
Bug: T230428
Change-Id: I50305556bd870461d05f98c5272cf1d6a65deb15
|
|\ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| |_|_|_|_|_|_|_|_|/ / / / / /
|/| | | | | | | | | | | | | | |
|