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
Classical toolbar no longer appears in Page namespace on Wikisources.
This reverts commit 7263ef1e00.
Bug: 69447
Bug: 29908
Change-Id: Ifafe41f7bc91183e0db4c10d8340a8b620b380bc
The message has been tweaked to be closer to the version used for several
years with success on the English Wikipedia and on some other wikis. In
particular, the calls-to-action now have individual links rather than
expecting users to be able to magically find them themselves, and a user-
facing justification for why they should log in.
Change-Id: I687e47c23618e536a8f3010d7a6f168feb7bfa72
Change Ia9baaf0b changed the visibility of member variables (many of which are not
otherwise exposed, e.g. by a method) and by that introduced a major API change
breaking extensions.
This patch explicitly marks affected variables as public again, keeping the intent
of the original patch of making phpcs-strict pass on includes/ directory.
Bug: 67522
Bug: 67984
Change-Id: I498512b2a1e615365bb477c1fd210aaa3241ca03
These functions actually does not return anything, so the @return is
wrong here. '@return void' is ignored.
Change-Id: I11495ee05b943c16c1c4715d617c8b50de22276c
This provides better mobile experiences on various pages
and a more consistent UI across both mobile and desktop.
It does this in two ways.
1) Forces HTMLForms to not use table based layouts so as
not to interfere with responsive nature of mediawiki ui elements
2) Applies MediaWiki.UI classes to most pages
If a page is created via Xml or Html classes it will use mediawiki ui
Where possible I've added classes unconditionally, but for cases of buttons
this is behind the $wgUseMediaWikiUIEverywhere global since button styling is
enabled on pages by default and for checkboxes since it is changes HTML markup.
3) Adds all MediaWiki.UI styles to pages which can use it
When enabled:
* Apply these styles to all pages which use HTMLForms
* Apply to EditPage
* Apply to anything that uses certain elements outputted by the
Xml or HTML helper classes
* Apply to History page
* Apply to protection page
* Apply to move page
* Apply to deletion page
Currently kept behind a global to allow us time to finetune
existing elements. After further testing we will look to kill the
globals and make mediawiki.ui the default
See: I430c0fbb79d2a33bb828b2427bda0ee01115d73f
Change-Id: I47db5eab4569514d039261d11b6dedb0eeae17b5
This change enables the direct creation of empty pages without needing
to use a work-around (such as "{{subst:ns:0}}"). A warning is added as
the message "blankarticle" to request confirmation that the empty page
was meant to be blank. A automatic edit summary has been added when
creating a blank page. The message is: "autosumm-newblank."
The API has been updated to permit the creation of empty pages, when
"text" is null, but not non-existant.
Unit tests have also been added to test these features.
Bug: 57238
Bug: 65206
Change-Id: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I783e4dbfe5f6f98b32b9a03ccf6439e13e132bcc
- use tab as indent instead of spaces
- Added space after closures "function"
- Added spaces around string_concat
- Added newline inside empty blocks
- Removed four spaces after comma
Change-Id: I4425b0c6a69b36f40acfea6511b8950cf09ce2b2
The current check will basically never pass, since it's looking for the
submitted section title to match the section title inserted into the
'newsectionsummary' message.
So let's factor out the code for applying 'newsectionsummary' and use
that for the conflict check. We can't just update $this->summary
earlier, since later checks depend on looking at the submitted summary
rather than the mangled one.
Bug: 67634
Change-Id: I72890c0641f991696ec98b50a6a42b2be7f46f63
