We can skip all the up and down message passing by persisting the
parameter placeholders for each template dialog. If the parameter
list is expanded then the placeholder is deleted, on being created
again it will still have state.
To test: create a transclusion with two templates, each having many
parameters. "Add more information" to add parameters, expand the
list by clicking "Show <num> more fields", then delete the parameter
placeholder using the trash cans. Try different permutations to fool
the cache or collide with another template.
This is preparation for other template sidebar dialog work.
Bug: T284636
Change-Id: I23bdd38b173114c2a9afafc7465c4beb92d25869
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
Begin to extract the wiring between a sidebar and the content pane of
the template dialog booklet layout. Eventually, this helper class
will present a high-level interface like "addPart(id)" and will take
care of creating the outline item, content page, and connecting
events.
Start very simple, take over the "focus" method.
Bug: T284632
Change-Id: I7bc73cc4386b99d95941fc6ed88ab5bd998de014
This reflects better what the method actually does. This patch
is a direct follow-up for the renames started in Ib029fd4.
Change-Id: Ie3e87139a5c2f5ac196e0fcc02fb897fadc99177
The names of the messages keys are very confusing. The order was set
wrong during refactoring in Ib029fd48b393d2ab7d7cff6c842789e22989e944.
We should rename the keys in a follow up in sync with translatewiki.
Bug: T284649
Change-Id: I43794d80b7df7d00441cb583ca53bcab03999e65
This reflects better what the widget actually does.
However, the config option `value` as well as the method
`getValue` are not renamed. These intentionally mirror a OOUI
convention.
Change-Id: I26e733b760501e57b3314d5da2d65bfdd4b38346
This dramatically simplifies the "mode" flag in
MWTransclusionDialog. The main reason to touch this code is:
The flag appears like it will be "single" when the dialog
contains a single template, and "multiple" when there are
multiple templates. But this is not true.
What the flag really does is show/hide the sidebar. The sidebar
is needed to be able to create multi-part templates. But a
dialog that already contains multiple templates can be set to
"single" mode (i.e. the user can collapse the sidebar), and
vice versa.
This patch focuses on private details inside of this class, but
keeps the terminology of a "mode" in some places. E.g. the
messages are not renamed to not cause unnecessary trouble for
translators.
Change-Id: Ib029fd48b393d2ab7d7cff6c842789e22989e944
Previously, if the checkboxes were shown on multiple lines (e.g. due
to a FlaggedRevs checkbox), there would be uneven margin at the
bottom. There was a special case to fix this only for the watchlist
expiry not-checkbox.
Change-Id: I006049cf23e6d42519bfa15b7ec30ea1bc5d08ac
This class represents a raw wikitext snippet. There is also no
base class that would require us to follow a generic
getValue/setValue naming scheme.
Change-Id: I0891a2f6c0ae0121429a47c39221e99b9653e8e3
There are 2 methods with the same name, but they are very
different. This makes it much easier to understand the
difference, I hope.
Change-Id: Ie1f049b2b14e1fe23f078e281ee797da29dfe3db
This does have a few advantages:
* Less code is executed and less memory consumed when these
elements are not needed.
* Code that belongs together is together.
* No local class properties are created when they are not
needed in the code below.
This patch is kind of a proof of concept. It touches only a few
classes we currently actively work with. If this change is fine
we can change some of the other classes the same way.
Change-Id: I9f548765034f1f69799fff41aeb6c147ff28b82d
The variable `html` had the value of undefined and was treated as a string.
This would then be displayed on the editing surface.
Change-Id: I4682ea121aa37f06cac41dde618af847586ae01e
The class .ve-init-mw-target-surface is used on the same element
as .ve-ui-surface. This element contains surface overlays
.ve-ui-overlay, which can contain other .ve-ui-surface elements
(inside inspectors), which would then erroneously have the target
surface styles applied.
Bug: T284312
Change-Id: I8d20a830dc48f6a098b0f9e9a7c7c1656de0fe56
Just reading the method signature gives the exact same
information in these cases. In other words, this code is
able to explain itself.
Change-Id: I04d031f2b24c3b0d21fede2c19c64b54d30b5b0c
The idea is to possibly rename some of these classes, based on
these descriptions. But this should be done in later, separate
patches.
Change-Id: I7f9e5b2382711b434d6dd618489fa3ed8b7a46b4
The main motivation for this patch is actually the comment. The
so called "spec" contains all parameters that are present in a
template, no matter if they are present in the TemplateData
documentation or not. This is critical here.
Change-Id: I5e1c79e3859a27562a9dea1d450cec196aa572ed
Depends on whether this is a new or existing template transclusion.
Split from Ib9b76cac7cd57245e8db2ef10879069a86a6269e
Bug: T276568
Change-Id: I4d22e32fef067b640e9a9389deffaace736c3405
When the existing search results don't contain an exact match
(see previous patch), perform an additional search for the
title. This uses OpenSearch. This is recommended in multiple
places and also used in the quick search field at the top of
MediaWiki.
Again, I came to the conclusion that an isolated unit test
would be complicated and not test much anyway. Better test
on-wiki.
Bug: T274903
Change-Id: Ib575248e089ff66814400202d224deff6369c772
This code detects a few edge-cases:
1. When some search results are exact matches, make sure they
are always at the very top.
2. When the prefixsearch API is used, e.g. as a fallback,
redirects show up as a separate metadata structure outside of
the pages array. Consider these and stop if there is already
an exact match.
3. CirrusSearch returns redirects as part of the pages array.
When there is an exact match, make these redirects separate
options and add them to the top.
All of this is case-insensitive, on purpose. In case two
templates with different capitalization exist, we rely on
the backend to return both. The code introduced here is fine
with this.
Notes:
* This doesn't guarantee an exact match is always there. This
requires an additional HTTP request and is done in the next
patch.
* I tried to write unit tests for this, but gave up. The setup
is complicated. An isolated unit test would not test much
anyway. Better test this on-wiki.
Bug: T274903
Change-Id: I64e1b5633e7b878a4d0d23d66229ca87e69d0045
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
* Create getSurfaceClasses method.
* Pass surfaceClasses to target widgets.
This ensures that the 'content' class is passed to mobile
target widgets, and the 'mw-body-content' class is added
in a less hacky way.
Change-Id: Ibce6d1a1d0fda63cca354761f1b91f808858e95b
Template names sometimes show up twice when searching for a
template in the "Add a template" dialog.
This is a bit hard to test. The code responsible for this
is not in a single place. The feature is in the upstream
TitleWidget class. It's not broken. It makes sense to
provide e.g. "foo" and "Foo" as two separate options when
the user typed "foo", but the page is named "Foo". Both are
valid, and the feature allows the user to pick either.
But the VE widget does it's own normalization. Both entries
are normalized to "Foo". Both do the same. The additional
one is pointless.
You can try this on the actual enwiki: Open VE, insert a
template, search for "Template:nHLE".
Change-Id: I65e706c4d131a2f8c605d7979a02ea56f831bf03
The "redirects" part in a prefixsearch query is always an
array, no matter if formatversion 1 or 2 is used.
The "pages" part is an object with formatversion 1, and an
array with formatversion 2.
As of now this always uses formatversion 1. This is
hard-coded in the upstream TitleWidget class.
Change-Id: I8cde8e104f8a288015da745db41016f6639b453b
VisualEditor recreates the mw-body-content element. The element
with mw-parser-output already exists as a child. All skins now
consistently follow this pattern.
To limit the impact to the editor, we use ArticleTarget and add the class
to the surface, which corresponds to the mw-body-content element of a skin.
This avoids unrelated regressions in experiences such as DiscussionTools.
Bug: T283014
Change-Id: I4833d1ca9fda4fc0bd433760e47fe7010f00db05
Returns true if there is no meaningful user input yet.
Will be used in the next patch.
Bug: T272355
Change-Id: I4f88ce31662bbc46755f78d574c46b907581d438
Rather than invent our own size, we'll reuse the "larger" format and
tweak the dialog height to 90%.
Bug: T273971
Change-Id: Ibef85c1912267b14d83396b089b81934751a8328
Discussed in T274903#7077957. Note this might not be the
"perfect" solution. We are still experimenting, and this is
all hidden behind a feature flag. This is the change with the
most minimal impact. Actively trimming the input is another
solution, but with a bigger impact we might want to discuss
first.
Bug: T274903
Change-Id: I2ed06c04bb96c7b61bd7e87ad001e639ea6d06a2
We have two cases now that we want to cover here:
- Either we're inserting a new template and start a "fresh"
transclusion, then we want to use "search" in the headlines
- Or we're adding a new template to an exsisting
transclusion, then we want to use "add" in the headlines
Bug: T277028
Change-Id: I9fa294cf732598d58f848c75b353d2e1742eb4e8
This allows using the config variable independendly from the cirrus search extension.
This way it can be used for all subtickets of T271802.
Bug: T277028
Change-Id: I1b3bdda5fa6fbfe5c531c3b51c2c8e2a28ed1faf
Renames "Add a template" to "Template Search" in most cases and
provides inline help for the workflow.
Bug: T277028
Change-Id: I3fee87cb89b5044e785596e71ef3f1a18f2694ce
Ib957eac2d checked to see if actionTools.notices existed before
destroying it, but assumed it always existed if editNotices was
set. This patch adds a check before attempting to show editNotices.
The error occurs because Ibc7fa48df unregisters the 'notices' tool
(along with many others) for AddLinkArticleTarget.js in
GrowthExperiments. I92a3162ef in GrowthExperiments will empty out
any notices to work around this problem.
Bug: T281960
Change-Id: Idacd365efa82ecd5c0074ead035eda0cb9444b1f
We're about to replace this jQuery element by a OOUI container, and
can take an initial step by reducing its lexical scope.
Change-Id: I4123c8d22c01040fc2f61180304254498b21f5fd
The name "description" conflicts with the TemplateData field name,
which is only one of several documentation fields.
Change-Id: I0942701204fe8499e8890740585b9a02c1d14c63
The internal name "more" conflicts with new collapsible buttons.
TODO: looks like TemplatePage has an analogous field?
Change-Id: I10b24758316a6cc3fbd236c77daffa014fcdafc6
When $wgVisualEditorTransclusionDialogInlineDescriptions is set to
true, the template dialog will use a larger format.
Bug: T273971
Change-Id: Iad3c3f4d65125c83e35414ce15f793f6a1b192ef
This patch is mostly about the arrow syntax.
Some places can not be updated because the arrow syntax also
changes the meaning of `this.…`, but some code relies on that.
Change-Id: Ida3ab0e0950a428fbd1a85f281013778ee879df4
