When working on multiple skins its been confusing to know how the lists
are created from the HTML. In Vector we've also resorted to some overly
complex styling rules to style `li` elements. It's proposed a mw-list-item
class is added to simplify Vector styling and make it easier to understand
how the HTML is generated.
Change-Id: I67731fe59743620d339ffcca3ffc3b1f127ce3e7
- Update $content_navigation in SkinTemplate::buildContentNavigationUrls() to include a new top-level menu.
- Exclude user-interface-preferences menu from content navigation in legacy skins.
- Add method makeSkinTemplatePersonalUrls() to SkinTemplate to build personal urls.
- Rename method to injectLegacyMenusIntoPersonalTools() to add legacy menu items.
- Update unit test for renamed method injectLegacyMenusIntoPersonalTools().
Bug: T282196
Change-Id: If4805e5186756056afcd31d21919e907a7782ce8
We filter out icons with no images, which includes empty icon arrays,
already. Let's also remove their containers if nothing winds up inside
them so we're not returning any empty container arrays, either.
Bug: T278266
Change-Id: If9bfb764b61a77e71ca7f374fa67a56ac89c799f
It is not entirely meaningless. It might be an indicator that
the number of calls to a method is intentionally unlimited.
This is similar to e.g. an @inheritDoc PHPDoc comment that
marks a method as being "intentionally undocumented".
However, what's the meaning of being "intentionally
unconstrained"? Let's just not have any constraint then.
I feel all these ->expects( $this->any() ) bloat the test
code so much that it's never worth it.
Change-Id: I9925e7706bd03e1666f6eb0b284cb42b0dd3be23
This allows separating notifications from personal tools.
The notifications are still inserted into the personal tools,
after the userpage, for skins using BaseTemplate, skins that
call buildPersonalUrls without the argument, skins that call
either getStructuredPersonalTools, makePersonalToolsList without
providing it personal tools or getPersonalToolsList.
Mustache skins that use data-personal are unaffected, and can
retrieve personal tools without notifications from data-user-menu
and notifications from data-notifications, both of which are in
the data-portlets array.
Notifications are manually inserted in both SkinTemplate and
SkinMustache to prevent calling buildPersonalUrls multiple times.
For backwards compatibility with user code and gadgets, the new
user-menu portlet uses the same id and classes as the personal
tools, allowing it to serve as a drop-in replacement.
Skins shouldn't output both.
Bug: T266613
Depends-On: Ib4112364c173952eb363e52756f03693a2e03512
Change-Id: Ia1451e3e802441162eecfc5b7f6a7ba2ae72f377
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
The new SkinMustache class is based on the emerging class in Vector.
Having this in core, will allow Vector to make use of this class
immediately and provide a minimal generic mechanism going forward
for rendering skins using Mustache. For now, I've fleshed out the minimum
possible data in getTemplateData which are based on existing functions in
Vector.
The Skin class now takes a generic options parameter which allows
registration of a skin using the SkinMustache class with a templateDirectory
option pointing to the associated template. A `styles` option can be passed
to define stylesheets that should be associated with the skin.
The SkinApi and SkinFallback classes are reduced significantly.
There are no known uses of SkinApiTemplate and it is thus removed.
SkinFallbackTemplate is removed and its functions copied across to
SkinFallback
End user changes:
* The fallback skin no longer prints the confusing warning message if the default
skin is setup incorrectly. Previously viewing the fallback skin with useskin
indicated that wgDefaultSkin was not set correctly which was misleading and confusing.
* Factory functions now receive skin options as a second parameter and the service as a
first - this is due to how ObjectFactory handles the extraArgs key for 'factory' key
- placing it at the beginning.
Bug: T254048
Change-Id: Ibbabd1d0f26efebf8f8ff068966685dc2191c527
I tried to simplify this test as much as possible. I found this used to
many hard to follow indirections and overly complicated helper methods,
when a straigt assertContains() should be enough.
Change-Id: I8133ce24d7b3d0bd859eba45e6f7da22a3a8bdec
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
This is part of refactoring skin code to allow us to move away
from SkinTemplate.
Move BaseTemplate functions to skin and soft deprecate them
to avoid compatiblity issues so they can be used inside the
Skin class by skins not using BaseTemplate
Note to reviewers:
The function bodies are copied without modification to Skin
with the following exceptions:
1) A phan comment is dropped and the only change.
2) wfMessage is replaced with msg
See I7a14f74728703c50874935e9d77b35ad9434b436 for a
bigger picture view of how
this would simplify Vector's codebase
Update function of `getStructuredPersonalTools`
to not use SkinTemplate
Bug: T251212
Depends-On: Ifd9bbc9c909626ecfe8ccd085673bc777423d560
Change-Id: I99c7cebc277cb0680ab369c78f02ab370193d5c5
Also fix PHPUnit 9 warning in PNGMetadataExtractorTest about $delta.
This should fix all of the integration test warning spam.
Bug: T244095
Change-Id: I0e2a76d5df2685ae5ad1498864e0b5f9db60c0cc
Use the existing `legacy` feature. It's assumed that this module was always
used with `mediawiki.legacy.shared` and minimizes disruptions given the
migration steps are identical to the approach taken in `mediawiki.legacy.shared`
The existing release notes are updated to reflect this.
Bug: T242177
Change-Id: I785321d86a5f26808eb83847a3dbbbe62c62698c
Skins that are using ResourceLoaderSkinModule will need to update their
features to include `legacy`
Note that Ic7af947cfd5a5df4218f006232ede4ee7ed36c62 for Vector
and I6471bc169f3c2a1f51e17b8ee26ac245b0374c18 for Monobook should
be merged in the same release as this patch to ensure these styles
do not disappear from those skins. Minerva or Timeless will not be impacted.
Changes for other skins including Modern and CologneBlue to follow
where needed.
Bug: T242177
Change-Id: Icb910a563273bde92a09b1bb92857d5b6e348baa
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
This advances T140664 as well, because it encourages module
loading logic from the skin to be in this single method.
Update the tests for setupSkinUserCss(), to now target
getDefaultModules() instead, given setupSkinUserCss() no longer
provides these behaviours. Had to move where the mock object
was created so that it can be injected in the skin (previously
it could be passed as parameter). Besides, its generally best-
practice to create mocks and stubs within the test anyhow, not in
the data provider.
Bug: T140664
Depends-On: Ib2b19ba165a9d646a770702cdf1724509156b93e
Change-Id: I3404c1c2a7e8eae0b803b31f333cb9b837f43d4a
Due to T127238, files in various */skins/* directories are not checked
by PHPCS. Temporarily removed the exclude rule from phpcs.xml and ran:
composer fix includes/skins/* tests/phpunit/includes/skins/* tests/phpunit/skins/*
Change-Id: I9240c1cee825920b6634903282be6252cce55686
* Remove redundant @licence/@license from test suite files.
They already have full licence headers. And @licence raises a
warning in Doxygen.
* Fix weird messes of comments inside comments and other things.
Change-Id: I38da8ca76330f72b8dc22b0ecf1ea69d5ea55ede
Modeled similar to ConfigFactory, this lets skins
register themselves via a callback, allowing for
proper dependency injection.
Loading via $wgValidSkinNames is still supported,
but considered "legacy", not deprecated though.
Skin::newFromKey is now deprecated (and had only
one caller in an extension, which I'll update
afterwards).
Change-Id: I1960483f87c2ef55c994545239b728fa376f17f4
2014-08-09 21:40:54 +01:00
Renamed from tests/phpunit/includes/SkinTemplateTest.php (Browse further)
