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 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
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
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 would would be correct if it was in a method of ve.ui.MWBackTool,
but this is actually a different class ve.ui.MWBackCommand (they are
both in the same file), which doesn't have a 'toolbar' property.
This partially reverts commit 4984c5ffbb
"Avoid using mw.ArticleTarget methods on global ve.init.target in tools".
Bug: T279613
Change-Id: Ia5e80e34cc5021295639cf18b3c324d2821aecf5
Triggered by Ctrl+Shift+Space on PC.
On Mac, there is no trigger, we rely on the built-in OS shortcut.
Bug: T53045
Change-Id: I9630804c833d755910589022b0ca78208337d804
As far as I can tell, the code only uses the comment, nothing else.
Omitting the title probably won’t make the underlying database query any
cheaper, but it should at least save some network traffic.
Change-Id: Ideb66ce3a24fb4f42fe8fc22ba0e93d05724d8b6
Previous, reverted attempt: da9b6fffbd.
This attempt also includes 6037fefbe0,
and fixes minor conflicts with other changes.
* In normal images, parse relative 'href' attributes instead of
expanding them to absolute. This resolves Parsoid generating
|link= options for copy-pasted images (T193253).
Keep them in the underscore-form to avoid causing dirty diffs like
T237040 again. Unlike in the previous attempt, we don't need to be
super-careful about the 'resource' attribute, thanks to the Parsoid
changes in T108504.
* In gallery images stuff, prefix the 'resource' attribute with './',
same as normal images do. This causes no functional changes, but it
makes updating tests easier, and the consistency is probably good.
* Update test examples to also prefix 'resource' and relative 'href'
attributes with './', like the real Parsoid does.
Bug: T193253
Change-Id: I91131728a87c9406bf069d46d3c94c9a8905a003
The conversion to a DM doc and subsequent cleanup is a generally
useful step that should be available as its own method.
Change-Id: Ia53c0a641b231bb81c25c011624357acf4dc42a3
This was used when we used to pass API errors to showMessage, but
is now unused by the two remaining users (missing edit summary, and
"press ctrl+enter to submit").
Change-Id: I8a6b4db78d4e451cf3ec85fcdfd8293328aaaa3c
The names in the schema are roughly following what's
done in Schema:TemplateWizard. The information if
templates have TemplateData will be logged seperatly.
Bug: T259705
Change-Id: Iafa7256f675dbfd6a5a6de794061901780e3c55d
Before we can integrate our new media search functionality into VE,
we need to add instrumentation that can measure the effectiveness of
the current media search tools to provide a baseline for comparison.
Bug: T265101
Change-Id: I980d6ae10045b0a4e56694473006196c2132c930
This parameter name was deprecated and replaced in 1.31. See also
Ie5fe2097cda45968bb080643d3afcac0b2868a6c
Change-Id: Ie9d6c70d3dfe3954504d3d698c122dceede7603d
The first edit to a parameter will cause an event to be sent,
subsequent edits to the same parameter will not send an event.
Bug: T258920
Change-Id: Ibe663ce99a8fdf85a5add17186fb44fdbd4176bf
Record that a parameter was added, and whether it was known or
unknown--whether it's documented the TemplateData. Note that
`.isParameterKnown` returns true after an unknown parameter is added
to the template, so we need to set up the event early.
Bug: T258920
Change-Id: I5f8d8d06226474160a0a82c2e85a7fa4e22ba8cb
Reference images are moved to Cite and used by Citoid.
Bug: T170919
Bug: T171292
Depends-On: I02041246dda1b3d3ad1bcc0b014fa022e8259b62
Change-Id: Id97659ed1fa64a1223a8957fefaf2a149edd0e9c
The 'mwSignature' command replaces the selected content with your
signature. So basically, if you double-click this node, it gets
deleted and an identical one is inserted. This is useless.
I think I added this when this class was inheriting from
ve.ui.MWTransclusionContextItem, to override the command that would
open the transclusion dialog, but even then this should have instead
been `null`.
Change-Id: Id4492e36e9d89001df655e48b528d07eb608289e
These constructors only take a single argument, so the api config was
being ignored and the input would fall back to the default `new
mw.Api()`.
The order is changed so that the "api" config is merely a default,
and can be changed by whatever comes later.
The UserInputWidget currently doesn't accept an "api" config. This
will be fixed in Ifb1dd9d. But this is not a blocker. Merging this
patch here before the other won't have any consequence. It will just
continue to ignore the "api" config. ;-)
Change-Id: I15c35216c717576c6767927cac06ef72198fc95a
The input field becomes a title autocomplete, showing small preview
images and searching only the File namespace.
This is consistent with how TemplateWizard behaves when editing a
File parameter.
Bug: T260886
Change-Id: I7a114e279436ec1ff6f7b8ab66443138ab12637f
The MWParameterSearchWidget that shows a list of all available
template parameters displays the (human-readable) label and
description of each parameter (both given via <templatedata>), as
well as the parameter's internal name and aliases, if there are
any.
This turns out to be non-helpful in the majority of situations:
* When there is no <templatedata> yet, there are no labels.
Instead, the names are used as labels, which means they are
*all* identical and everything is shown twice.
* The same happens when manually adding an "unknown field". Simply
start typing, and you can add parameters with any name. What you
type is shown twice (actually 3 times, 1 time in the input
field, 2 times in the result widget).
* Many template parameters are already nice, human-readable. Even
if <templatedata> exists and specifies labels, these labels are
often identical to the names. There is no need to come up with
something else if the name is already good enough. (Exception:
Localizations, but these are rare.)
Furthermore, this is a *search* result widget. The pretty much
only reason the names and aliases are shown is because the user
can search for them, and needs to understand why a parameter was
found. This still works fine.
For comparison, when a parameter is required you will *never* see
it's name, because the parameter is always there, and never shows
up as a search result.
Change-Id: I6b1dca1c94b2c496930b5bfdfe1c6f76898faa2a
Items which are invalid titles will still get discarded if
the gallery is edited, but this is better than crashing.
Bug: T260584
Change-Id: I5dc20c233fd9ab41bdf48531829bddca2c5b25df
The interface has enough space for 2 or 3 lines of text.
(On mobile, the button has only an icon and no label.)
Bug: T260074
Change-Id: I50b08029f843e91d10b8c81985f6dfacbb96c8e7
We don't share much functionality, and we have to do a bunch
of hacks to disable functionality we don't want.
Change-Id: I9861123d8f1cbab1923f1aa5be713c2dadaed53d
The rendering is the same as before, but keeping the element around
makes it possible to override getDescription() to return some extra
text and have it appear as expected.
Change-Id: I1ef38abffbdb405121ea6b0b2ac368bbbb008cd7
This reverts commit e5c1ef651b.
This change caused an error where templates failed to be inserted
into wikitext in the 2017 wikitext editor.
Bug: T255785
Change-Id: Ie57c49e68e594be22af2b1b479840f29e46131db
mw.Target doesn't know about revid and etag, so move that logic
to ArticleTarget, where the param can still just be a boolean.
Change-Id: Idf4632cd28554aaf5bbf5f2b44ded047c0c4b182
The difference is that metaitems are not visible on the editing
surface, and their exact position is not preserved when the paragraph
containing them is edited.
This behavior is desirable for e.g. categories, but not for
<noinclude> and related tags, which are intentionally placed in
specific places in the text.
Note that we don't really have any editing interface for these nodes
yet. But you can see them (and they come with descriptions and links
to documentation pages), and delete or copy-paste them.
Bug: T250937
Change-Id: I104e7abbd650567df0e59813653c46a66d955d58
By default, many browsers permit resizing the textarea in both
dimensions; however, the SaveDialog doesn’t handle horizontal resizing
very well (the textarea is no longer centered and the options don’t
adapt to the new width), so add some CSS to limit the resizing to
vertical only.
Change-Id: I91bf63357237ddc2e3ede8e661480ab0cb48d10e
Code in ve.dm.MWTransclusionNode (which ve.dm.MWSignatureNode extends)
expects the node data to have an 'attributes' property.
We could override a bunch of methods to fix this, or add checks in the
original code, but it seems more future-proof to instead ensure that
the property exists.
Bug: T248585
Change-Id: I5bd721ca73605a396509669145b740db7283afd3
And factor out the common code for using a preference with a fallback to
localStorage or a cookie.
Bug: T235566
Change-Id: Ibb983319edcd2987225fe89677fd10e3ff8f9df6
