Depends lightly on a patch to WikiEditor, which will hook up the logging there
for the case where the switch is happening from WikiEditor to VisualEditor on
the same pageload.
Bug: T221191
Change-Id: Ibafec77b2eabd3b3b3767472b7b5a40e3312bf18
In general action=edit could be bound to a wikitext-specific
edit link, but in the case of redlinks we can use the
preferred editor instead.
Bug: T223793
Change-Id: Ib0851e9e2ce441ae93311153801e2c3de0a2063d
If a new namespace was added to $wgVisualEditorAvailableNamespaces,
but VE was loaded on a page with old cached HTML, the 'Edit' tab's
text would incorrectly be 'Edit source'.
If $wgVisualEditorTabMessages['edit'] or ...['create'] was changed
from non-null to null, but VE was loaded on a page with old cached
HTML, the tab would still use the old text.
Change-Id: I2d5c7b922ba480eb90fa0a6da7a1901f062c96df
Prior to 80bfbfc54b this worked by
accident, and with a number of bugs depending on your settings (see
T219457). It turns out that Wikipedia users have invented various
workflows that depended on this bug (mostly involving sandbox pages in
namespaces where VE is not enabled). Restore it as a supported
feature, and in a way that avoids the problems it previously caused.
Bug: T221892
Change-Id: I62714b6f2905efd1d1b34c7a13b9917cb6c609fc
Use an API 'parse' call with a sectionid to trigger
a full document expansion using replaceSectionAtRev.
Then send this off the RESTBase to convert to HTML
and statsh.
Ensure the etag is passed back to the API response.
Bug: T117716
Bug: T223023
Change-Id: I1b35b28e428a1f86d2e34d90ddbe73361ce14818
I think mostly the incompatible changes were made in commit
I5a7d73b20617cb3c6d6379084ac4bea23ec3bc74, but I didn't try
to track them down.
Also fix an issue where hrefs in section edit links generated
by this code were wrong.
Bug: T208102
Change-Id: Ibf6564bc0dcb7fcb420739a897b54346a01add02
If a page can't be edited in the requested mode (e.g. veaction=edit on
talk pages), the parameter will now do nothing (the editor won't
load), instead of trying to load the editor in another available mode.
Bug: T219457
Change-Id: I2cd78ea13ba13ff622f5e4b7db033f82dfa7875e
* Make inserting secondary tab work with Minerva's non-standard structure
of navigation menus
* Distinguish primary and secondary tabs with tiny icons, since Minerva
hides their text
* Hide section edit link dividers (unnecessary when we use icons)
Bug: T208102
Change-Id: Ieaec60165617e3b423ec58857d6f0a0406e22b1d
I suppose technically you don't need it if you're already on an
?action=edit page, since that will cause the editor to load as well.
At a glance nothing seems to break if it is missing (other than the
fact that there is no way to launch the editor, obviously).
Bug: T179427
Change-Id: I3c221ded302702b881857930da5dc41630680c02
ve.track tries to guess the platform, but it needs a loaded Target to do so,
and init happens before that.
Also, log a warning when this happens, in case it comes up again.
Bug: T203618
Change-Id: I35fa58a42cd247e01f3717c9ab3a10d8ea93a484
Refactoring in 92c4e23 didn't account for the case where there are multiple
tabs and source mode isn't NWE, which caused the "edit source" tab to just be
a page- navigation that always discarded changes. onEditTabClick handles this
case fine, so just always bind the handler.
Bug: T199655
Change-Id: I3dca87a7a3b0ea88ef0008be89cd1f6007167916
If the wiki runs on a host that contains a port number, section edit
links would always reload the page, and the "Add section" tab would
not work.
As it happens, my local testing wiki runs on localhost:3080.
It is an unfortunate naming mishap:
* mw.Uri#host is equivalent to location.hostname
* mw.Uri#getHostPort is equivalent to location.host
In this case, we have to compare the port too, otherwise a setup (my
setup ;) ) where one starts up another wiki on localhost:3081 to test
cross-wiki features would fail.
Change-Id: Ib7de4ba3c3a84888f24186af03bd9dcced131051
What happens when an edit tab is clicked is spread across handlers in
DesktopArticleTarget and DesktopArticleTarget.init. Consolidating the logic
into the handler in DesktopArticleTarget.init makes it easier to understand.
It could be moved further into DesktopArticleTarget, but the init handler has
to exist to activate the target in the first place.
This patches a hole where clicking "edit source" while in visual mode would
sometimes not switch to source mode, because it didn't think it was changing
the current section.
Also, fix a typo in the documentation.
Bug: T198272
Change-Id: I12d958b6af1b9fa9aca68b498eb2a1a2d76b5a82
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
When the user is viewing the last stable revision of a page which has
newer unreviewed revisions, FlaggedRevs wants us to open the latest
(unreviewed) revision of the page for editing.
Use the JS config variable 'wgFlaggedRevsEditLatestRevision', provided
by FlaggedRevs since change I4c9804fe2c4924e28770807881379ddca4fd8b76.
Also add an extra comment about loading latest revisions in general.
Bug: T165283
Depends-On: I4c9804fe2c4924e28770807881379ddca4fd8b76
Change-Id: Ic47491e690153d0ad87ce64bfc9e7a28a06fc6e2
