The following sniffs now pass and were enabled:
* MediaWiki.Commenting.LicenseComment.InvalidLicenseTag
Change-Id: I13c4825186d8ba101feb2a2d28ee8dc9bc7306dd
We keep constants in CategoryTree.php extension loader to maintain
backwards compatibility with the MediaWiki configuration. It's expected
users will migrate from them when they switch to wfLoadExtension.
Bug: T87888
Change-Id: If67d0fe2ff758c7fd41386d04f5c0839c8c665a1
The extension CT_* defines are replaced by class constants.
We currently keep the former defines in CategoryTree.php,
to help to set the default configuration. When the code
will be migrated to use the extension registration, we'll
remove the defines.
Bug: T87888
Change-Id: I59e6b9319fd5130c51a23f21ea81d4dbf3f28b8e
The extension entry point contains several callback functions, and an
helper function. We move them respectively to the new CategoryTreeHooks
class and to the existing CategoryTree class.
This change is intended to prepare the extension transition to the new
registration system.
Bug: T87888
Change-Id: Ic6ddd6f0dc51e90391f2b8d3c4450683ed67c018
Style modules currently added through addModuleStyles default
to being in the head ("top" position). This is an unhealthy default,
since only critical styles that are needed at pageload should be
in the head. In order to be able to switch the default to "bottom",
existing module positions have to be defined explicitly.
Bug: T97410
Change-Id: I7ce807e7043b8dc059fe8211dc01396c9b67e1d7
Follows-up I32357244c013a2370f14f.
I don't know how or why, but this late way of registering magic
words from within an extension setup function is sometimes
causing people's install to fatally crash on:
> Exception from line 318 of mw/includes/MagicWord.php:
> Error: invalid magic word 'categorytree'
Just move it out of there into a plain and simple registration.
The parser function itself is still registered conditionally.
Change-Id: I07df5de5f39ce0ad029ef0152d126e620308ba25
Previously, $wgOut was used when $wgCategoryTreeForceHeaders was set and
a hook was used when it was not.
This change makes sure there is always a hook used with an OutputPage
instance. It fixes bug 57651.
Using $wgOut the rebuildFileCache.php maintenance script would generate
pages without JavaScript and CSS for CategoryTree when
$wgCategoryTreeForceHeaders was set (for example, when the sidebar was
in use).
Other uses of $wgOut in the CategoryTree extension seem to be less of an
issue because when there is a CategoryTree on a page, those pages seem
to be excluded from caching. (But fixing those would be nice
nonetheless: it may prevent other bugs in the future).
Bug: 57651
Change-Id: I0ee66d38755e255c5597db7a237a176039025fae
Extension config based on values of config values isn't going to work
in the global scope. The user won't have set it yet.
Though, is there any reason we don't just loads this always?
Change-Id: I32357244c013a2370f14ff5d36427aa3385be444
Procedure per https://www.mediawiki.org/wiki/Manual:GenerateJsonI18n.php
with shim.
Add a file to .jshintignore to not make Jenkins block on something that's
not related to this patch set.
Change-Id: I9331d328746281a2eb7ec1317d557e8fd7931d74
Somewhere along the line this extension's JS was refactored,
except for a part which was left as is, and was calling functions
since renamed, and still assuming top loaded...
Just kill $wgCategoryTreeDynamicTag, since it doesn't work, it
hasn't worked for a while, and it looks like a bit of work to
make it work properly. Also change the cache disabling defaults
of this extension to be 6 hours so it doesn't cause explosions.
If someone wants the feature represented by $wgCategoryTreeDynamicTag
they can of course re-introduce it in a subsequent commit. In the
mean time, let's not have broken code.
Bug: 59798
Change-Id: I01e0bd264e2a007cd9de017d10667bb2809d70a9
Remove some unused variables (set to '' and never set for use in query)
Wrap some long lines
Add a few braces
Add CategoryTreeCategoryViewer to AutoloadClasses
Add @var type docs for member variable
Change-Id: I77c870a9159a4e16a4fe172ac007b28a221cb090
* So that local settings are actually used, regardless of order.
wgExtensionFunctions should be early enough still.
Change-Id: I38aa542f3e1940398c3a80927cf3de44790c6b7b
There's a couple of WTF moments in the code, this is really due to some issues with the PHP side of stuff. It really needs some TLC but for right now it works, I'll come back to it before 1.19 and clean it up.
This should obsolete $wgCategoryTreeMaxScanRows, added in r67179, so I
removed it. Note that I only tested with very basic usage, since I
don't quite understand all the complicated things this extension can do,
and some code paths are certainly going to remain inefficient, since
arbitrary namespace filtering seems possible here (at least
renderChildren() has support for it). However, clicking the little plus
sign on category pages should now scan only as many rows as are actually
used, so no limit should be necessary.
Sorting is now by cl_type, cl_sortkey instead of cl_sortkey. This
change has to be made to all users for efficiency, since the old index
was dropped. It means the sort order might be somewhat unexpected in
some cases, but for basic CategoryTree use it makes no difference, since
all the results have cl_type = 'subcat' anyway.
Fixes bug 23682, I think.
* Fixed a bug causing the "+" link to be shown even when the number of subcategories is zero, due to the DBMS returning a string instead of an integer, causing triple-equals comparison to fail.
* 1.11 and below aren't supported anymore, so we don't need to be maintaining back-compat code for it anymore. This is why we branch extensions
* The vast majority of these were using $wgParser. This defeats the purpose of ParserFirstCallInit...allowing you to use parsers other than $wgParser. All these extensions now work in any instance of the Parser, not just $wgParser
Uses $dir in extension files, and assumes that it remains unchanged in require_once( 'maintenance/commandLine.inc' ).
In fact, it is likely that '$dir' will be set when setting up command-line, as some extensions will use the same var.
Recommended fix: Use $CentralAuth_dir, $EmailPage_dir, etc.
