* Created a new Resource Loader module
* Created an entry for the RL module in the Resources.php
* Added messages to languages/MessagesEn.php and languages/MessagesQqq.php
* Called the new RL module from the EditPage.php
* Added required entries in the messages.inc, DefaultSettings.php
Corresponding change in the Vector extension: I164f17255bc927
Bug: 46514
Change-Id: I7bdbd09f4083ccb316156307400ccfacdfec79e1
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
* Sets short-lived cookie in EditPage
* Adds JS module, 'mediawiki.action.view.postEdit', to all views to
convert cookie to wgPostEdit. This avoids caching the variable in the
HTML.
* Based in part on PostEdit extension
Change-Id: Ie89507f8e98c365df9d93a7633223103b9025790
Since Ic05e5898 spaces are also trimmed on preview/show changes, which
is bad, because the autosummary "/* Header */ " gets trimmed and the
user text is direct written behind the slash. That is confusing and was
not so, before this change.
Force the trim on summary preview to have the right preview, because the
spaces are trimmed on save.
Change-Id: I0058ce31197f3ea8ffc5520f3f0f9e1bf6105066
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
When trying to edit a page that does not support sections (like a JS or CSS page)
with section=new or so, show an informative error page instead of dying with
a fatal error.
Change-Id: I3d2901b715c10b52fab4fdc6b5e9ab5d887610bd
Makes life easier for static analysis, since they don't need to
handle if the end of a function where a wfProfileOut was not called
was reachable or not.
It is recommended to review this change ignoring whitespaces
(specially for includes/parser/Tidy.php)
Also documented the rationale for the elseif chain in UploadBase::detectVirus()
Change-Id: Ic4f65937fa9e6f926d8fcfd670e3b0e99e06eefc
This is part a the solution to bug 42064: it modifies the EditFilterMergedContent hook
to allow it to be triggered by code outside the EditPage. This is useful when extensions
such as Wikibase implement their own editing mechanism for non-textual content.
Allowing EditFilterMergedContent to be used on non-textual content ensures that
any filters will also be applied to that content.
Note that EditFilterMergedContent was introduced in 1.21 which hasn't been released yet,
so modifying the hooks definition should not be a problem. The only extension that appears
to use the EditFilterMergedContent hook is Translate. I'll supply a patch.
To completely fix bug 42064, I will soon submit two changes to two extensions:
* In the Wikibase extension, trigger the EditFilterMergedContent when changing data
entities.
* In AbuseFilter, make use of the EditFilterMergedContent hook, so filters will also be
applied to non-textual content.
The the dicsussion on bugzilla for the rationale of this architecture.
Change-Id: I99a19c93e99860a91d7f898b0a3fbb72b69baab8
Apply the same robot behavior of the edit & history pages (noindex,nofollow), on view source pages
(case of ?action=edit when having no edit permissios).
Change-Id: Ifc162332798a3dea93db4096d26e928545fbf4b6
* Move edit notice rendering to Title class
* Use new getEditNotices method in EditPage
This opens the door for alternative editors (such as the VisualEditor) to use the same notice systems already in use.
Change-Id: Ib0e40714f5433f4d75c54a3c3d60b1590fded7f1
Adds two new hooks:
* AlternateEditPreview allows an extension to override the standard
page preview display.
* EditPage::showStandardInputs:options allows an extension to add
additional HTML to the end of the editOptions area of the edit form.
Change-Id: Ic5d35c8e9ff71282b5ebccc87c64894a385e5836
Use the new Content::convert function to convert preloaded content
if the page being edited uses a different content model. This allows
e.g. a page like User:Foo/bar to be preloaded when creating
User:Foo/common.css. This currently fails, because it is not possible
to use wikitext to pre-fill a CSS page.
Change-Id: I70656b41bd203e5722528e889a242fa54cbfbf62
This reverts the temporary fix in I4c2055be and instead fixes the
resolution of merge conflicts using Contenthandler::merge3.
Change-Id: I0b1db6d76c0678d0ce795720e513e16e28e907d4
Reverts I2c600915. Regular UI edits seem to go through fine, but things go
horribly wrong for reasons unknown to me in for example LiquidThreads.
That's of course not acceptable, so reverting. Also see bug 41497.
Change-Id: Id95e279c0ec0fbcc162983a12434282f55e8489e
Some details:
* Using context as much as possible.
* Changed mTitle/mArticle to getTitle()/getArticle().
* Tweaked some comments.
* Broke some long lines.
Change-Id: I2c600915d8a4af98215de9bf9d2d60abdc675fab
Until the ContentHandler merge, when editing an old revision the "Show
changes" button would show the diff between the current version and the
text in the edit field. It appears that the ContentHandler merge somehow
unfixed bug 34849.
The same fix that was applied for that bug in r112819 translated into
ContentHandler terms seems to fix the bug again here.
Change-Id: I1eee25c530ef87ff2ecd61f0fd5c01de94eccb98
Changes to EditPage.php apparently got lost during merge.
Wonder how that happened, there are no conflicts.
Change-Id: I5449d0331f5d60ed0296b69888e10272f47f9d42
