Use cases of HTMLForm should not supply user inputs as the default
value, espacially values that can't pass validations.
Bug: T41126
Change-Id: Ia50b06e12fbe5d47165a73245e695ba75fa4faec
Currently it is documented that mParent in HTMLFormField may be null.
This can happen if the form element is constructed manually via
new, instead of the normal way via HTMLForm methods.
As it stands, much of the code assumes that mParent is always set
despite the documentation. Lets mark creating form fields without
parent set as deprecated. The current situation seems like a
recipe for bugs, and after the deprecation period this would allow
us to simplify some of the HTMLFormField code.
Bug: T326456
Change-Id: Ica0740049f0a3e8ec764903c5b71825e4d628a3f
Depends-On: I15a39605e3eec8a5c265c4a331039fa906eda036
The methods HTMLFormField::getDiv, getRaw, getInline, etc. all
accept a single string parameter, but here are being passed null.
This raises a deprecation warning in PHP 8.1 in some situations,
(because of deeper usages of substr() etc.).
Bug: T289926
Change-Id: Id965f42b9cb4fc617d89c26d4459c66c3c478090
Mainly, document some parameters as non-empty-array so that phan knows
the list of arguments won't be empty when unpacking.
In EditPage, account for hooks potentially unsetting the copyright
notice.
Also rewrite some code in LogPager, so it's hopefully easier for phan to
understand what's going on.
Change-Id: Ic0638571554424098d0743db32dd46723a08e103
This patch introduces HTMLTimezoneField, an HTMLForm field type that
allows the user to select a timezone, either from a geographic zone, by
manually entering an offset, or using the wiki/browser default. This
logic is extracted from DefaultPreferencesFactory so that it can be
reused elsewhere.
The widget itself is really just an HTMLSelectOrOtherField, it's just
the list of options and the JS logic that is special.
Bug: T309629
Change-Id: I99a00dff7e3319ce45883191daee16bec1ed68ba
The variables are set conditional later, but all condition branches set
it or the variable is not used outside that scope
Change-Id: Ic9612915db507028ad4733a061d3ce9be3babfb6
Callbacks are documented to return Status, but we use the two
interchangeably almost everywhere, so this eliminates an easy
mistake possibility.
(The more ideal solution would be to allow returning StatusValue
from trySubmit and associated methods, but that's way more effort.)
Change-Id: I6c54b4aceb0430530d22423f8e80ab20a88548b3
In a default installation of Mediawiki, the article URLs use the URL GET
parameter "title" to construct the page title (index.php?title=Foo).
When a form is submitted, that parameter is added to the form as a
hidden field. Before this patch, it's added as last element of the form,
which makes the URL confusing. For example, when running a search on the
Lint errors, the URL becomes
index.php?pagename=Test&title=Special%3ALintErrors instead of starting
with title=Special:LintErrors as one would expect.
Note that this is not an issue on wikis that set their article path to
look like /wiki/Foo: in that case, the title of the page is not set as
a hidden field.
Change-Id: Id7c0617166754010cec987158e14ac54ddc94444
Using the constructor without the $context parameter was deprecated
in MediaWiki 1.38 in 97056794fc.
Bug: T308407
Change-Id: Id92adde978e70ffd6fa5d4a048d5d45c7ede4bf3
This edition brought to you by:
grep -ERIn $(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | tr
"\n" '|' | sed 's/|$/\n/') includes/
I only corrected a fraction of the results provided by that command. I'm
submitting the partial patch now so it doesn't bitrot.
Bug: T305805
Change-Id: If1918c0b3d88cdf90403921e4310740e206d6962
Make phan stricter about array keys
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T304887
Depends-On: I3105a5fd4826f8667b5232834defc5ec93be32a1
Depends-On: Ie9610a6e83731468311edb3ed17f80fc509de385
Change-Id: I701f12ab94478c3b8e7fd82110ade74a8e6b04ef
Some use cases like HistoryAction prefer the `index.php` form to keep
consistency, so they use setAction( wfScript() ) or something similar.
But the title is missing, so they hack it with manual addHiddenField()
or add a 'title' field in the descriptor. This is not good and prevents
us to warn the use of internal fields (title, wfEditToken).
Bug: T285464
Change-Id: Iaec81a2fb49162f2fc764f143f88e887572a3a0b
There is no reason to use loadData() only, and would unexpectedly skip
some necessary checks in prepareForm().
Some use cases are too old and didn't make use of the show() method
where should be available, which may be addressed in follow-up(s).
Bug: T256805
Change-Id: Ibbdc2c2c2b056342bb2c583a63546ac789b651d8
It was supposed to become required in 1.19, according to a code
comment (typo'ed in ead9055a).
There seem to be very few uses without the parameter out there (based
on a brief look at https://codesearch.wmcloud.org/), and most of them
are in tests, so they should be easy to find and correct.
Change-Id: I161cc342d1af813c281a6d9e30fdd85bc7b07578
I believe there is a mistake, since DefaultPreferencesFactory::cleanSignature() uses it as field data, which is the only filter applied in the core.
Change-Id: Ic7aa509a3e5fd3a3c717259d83d5bf0a26d3556a
Data of disabled fields wouldn't be sent to the server, which needs to load data from default.
Bug: T298614
Bug: T298819
Change-Id: I58f9df384df8ecc5ebae8cac68ec2251351bc984
Rename HTMLForm::[get|set|add][Pre|Post|Header|Footer]Text() to
HTMLForm::[get|set|add][Pre|Post|Header|Footer]Html() and
deprecate the old methods. Their arguments are rendered as raw
HTML so the old name was misleading.
Some of these are marked as stable to override and theoretically
the renaming could cause problems if callers are updated to the
new name while the overriding class is still using the old name,
but the only case known to codesearch is OOUIHTMLForm which is
also updated here.
Bug: T290771
Change-Id: I2c269eb6ab2b320fa2eef4ee8a226e96ad05fbe2
This name is consist with the rest of the setter and getter methods
in ParserOutput. Renamed the methods in OutputPage, ImageHistoryList,
ImageHistoryPseudoPager, and ContribsPager as well for consistency;
it also makes chasing down lingering references in codesearch easier.
Soft-deprecated the old name for 1.38. Hard-deprecation will follow,
but there are a number of users in production that should be chased
down first.
Code search:
https://codesearch.https://codesearch.wmcloud.org/deployed/?q=(allow%7Cprevent)Clickjacking&i=nope&files=&excludeFiles=&repos=
Bug: T287216
Change-Id: I9822c60c180d204bd30cb4447a1120155d456da4
The message keys by 'options-messages' are evaluated with
Message::plain(), but some situation needs Message::parse() to support
templates and HTML formatting in this values.
Bug: T58633
Change-Id: I8f52f21ae2641ddcad1aa85ce6bf14de1a09ab4b
Note that this changes the effective type of the protected mCancelTarget
field. This fields has no declared type, and does not seem to be used in
any subclass. The type of mTitle is not changed at this time, but
nothing seems to rely on that either.
Bug: T278459
Change-Id: I4bf0d46c74b53ffc9cb3e6e497c789ef6b3bab6a
Implements HTMLTagMultiselectField, a form field that instantiates
TagMultiselectWidget, the PHP representation of the OOUI's js-based
widget of the same name with the implemented parameters:
* allowArbitrary
* allowedValues
Bug: T278317
Change-Id: I3a6a30506d493be4185f917c577b3837fffd8ae1
single string is raw html,
not a message key as documented on HTMLForm::trySubmit
Also remove is_string, any truthy value would be implicit string casted
in HtmlForm::getErrorsOrWarnings
Reorder the if in HtmlForm to look similar to OOUI
Change-Id: I5b78b0df2cca695f8f5c6b08aa4d6c015d1fa1fe
Deconstructing non-sparse, numerically indexed arrays directly in
foreach (a.k.a. using the list() syntax in foreach) is possible since
PHP 5.5.
The possibility to use string array keys as well as non-sequential
numeric keys in array deconstruction was added in PHP 7.1.
Change-Id: I56a48552a45f61cedc291b306cad8548fc70d485
