There really isn't a previous content model because the page didn't
exist beforehand, so say the page was created with a non-default
content model.
Bug: T128645
Change-Id: Ibe0b124e3f3ceaaf3775f82e2646b7639a146a42
I searched for /\$(\S+) = (.+?\(.*?\);)\n.*?\$\1\[/, ignored
everything involving isset(), unset() or array assigments, then
skimmed through the remaining results and changed things where they
made sense. These changes were not automated, so please review them.
Change-Id: Ib37b4c66fc57648470f151ad412210b3629c2538
Avoids validation error:
The for attribute of the label element must refer to a non-hidden form
control.
Change-Id: I9501fda9ca1dbff3db530f5d9e0c2504b94b0ff3
Most projects override this anyway, but for default installs, let's
be consistent with other warning messages so it's clearer what is
going on.
Bug: T127403
Change-Id: I22c51a46a249247abccda709d74356e8e31a19a8
With this, if a gadget put a hidden input named "wpExtraQueryRedirect",
can guide MediaWiki to keep that extra query parameter even after the
save of the page.
Bug: T124986
Change-Id: Ie45d6d80e83298e4c349f1e2dedd4eaa66b7697a
Change tags to apply to an edit can now be passed directly to the
WikiPage::doEditContent function. They are then passed to the
RecentChange::notifyNew/Edit functions where tagging is made
after the recent change is saved. This ensures that other callers
of doEditContent will not run into the same issue as T100248.
ApiRollback is fixed in this way.
In addition, we'll have to pass tags in this way for core tagging
of edits (I2e48bd458fc8d7c289f04dc276f9287516e0b987), and this makes
it possible to merge the arrays of tags and call ChangeTags::addTags
only once.
Change-Id: I829960c7a33b70464065839d7504d7529dfd0b72
Take from either the request parameter, calculated value, or the actual
revision ID of the fetched page content.
This will be used in more places, once we replace time-based conflict
detection with revision-based detection.
Bug: T58849
Change-Id: I29dcb4694cd9fee4622663b4d9787e975cb415ec
Disable editing and serialize using the default format if the revision
has a different content model from the current one.
Bug: T73163
Change-Id: If28de7a3612d414a4366e3d493598244c0754b90
This change only improves documentation, it does not touch code.
For reference:
* CoreParserFunctions::displaytitle generates HTML, with &, < and so on
property escaped. OutputPage::setPageTitle() treats the input as wikitext,
which works for both plain text and HTML.
* Wikibase calls ParserOutput::setDisplayTitle() with HTML including <span>
structures.
In the API action=query&prop=pageprops returns HTML. There doesn't seem to
be a good place to document that fact, though.
Change-Id: I043b26b82f066abe2830a81d3bc073543b3748d8
* All DeferrableUpdates will be deferred as normal.
In CLI mode this is just post-commit and would have
happened before the doUpdates() call anyway. For web
requests this will be at request-end (post-send on HHVM).
Note that deferral was already the default for EditPage.
* Previously, it was easy to accidently not set EDIT_DEFER_UPDATES.
Deferred updates are supposed to be deferrable by definition,
and there is no longer the problem of them piling up in CLI in
recent versions. Not deferring mostly just forfeits performance.
* Also, it is not really the responsibility of WikiPage to be
running DeferrableUpdate instances itself.
Change-Id: I2bc47b82635e0a24b1df5d502ba66f6de737697e
We have this nice class for unit testing cookie-setting, but the
cookie-setting method ignores all the parameters! Fix that. Also provide
accessors to check the entire set of cookie data, and the set cookies as
a whole.
While this does change the semantics of FauxRequest::getcookie() in that
the name now needs to be prefixed, no extension in Gerrit uses this
method so we should be fine.
Also clean up the case of the setCookie and getCookie methods while
we're at it. Since PHP method names are case-insensitive, this doesn't
even break compatibility with extensions.
Change-Id: Ib44a074bf9796bc0b470d557e39465792f399d30
- Removed space after cast
- Removed spaces in array index
- Removed double spaces
- Added spaces around string concat
- Fixed mixed tabs and spaces at begin of line
Change-Id: I38e849723f055d2d4c05cba72f5c245a28e8d5da
These placeholders are already in use by the edit form, but were not
available to extensions. This gives us equal oppertunity to adapt the
contents surrounding the source textbox as we have in the editform.
I'm reusing the same placeholders. Most extensions fill these
placeholders through the showEditForm:initial hook however, so it
should not cause too many unexpected changes, since the readonly page
uses showReadOnlyForm:initial instead. I left out those that were very
specific to the editpage (afterEditTools etc).
This will be useful for Bug T110050.
Change-Id: Ia03265a907212ee7bac1b839dcdd4d2f24c79bbe
This avoids the use of $wgUser inside of WikiPage::doEditContent.
It does not avoid the use of $wgUser in general, because EditPage does
not know about context, but it will make the indirect use visible and a
rewrite of EditPage can address the issue better.
Change-Id: Ifbcf52f2f076dc5c177bea22f90eb3b9fb8e3224
Most wikis only use user signatures on pages set aside from discussion,
(Talk namespaces and sometimes project/main namespaces depending on
the wiki), so having the button available everywhere is confusing.
The few wikis that need the button (especially non-content,
internal/corporate/planning wikis), can add relevant namespaces to the
$wgExtraSignatureNamespaces array in LocalSettings.
This would make it possible to solve bugs like T59727 or T53154.
Since this is a change to default behavior, a release note is added.
Bug: T7645
Change-Id: I7ccf1093b888c7b33721234349ca0ac054c3cd3f
* This avoids hitting a long tail of logging table queries that
cannot easily use the buffer pool all the time.
Change-Id: Id2ad6b9699f1a8c579ebb1c3c0319183772af1bd
Special:ChangeContentModel allows for users with the 'editcontentmodel'
right to change the content model of a page.
Visiting Special:ChangeContentModel will contain an input field for a
page title. The user will then be sent to
Special:ChangeContentModel?pagetitle=<input> where the page title is
read only, with a content model selector and optional reason field.
The special page only allows converting between content models that
extend TextContent for simplicity. Advanced conversions should be done
via the API.
All content model changes via the special page or API generate a null
revision in the page history and a log entry at
Special:Log/contentmodel. The log entry has a revert link for
convenience (like the move log).
Bug: T72592
Co-Authored-By: Lewis Cawte <lewis@lewiscawte.me>
Change-Id: I296a67c09fcbc880c8c3a648eb5086580725ea46
Reject any edits that attempt to change the content model of a page if
$wgContentHandlerUseDB is false.
Change-Id: Ic2e0ed8f74c3a54864793a457a452f72fe637f73
Users on enwiki's VPT are reporting a spike in the frequency of rejected edits
due to loss of session data. It is difficult to corroborate these reports when
we don't have any instrumentation for them in the code, and thus no visibility
into how frequently they are occurring in the wild.
Bug: T102199
Change-Id: I0c99f292002209cf2bf4376f97b8c70a6b1ec021
This adds supportsDirectApiEditing and
supportsDirectEditing methods to ContentHandler. Both
return false by default for the ContentHandler base
class, and true for TextContentHandler and it's
derivatives. (everything in core)
Extension content types that directly extend
AbstractContent / ContentHandler, often / generally don't
support direct editing. EntityContent in Wikibase
and Flow boards are the two such content types currently
in gerrit-hosted extensions.
The use and direct settings of the allowNonTextContent
member variable is replaced by enableApiEditOverride and
a setter for that. The only place allowNonTextContent is
used in all of Wikimedia-hosted git repos is core itself
(EditPage and ApiEditPage), so should be safe to make
this change.
With this change, Wikibase can remove its ApiCheckCanExecute
hook handler that disallows editing there, and MobileFrontend
could check if direct editing is allowed before enabling it's
editing features, instead of Wikibase having to add
MobileFrontend hook handlers to disable the features.
Bug: T96382
Change-Id: I276cd6ecedf38108f1f2be16b38e699e8c5d2d0c
You can add tags at the same time as performing action=edit, as long as you
have the "applychangetags" right. Also, you can add or remove tags after
the fact from revisions and log entries using the API action=tags.
No UI is provided for either of these changes. The target audience is user
scripts, gadgets and similar tools.
Includes a new log parameter format type: "list", for a comma-separated
list of values.
Logging of change tag events is limited to those that do not accompany an
edit (i.e. those done after the fact), and is hidden from Special:Log by
default, similar to the patrol log.
Bug: T20670
Change-Id: I37275e0f73fa3127f55da0c320b892551b61ee80
Someone could theoretically try to hide malicious code in their user
common.js and then trick an admin into previewing it by asking for help.
Bug: T85855
Change-Id: I5a7a75306695859df5d848f6105b81bea0098f0a
The patch did not improve performance. I'd like to think that the increased
control over when inline scripts are executed makes the patch worthwhile
regardless, but that is post hoc justification and possibly a bit of personal
ego. Krinkle agrees that we may use some of the ideas in this patch in the
future but he thinks we're better off not heading down this path before we
have a better sense of where we're going, and I trust his judgment.
This reverts commit e86e5f8460.
Change-Id: I151f74a41dd664b5a0aa5cfd99fcc95e2686a1e6
Set the new global JavaScript variable 'wgEditMessage' with the name of the message.
Document this global JavaScript variable in
https://www.mediawiki.org/wiki/Manual:Interface/JavaScript#mw.config
after merge.
Bug: T88117
Change-Id: Ida5c1d470908cefd16925bd5455758d25db02113
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
The current ordering of scripts and stylesheets in <head> causes all major
browsers to serialize and defer requests that could be performed in parallel.
The problem is that external stylesheets are loaded before inline scripts. As
Steven Souders explains, "all major browsers preserve the order of CSS and
JavaScript. The stylesheet has to be fully downloaded, parsed, and applied
before the inline script is executed. And the inline script must be executed
before the remaining resources can be downloaded. Therefore, resources that
follow a stylesheet and inline script are blocked from downloading."[1]
In other words: the browser could start loading body images, but it refuses to
do that until it has executed inline scripts in head. And it refuses to execute
those scripts until the external CSS is downloaded, parsed and applied. You can
see the effect of this in this image, showing the request waterfall for
[[en:Gothic Alphabet]]: [2]. Notice how no images were requested before the
browser had finished processing the three load.php requests at the top.
To fix this, we want to move the inline scripts above the external CSS. This is
a little bit tricky, because the inline scripts depend on mw.loader, which is
loaded via an external script. If we move the external script so that it too is
above the external stylesheet, we force the browser to serialize requests,
because the browser will not retrieve the external CSS until it has retrieved
and executed the external JS code. So what we want is to move the inline
scripts above the external stylesheet, but keep the external script (which the
inline scripts depend on) below the external stylesheet.
We can do this by wrapping the inline script code in a closure (which binds
'mw') and enqueuing the closure in a global array which will be processed by
the startup module at just the right time.
Net result: external CSS and JS is retrieved in parallel, retrieval of images
(and other external assets) is unblocked, but the order in which code is
evaluated remains the same.
[1]: <http://www.stevesouders.com/blog/2009/05/06/positioning-inline-scripts/>
[2]: <http://people.wikimedia.org/~ori/enwiki-waterfall.png> (excerpted from
<http://www.webpagetest.org/result/150316_0C_7MB/1/details/>.
Change-Id: I98d383a6299ffbd10210431544a505338ca8643f
So that we can determine whether a save attempt succeeded or failed,
to log saveSuccess and saveFailure events from the server to Schema:Edit
on meta.
Bug: T88027
Change-Id: Ib861262603872e67600d1aab9bde3b58a8dd1738
The content container is needed for CSS selectors based on the direction
of the page content language.
Bug: T85531
Change-Id: I78f6b82972621da8dddc24f0d6d6b2293f7d8876
