<style> and <link> tags are metadata tags, they shouldn't split the <p>
tag when p-wrapping content.
Bug: T208901
Change-Id: I2ef5da68c9ccde4477d8295dfe4abf8497c5d26e
phpunit-patch-coverage assumes that the filename matches the classname
as a performance optimization. And for most test cases, this is true. We
should enforce this with PHPCS, mostly to help developers not make
mistakes.
Test cases that have mock classes will need to ensure that the test case
class that matches the filename comes first, since that's the only class
the sniff will look at.
Tests in GlobalFunctions/ and maintenance/ are still exempted for now,
since they don't match yet.
Change-Id: Iede341504290f5ba2da1c81908069ba9d465600f
The classes were renamed in 9bf39163, this updates the test cases to
match. Also take care of XCF while we're at it too.
Change-Id: Iaaeee93e496af6cdd610df5bc75302ecfe273f64
The editing restrictions will be split by type and add a heading for each type.
The namespace will be linked to Special:AllPages with the namespace set so the
user can see what pages the user is blocked from.
Bug: T204990
Change-Id: Idb1de20c1a780562b072ea350e5ba7dd1518d177
In 8 years, this is the first time I see this directory exists
and that there is a Makefile that would write to it.
I don't know if anyone uses that, but PHPUnit auto-creates this
directory as needed. Hence, it need not exist ahead of time.
It seems most contributors generate code coverage by invoking
PHPUnit directory, which requires a path to be specified.
Per https://mediawiki.org/wiki/Manual:PHP_unit_testing/Code_coverage,
this tends to be docs/coverage, not docs/code-coverage.
Change the Makefile to write there as well, as better example,
and also add it to gitignore.
Change-Id: I0a4cf716ea9b7fae89c282945b160b0dc7b2d02f
Currently, there are 3 block messages: sitewide, partial with restrictions, and
non-editing partial blocks. This will add namespace restrictions to the
partial editing blocks message type.
Bug: T204985
Change-Id: Ic17d5459e67c267fdee1fb2513d67428148ac85d
AuthManager::autoCreateUser() causes createAndPromote.php to give error
"Automatic account creation is not allowed." when
$wgGroupPermissions['*']['createaccount']=false is set. Anonymous user
checks should be skipped for maintenance scripts.
Change-Id: Ib61889a758e542abe991707d8b7853a25cfed8e9
Provide backward compatibility for callback functions in
GuzzleHttpRequest, which was missing in T202110, and restore
GuzzleHttpRequest as the default provided by HttpRequestFactory.
Bug: T212175
Depends-On: I4b45e79d35252d13f714f3271b87301ca515121a
Change-Id: I60d1a034b44874f6d24a04058db264eeb565f5e1
So far, our key derivation code assumed that it has control over
the salt used by the derivation routines, however I want to add Argon2
support and it doesn't work this way: password_hash() generates the
salt itself, and the only way to verify a password is by using
password_verify(). Current way the things are done doesn't support it
because it relies on the result of password hashing with parameters we
provide to be deterministic.
Therefore, I'm deprecating Password::equals(), as well as whole concept
of comparing Password objects - it's used only in tests anyway. It's
getting replaced with verify() that only accepts password strings.
Uses of old function are fixed with exception of a few calls in tests
that will be addressed in my Argon2 patch.
Change-Id: I2b2be9a422ee0f773490eac316ad81505c3f8571
Calling Title::getLinkURL or any other method that relies on
getFragmentForURL on a title with an unknown interwiki prefix
was triggering a fatal error. With this patch, that situation is
handled more gracefully.
Bug: T204800
Change-Id: I665cd5e983a80c15c68c89541d9c856082c460bb
* Introduce MSCompoundFileReader, which reads the CFB directory and
detects the file type from well-known names in the root directory
* Do not detect a ZIP file if the EOCDR is not at the end. Other
containers, especially CFB files, may contain ZIP files embedded
within them in the last 64KB, but this is not a security concern
unless the EOCDR is exactly at the end of the file.
Bug: T40432
Change-Id: Id5b1a258ccf3c3c8951e32f6b7a5b1bafe941082
This adds a UI for blocking namespaces to Special:Block
and a namespacerestrictions parameter to the block API.
The number of namespace restrictions in a single block
is not limited as page restrictions are.
The checkbox allowing the blocker to specify whether
the target can edit their own user page is normally
disabled for a partial block, but is re-enabled if
the block is to the user talk namespace.
If the config $wgBlockAllowsUTEdit is set to false, the
checkbox will not appear, and the target will not be
able to edit their own user talk page if they are
sitewide-blocked, namespace-blocked from the user talk
namespace, or page-blocked from their user talk page.
Bug: T204986
Change-Id: I9e231ad109d7285486ec332b26780339592b8df7
Reference the fixture files relatively instead of absolutely,
this is done for most other references to data files as well
I believe.
Use plain arrayEquals(), which seems to suffice here. In PHP 7 at
least, regular == doesn't require the declaration order of the
keys to be the same in order to evaluate to true.
Change-Id: Iddc874ec811f5c960e13d480d70bcb20334cfa1e
This begins work on making namespaces a valid restriction type. The CRUD
operations of BlockRestriction can now handle namespaces. Since
NamespaceRestriction implements Restriction, enforcement should start working
immediately, but testing enforcement will come in a subsequent patch since it's
impossible to create them.
Bug: T204991
Change-Id: I7264b452d9ad788c146d6ea25d01d4d7cb5ac4f6
getNativeData() is under-specified - callers can do nothing with the
value returned by getNativeData without knowing the concrete Content
class. And if they know the concrete class, they can and should use
a specialized getter instead, anyway.
Basically, getNativeData is overly generic, an example of polymorphism
done poorly. Let's fix it now.
Bug: T155582
Change-Id: Id2c61dcd38ab30416a25746e3680edb8791ae8e8
This code doesn’t use any MediaWiki-specific code, so rename
MediaWiki\Services to Wikimedia\Services and move it below libs/. (Of
course, this does not apply to the MediaWikiServices subclass.)
Class aliases are added to retain backwards compatibity for now.
Bug: T211608
Change-Id: Ic14ea28ef21c359695b309d4293dbaaf5deedc09
We were creating the `<g>` element without specifying a namespace,
which caused the library to add `xmlns` attributes with the document's
default SVG namespace to elements that we appended underneath it.
(At least, that's what I think was happening.)
Specify the SVG namespace when creating it to avoid the mess and
reduce resulting file size.
Change-Id: Ida27494aeae9dece16f878c16cf9aa582e6deac3
While it shouldn't be causing any rendering problems,
doing so is semantically incorrect.
Bug: T213507
Change-Id: Ic86cd2bf3028eb24ad60db7ffa9498dd86edd4a5
This might hint at an edge-case in the PHP CodeSniffer sniff that should
detect if methods are separated by a single empty line. Feel free to
investigate. I, personally, can't invest more time in this than
suggesting this quick fix.
Change-Id: Ib3c60eac76f255b4fe929f7933de256222716576
ExtensionRegistry is a rather special singleton that can't use the normal
MediaWikiServices reset due to its early initialization, so introduce
a ->setAttributeForTest method to override attributes that are typically
loaded from extension.json.
Bug: T200013
Change-Id: I9e62a02ed2044c847e9ab2dcdfab094001f88986
The filter attribute will often have things like filter="url( #foo )"
These local to the file filters in svgs should be fine (We already
disallow non-local xlink:href attributes on <filter> elements). In
fact, users can already do the exact same thing by doing:
style="filter: url( #foo )"
Bug: 67044
Change-Id: Ib25328c160c0d5ea7e01dc84616b76e1b9dcd0eb
This reverts commit 91fc748030.
Hence it reapplies I6312a36911e5b73d773452fefef7ff25b9af08a4.
The changes made by this commit are (excluding the cases
checked for earlier):
* An action can only be blocked if prevents() is true/null and
isBlockedFrom() is truthy. Previously, any action other than
'edit' or 'create' would be blocked if prevents() was true/null,
regardless of isBlockedFrom().
* If an Action can be constructed, and requiresUnblock() is
false, the action won't be blocked. Previously, requiresUnblock()
wasn't checked.
This commit was previously reverted because it exposed that
EditEntityAction::requiresUnblock in Wikibase wrongly returned
false (fixed in I99061230023da2bbd0f98190a2907ca2e9717a4c).
Other potentially similar cases were audited in T211048.
Bug: T208862
Change-Id: If74a1d422290b8c62b7a7a8922621c73c9598269
Adds a way to set an array of options for a password policy. Currently
there is one option, 'forceChange', which forces the user to change
their password (if it fails the given check) before logging in.
Bug: T118774
Change-Id: I28c31fc4eae08c3ac44eff3a05f5e785ce4b9e01
