There is a namespace filter and two more options on the page.
They weren't preserved when the user navigated to another batch
of results (e.g., using "50 next").
Change-Id: I702c08957daa204f151db0d85063da9818835866
Every QueryPage needs a database to work
Inject the new service on special pages with already using services.
Bug: T259960
Change-Id: I96d91993b70052484c1a6a918a1e2ccc91e39ae7
This covers only directly used services by this special page
Services used by the base class are not part of this patch set
Bug: T259960
Change-Id: I68e6fc3427e2b91e1b64ae27da2e382d814b7446
Previously, if you visited e.g. 'Special:PagesWithProp/aaa' and then
changed the value in the form to 'bbb' and submitted, you would end up
on 'Special:PagesWithProp/aaa?propname=bbb', which is confusing.
Change-Id: Icea0a8131c29f87f045618e155d6142c4b29f437
Firstly, restore the availability to query all namespaces.
There is no reason to remove this feature.
Secondly, fix code not to treat '0' as falsy. Instead, use
the request object to get an integer or null.
Bug: T50247
Change-Id: I182e25be2d694d010a1e8382a461c5c08f898581
These stylesheets are sufficiently tiny that it doesn't make sense to
offer them the ability to be loaded separately from each other (saving
bytes in double-digits) at the cost of 1) exporting a dedicated registry
item with meta data shipped on every page view, 2) reduced cache re-use
from increased fragmentation.
Instead, move these to the 'mediawiki.special' style module.
The entries retain their own files to keep them as easy to find
and edit as before.
Where not already, ensure addModuleStyles() is always placed above
any addModules() call in the same method. The load order isn't
affected by the call order, but given blocking style-modules load
before async JS, it helps to order them in a way that visually
matches the effective load order (from top to bottom).
The following 7 modules were remove without deprecation:
1. "mediawiki.special.apisandbox.styles" (1 rule)
2. "mediawiki.special.edittags.styles" (3 rules)
3. "mediawiki.special.movePage.styles" (1 rule)
4. "mediawiki.special.pagesWithProp" (1 rule)
5. "mediawiki.special.upload.styles" (2 rules)
6. "mediawiki.special.watchlist.styles" (3 rules)
7. "mediawiki.special.comparepages.styles" (4 rules)
These module names were only used on the core classes loading them, and
aren't depended on outside core by module name, rather, extensions and
gadgets depend on the styles styles being loaded in a blocking manner on
these pages, which remains unaffected.
Bug: T192623
Change-Id: I6e663dc3c80c7104c9b9abdde44c654543185373
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: Ie419638e909a47aa72a274043604247830ee1a81
Always declare $propnames as an array; do not assume that there will
be a property to implicitly set it.
Bug: 51891
Change-Id: I82c6b71a3283c7dc17e66873c2e54cea973c67c0
Distinguish information about property values being hidden from the
actual values visually by making it italicised.
Added a new module, mediawiki.special.pagesWithProp.
Followup to Ib2db241a.
Bug: 51888
Change-Id: I6a0246e9b2a97b59503395ece7f80442ae3e0c69
It already looks rather silly when querying for 'templatedata' prop
from the TemplateData extension (e.g. [1]), it will start looking much
worse once Ie66b0dd6 in TemplateData is merged (which makes it store
the props gzip-compressed).
Do not show very long (over 1 kB) or binary (containing a null byte)
values; instead display a helpful message and size.
Changing the display format slightly, it's now "Page: <propvalue-or-message>"
instead of "Page (<propvalue-or-message>)", because the helpful
messages themselves include parentheses.
[1] https://en.wikipedia.org/wiki/Special:PagesWithProp?propname=templatedata
Bug: 51888
Change-Id: Ib2db241a117b06faee2426c8ea9ae18eab499e08
- Remove unneeded call to HTMLForm::setAction()
- Call HTMLForm::setWrapperLegendMsg() instead of HTMLForm::setWrapperLegend()
- Use Html::element() instead of Xml::span()
Change-Id: I4bc90c223a89bd31ce2d93a959e9bdf4b546e6dd
Having all group mapping for Special:SpecialPages in the global
$wgSpecialPageGroups is not a good OO style.
Created a method SpecialPage::getGroupName, which than can be overridden
by each subclasses to the featured group name.
Added also SpecialPage::getFinalGroupName to get the groupname on
Special:SpecialPages to handle the customization and
to keep $wgSpecialPageGroups for b/c
Change-Id: I1de3a186f0a59ec5ecb8996c5f805cf164e9637f
It would be useful to be able to list pages using a particular page
property, particularly in light of the new Disambiguator extension.
This adds a special page Special:PagesWithProp and an API query module
list=pageswithprop to do just this. It also adds an API query module
list=pagepropnames to list the prop names currently in use on the wiki.
Change-Id: Ib0d4e17f22b8d0cb9894eac6095962315480e809
