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
* This also changes previews to render section edit tokens but
remove them on output, avoiding cache fragmentation.
* Also shortened the resulting getStashKey() value.
Change-Id: Ic8fa87669106b960c76912b864788b781f6ee2e6
ConfirmEdit was tripling the amount of time it took to save a typical
page via the API, since it was assuming that the APIEditBeforeSave hook
was giving unmerged wikitext, requiring a full parse of the content
before and after the edit in order to check the addurl trigger.
Apparently nobody bothered to update it after Ia59fb6bb.
APIEditBeforeSave is unusable anyway, because it is given the serialized
content, without any information about the content model. It really
needs the Content object in order to do it properly. So instead, adapt
EditFilterMergedContent for the purpose. Incidentally, that avoids the
inelegant defined('MW_API') check in ConfirmEdit's
EditFilterMergedContent handler, since both API and normal edits are
handled by EditFilterMergedContent in the same way.
Unfortunately the interpretation of the 'value' member in the Status
object passed to EditFilterMergedContent is not extensible, being an
integer instead of an associative array. So we add a custom member in
order to get the result array back down the stack.
Another obstacle to this design was the lack of an EditPage object
passed to EditFilterMergedContent. ConfirmEdit was previously directly
calling EditPage::showEditForm() with a $formCallback which outputs the
necessary HTML. Instead, I hacked up runPostMergeFilters() a bit, to
allow the hook to request that the edit page be shown again even if
hookError is not set. Then a new EditPage::showEditForm:fields hook does
the necessary HTML output, instead of $formCallback.
Marked $formCallback as deprecated, since I think it is now unused.
Change-Id: I4b4270dd868a643512d4717927858b6ef0556d8a
* This lets edits be prepared while users enter edit summaries.
* The edit form will now make use of this API, controlled by
$wgAjaxEditStash.
Change-Id: I4f4057bc0d1d4a66a8f7cfb7cdc26d443a8eb0c4
Add the user right 'editcontentmodel', which is required to change the
content model while editing a Page.
Bug: 70901
Change-Id: I54f59539f1045092ec0de76c31cb47ca19c56874
When editing a page in the mediawiki namespace the hint to
translatewiki.net is always shown, but it is unneeded, when the message
is not a default message and maybe used for warnings in abusefilter or
is a gadget description.
Change-Id: I7dbf030311e30ce852459e363c91e988ca15d86d
Follows-up 285c52039b.
Get rid of mediawiki.mediawiki.action.toolbar. Not keeping a
backwards-compat alias since this module is not supposed to be used
publicly in its current form.
Change-Id: I403216c6916e1f4d29216a55c3fe6c92eb68400b
Stop littering MediaWiki with globals, provide a common
api for generating them similar to how we do text input
attributes before things get out of control.
Adds
* submitButton
* linkButton
Change-Id: I61bb3c358f755ed9f2153d94b744c1a9da02c456
Useful in order to be sure that only the default format is saved in the database (allow to implement optional formats useful for APIs but not used in the storage)
Change-Id: Ia703319aefc8d56c377cd7766dc5985c5c3c27c1
Also, try out a way to have per-module LESS variables defined in PHP.
This might come in handy in the future… Maybe for skin theme support?
(I recommend reviewing the file changes in the order below. :D)
includes/resourceloader/ResourceLoaderFileModule.php
* Pass the context (ResourceLoaderContext) deeper down via
readStyleFiles() and readStyleFile(). We need it to compile the
.less files for the right language.
* Extract LESS compiler creation to getLessCompiler().
* Allow passing a LESS compiler instance to compileLessFile(), rather
than getting one after the method is called.
All of the changes are backwards-compatible.
includes/resourceloader/ResourceLoaderEditToolbarModule.php
* New module to support getting the language data and passing it to
LESS variables.
It might be a good idea to factor out a reusable class for a LESS
module with additional variables, but that would require more
attention to design than I gave it.
resources/src/mediawiki.action/mediawiki.action.edit.toolbar/mediawiki.action.edit.toolbar.less
* Glue code to use the language data defined by the module above and
put it in final CSS.
includes/EditPage.php
* Do not hardcode image URLs in output HTML, as they are provided in
CSS now. This gets rid of some usage of globals.
In fact, we should be able to finally move the inline JavaScript
calls out of getEditToolbar(), but I'm already introducing too many
changes for one patch. That can be done later.
languages/Language.php
* Add getImageFiles() to complement existing getImageFile() method.
Misleadingly named, it returns paths for images for the toolbar
only (and no other ones at all).
skins/common/ → resources/src/mediawiki.action/mediawiki.action.edit.toolbar/
* Moved all of the button images to new location.
Also, boring cleanup that was harder before because we treated the
paths as public API:
* Placed default ones in en/ subdirectory.
* Renamed cyrl/ to ru/.
* Renamed ksh/button_S_italic.png → ksh/button_italic.png.
languages/messages/
* Adjusting paths and filenames for the changes above.
resources/src/mediawiki.action/mediawiki.action.edit.css
resources/src/mediawiki.action/mediawiki.action.edit.js
* Added styles and updated the script to make it possible to have
non-<img> elements as toolbar buttons.
* Consolidated styles that were already required, but defined
somewhere else:
* `cursor: pointer;` (from shared.css)
* `vertical-align: middle;` (from commonElements.css)
Bug: 69277
Change-Id: I39d8ed4258c7da0fe4fe4c665cdb26c86420769c
