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
* Refactored getUserPermissionsErrors "expensive" checks flag to be
a bit more general.
bug: T51419
Change-Id: Ic1882aa2957eed2b978761b5fc34ea9bdd8981b5
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
When a page transcludes itself, such as <noinclude>foo
{{:{{FULLPAGENAME}}}}</noinclude><includeonly>bar</includeonly>, use the
preview content in its own transclusions. This code was basically ripped
straight from Extension:TemplateSandbox.
Bug: T85408
Bug: T7278
Change-Id: I1aa091a395a4f7b7b744e09e0bed59bc2e1176d0
Follows-up b3830611c4.
Unlike getEditToolbar(), which only runs if the user preference
is enabled, the loading of mediawiki.action.edit is unconditional.
As mediawiki.toolbar has already been separated from mediawiki.action.edit,
it's easy to load it conditionally instead of via a dependency
(mediawiki.action.edit doesn't depend on it for anything else).
Also:
* Remove odd 'false' values passed to User::getOption(). These
options are part of MediaWiki core and always exist. The default
value 'false' was ignored.
* Remove redundant closure. The domready callback already provides
a closure and 'mw' is not used here (similar to jquery.mw-jump).
Change-Id: Ib2f4633b328cf8090df43b8d286cfcd77f95c5ea
After talking with the folks in #mediawiki-core, I decided that I can
put up with it, under protest, on the basis that it's arguably
consistent with PSR-2.
Change-Id: I5f0c0f8f0172674797970d306efe6439ce1c2b67
