The $baseRevId in WikiPage::doEditContent is used only to indicate what
revision an edit reverted to. It is not used to indicate the actual base
revision of an edit in any sense. Specifically, EditPage never sets it.
So, this change renames the parameter to $originalRevId to match $undidRevId.
It also renames PageUpdater::setBaseRevisionId to setOriginalRevisionId.
Further, this introduces a paramter to PageUpdater::hasEditConflict():
Before this change, PageUpdater::hasEditConflict() was based on the
revision set via PageUpdater::setBaseRevisionId(), assuming the semantics
of "base revision" used by EditPage. However, this is NOT how the $baseRevId
parameter in WikiPage works.
Bug: T197685
Change-Id: Ib78257d4d6ee7c4ec093d5706904c599b02c73e0
Hooks [UploadForm:BeforeProcessing] and [UploadForm:initial] get SpecialUpload
object as their parameter (NOT the UploadForm object).
Also replaced obsolete note "use UploadVerification and UploadVerifyFile"
with modern "use UploadVerifyUpload".
Change-Id: I09ac5b238c8619c94978bdc771653127d3a6264d
This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
This file is a disaster, but now at least we actually wrap at 80 chars
for all the hooks, not just the ones where the developer felt like it.
Change-Id: I10d3d51412af29b135fd7e9a0393ff0b57eb25aa
Many of these are still soft-deprecated, so tracking down their age
and kicking off the full deprecation process is hard, let alone
actually removing them. Doing this makes that future work easier.
Change-Id: Ib096190accceabf9082f621ba96243f7dedb025d
This allows extensions to essentially reimplement Linker#makeImageLink
completely. Before this wasn't 100% possible as these three are needed for
that.
Inspired by wikiHow's core hacks to /includes/Linker.php, which can now be
moved to an ImageBeforeProduceHTML hook subscriber. wikiHow uses those
changes together with the WikihowArticle extension to heavily modify the
article DOM for various extensions and the default skin.
Change-Id: I8b5ab42d9cf021d66b90d15be68a0239643c10e3
This will be useful when an extension does something expensive and wants to
make sure users don't put too much pressure on the system.
Bug: T194950
Change-Id: I8a396d07c2d5764a680d0e5536cd1f99edbe141e
Remove mention of this deprecated global in favour of documenting
the backend configuration instead.
Also update the outdated docs for where the sidebar is cached,
which was changed a while ago to use WANObjectCache instead.
See Skin::buildSidebar().
Change-Id: I3d34a760cc05cab6fe7ddd8684257d6ec6b49309
In change 4633f4d46a it was changed
to an interface implemented by both PreferencesFormLegacy and
PreferencesFormOOUI so that existing typehints for some functions
parameter would accept them both. Replace those typehints to use
HTMLForm instead. There was really no guarantee in the past that
they would only be given PreferencesForm or its subclasses, either.
Because the typehint change affects some hooks, note it as a
deprecation in MW 1.31 and a breaking change in MW 1.32.
Also add @since tags and correct some typos in code comments.
Follow-up to 4633f4d46a.
Change-Id: I61749f1d864cf68afe90cd9e15ba2d7a74252501
The PSR-4 autoloader requires "AutoloadNamespaces" keys to have a
trailing \ (\\ in JSON), so add a validation check for that.
Unfortunately the validation error isn't great, since it checks to see
if the property matches patternProperties, and when it doesn't, it
claims the property isn't defined since additionalProperties is false.
But it's still better than not failing when they are missing.
Bug: T189136
Change-Id: If01bd06cdd767fb704a8ff85cdf1c143e53fa4ca
The primary goal here is a defense in depth measure to
stop an attacker who found a bug in the parser allowing
them to insert malicious attributes.
This wouldn't stop someone who could insert a full
script tag (since at current it can't distinguish between
malicious and legit user js). It also would not prevent
DOM-based or reflected XSS for anons, as the nonce value
is guessable for anons when receiving a response cached
by varnish. However, the limited protection of just stopping
stored XSS where the attacker only has control of attributes,
is still a big win in my opinion. (But it wouldn't prevent
someone who has that type of xss from abusing things like
data-ooui attribute).
This will likely break many gadgets. Its expected that any
sort of rollout on Wikimedia will be done very slowly, with
lots of testing and the report-only option to begin with.
This is behind feature flags that are off by default, so
merging this patch should not cause any change in default
behaviour.
This may break some extensions (The most obvious one
is charinsert (See fe648d41005), but will probably need
some testing in report-only mode to see if anything else breaks)
This uses the unsafe-eval option of CSP, in order to
support RL's local storage thingy. For better security,
we may want to remove some of the sillier uses of eval
(e.g. jquery.ui.datepicker.js).
For more info, see spec: https://www.w3.org/TR/CSP2/
Additionally see:
https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy
Bug: T135963
Change-Id: I80f6f469ba4c0b608385483457df96ccb7429ae5
Single-file modules to src/, the remaining as sub directories.
A few highlights:
* mediawiki.Upload.BookletLayout. (stylesheet: no image references)
* mediawiki.feedback - Also move the image to its own images/ subdir.
* mediawiki.searchSuggest. (stylesheet: no image references)
* mediawiki.toc. (stylesheet: no image references)
Also updated any other references to 'src/mediawiki/' that I could find
in core:
* Fixed references in docs/uidesign/*.html
* Remove redundant exclude from jsduck.json.
After this, there are 4 files remaining in src/mediawiki,
which are the 4 files used by the actual 'mediawiki' base module.
Bug: T193826
Change-Id: I8058652892a78b3f5976397bd850741dd5c92427
There has long been a hack for previewing edits to user JS/CSS, where
OutputPage would pass an 'excludepage' parameter to
ResourceLoaderUserModule to tell it not to load one particular page and
would instead embed that page statically. That's nice, but there are
other places where we could use the same thing.
This patch generalizes it:
* DerivativeResourceLoaderContext may now contain a callback for mapping
titles to replacement Content objects.
* ResourceLoaderWikiModule::getContent() uses the overrides, and
requests embedding when they're used. All subclasses in Gerrit should
pick it up automatically.
* OutputPage gains methods for callers to add to the override mapping,
which it passes on to RL. It loses a bunch of the special casing it
had for the 'user' and 'user.styles' modules.
* EditPage sets the overrides on OutputPage when doing the preview, as
does ApiParse for prop=headhtml. TemplateSandbox does too in I83fa0856.
* OutputPage::userCanPreview() gets less specific to editing user CSS
and JS, since RL now handles the embedding based on the actual
modules' dependencies and EditPage only requests it on preview.
ApiParse also gets a new hook to support TemplateSandbox's API
integration (used in I83fa0856).
Bug: T112474
Change-Id: Ib9d2ce42931c1de8372e231314a1f672d7e2ac0e
* Remove left-over mention of the .php5 entry points in docs.
* Remove dead logic in NoLocalSettings for php5 entry points.
* Remove dead match in WebRequest for php5 entry points (they'd
redirect since 1.25, and not seen by PHP).
Change-Id: Ia0ee8588591860b8fe34030c8503f38e9bce31f3
Deprecated since 1.30, only had one caller (MobileFrontend)
which has been fixed since.
Bug: T140804
Change-Id: I39b594e3082ebe321bae463780cfadbfb3de1d5c
PlatformSettings.php is a standardized and recommended way for
re-distributors and packagers of MediaWiki to be able to tune
DefaultSettings.php as appropriate.
If includes/PlatformSettings.php exists, the installer will
automatically include it as part of the generated LocalSettings.php.
The main advantage of this system is that if the distributor wants to
change the default settings, all users will benefit immediately. And if
people want a vanilla MediaWiki experience, they can just remove the
inclusion from their LocalSettings.php.
This RfC
(<https://www.mediawiki.org/wiki/Requests_for_comment/PlatformSettings.php>)
was approved by TechCom.
Bug: T182020
Change-Id: I34f9a4acbe86b9c5c80ac16451b317ce5f6640f9
This makes it possible for extensions to add to the WHERE clause
with which unknown preferences are deleted.
Bug: T188966
Change-Id: Ifb22ca42207956f2b07333da026ff0b215a83930
It was never super popular anyway, APC was always the best option.
The project has no plans to move to PHP7, so it's quickly reaching
its end of life. Oh, and Fedora dropped it from their repos 2 years
ago.
Change-Id: Ia3257e86a6323d8943f04a5c05c72c0bd4c4b0a9
So that more than just PHP code and MediaWiki core can use it, but
also JSON-based static extension registrations. :-)
Change-Id: If22fccbb43c5b05db2a666d61ae8864ee9815e7d
* Some of the license selection code (License & Licenses)
has seen some minor refactor to make it more open to
reuse/extension elsewhere.
Extension:3D will make use of these for patent selection in
Iafb1e7e5da4b67f4c5ae7dda511d130ae10f748c
* License/TemplateSelectorLine has been modified so the text
can be wikitext (as needed for patent labels)
* uploadLicense was renamed to uploadTemplatePreview and
altered so it can be reused elsewhere. And, like
window.wgUploadWarningObj, uploadTemplatePreview is now also
added to `window` so it can be re-used from elsewhere (to
preview patent templates)
Bug: T182683
Change-Id: I0c097442aa557dd90eb5825553ebf892f9af8a01
This is a re-submission of I4f24e7fbb68.
As a first major step towards Multi-Content-Revisions (MCR),
this patch turns the Revision class into a legacy proxy for
the new RevisionRecord and RevisionStore classes.
Backwards compatibility is maintained for all but some
rare edge cases, like constructing a completely empty
Revision object.
For more information on MCR, see
<https://www.mediawiki.org/wiki/Requests_for_comment/Multi-Content_Revisions>.
NOTE: once this is merged, verify create/delete/restore cycle on beta,
ideally with emulated replication lag.
Bug: T174025
Change-Id: Ia4c20a91e98df0b9b14b138eb4825c55e5200384
This reverts commit 9dcc56b3c9.
With this patch applied, newly created revisions are sometimes not found
just after submitting an edit, until replicas have caught up.
Our best theory is that it somehow interfere with ChronologyProtector,
but we don't have a good idea how.
Also, as legoktm mentioned, the commit message is terrible and needs fixing.
Change-Id: Idf3404f3fa8f8d08a7fb2ab8268726e2c1edecfe
This adds support for a PSR-4 (<http://www.php-fig.org/psr/psr-4/>)
autoloader, so instead of needing to manually list each class, just the
namespace prefix is needed.
Extensions can set a "AutoloadNamespaces" property in extension.json to
register PSR-4 compatible namespaces to be autoloaded.
The implementation is based off of the example implementation
(<http://www.php-fig.org/psr/psr-4/examples/>) with some modifications
for performance, notably cutting down on function calls, and only trying
to look up classes that are namespaced.
The generateLocalAutoload.php script will ignore any directory that is
registered as a PSR-4 namespace.
Bug: T99865
Bug: T173799
Change-Id: Id095dde37cbb40aa424fb628bd3c94e684ca2f65
Importing revisions in MediaWiki has long been weird: if the username on
the imported revision exists locally it's automatically attributed to
the local user, while if the name does not exist locally we wind up with
revision table rows with rev_user = 0 and rev_user_text being a valid
name that someone might later create. "Global" blocks too create rows
with ipb_by = 0 an ipb_by_text being a valid name.
The upcoming actor table change, as things currently stand, would
regularize that a bit by automatically attributing those imported
revisions to the newly-created user. But that's not necessarily what we
actually want to happen. And it would certainly confuse CentralAuth's
attempt to detect its own global blocks.
Thus, this patch introduces "interwiki" usernames that aren't valid for
local use, of the format "iw>Example".[1] Linker will interpret these
names and generate an appropriate interwiki link in history pages and
the like, as if from wikitext like `[[iw:User:Example]]`.
Imports for non-existant local users (and optionally for existing local
users too) will credit the edit to such an interwiki name. There is also
a new hook, 'ImportHandleUnknownUser', to allow extension such as
CentralAuth to create local users as their edits are imported.
Block will no longer accept usable-but-nonexistent names for 'byText' or
->setBlocker(). CentralAuth's global blocks will be submitted with an
interwiki username (see Ieae5d24f9).
Wikis that have imported edits or CentralAuth global blocks should run
the new maintenance/cleanupUsersWithNoId.php maintenance script. This
isn't done by update.php because (1) it needs an interwiki prefix to use
and (2) the updater can't know whether to pass the `--assign` flag.
[1]: '>' was used instead of the more usual ':' because WMF wikis have
many existing usernames containing colons.
Bug: T9240
Bug: T20209
Bug: T111605
Change-Id: I5401941c06102e8faa813910519d55482dff36cb
Depends-On: Ieae5d24f9098c1977447c50a8d4e2cab58a24d9f
