Commit graph

16 commits

Author SHA1 Message Date
AronDemian b0281fa450 Add CSS class on body to mark the skin version
Adds class 'skin-vector-legacy' for legacy layout.

Bug: T251648
Change-Id: I52938689fc7d99a710510349aaa573a87864a367
2020-05-08 16:30:26 +02:00
Sam Smith cee5ee0003 Make legacy mode a feature
Changes:

- Add the LatestSkinVersionRequirement requirement class, which lazily
  evaluates the application state to get the version of the skin for the
  request.

  This majority of this class is taken from Stephen Niedzielski's
  Vector\SkinVersionLookup class, which was introduced in d1072d0fdf.

- Register an instance of LatestSkinVersionRequirement and register the
  'LatestSkin' feature that requires that requirement

- Re-introduce SkinVector::isLegacy and make it defer to the Feature
  Manager

Bug: T244481
Change-Id: If6b82a514aa5afce73e571abdd8de60b16a62fa8
2020-04-21 10:57:11 -06:00
Stephen Niedzielski d1072d0fdf [dev] add skin version query parameter override
As described in the readme but not implemented until now, this patch
enables the skin version to be specified as a URL query parameter. This
is useful for testing both skin versions during development and on wiki,
as well as enabling sharing URLs with a specific skin (Vector) and skin
version (1 or 2).

Obtaining the actual skin version requires tying together three input
sources, WebRequest, User, and Config. It seems simple but it'd be easy
to botch. For this reason, a helper class to correctly interrogate them
and tests are provided.

Bug: T244481
Change-Id: I52d80942b4270c008d4e45050589ed9220255a50
2020-04-02 16:22:26 -06:00
Nicholas Ray ec382a8c86 Add opt-out link to Sidebar for Vector/Logged-in Users Without Abstractions
This commit is singularly focused on adding a link to the sidebar for
Vector, logged-in users. It does the bare minimum to fulfill the
requirements of T243281.

Additionally, it will help to answer the question "Do we need to use
abstractions (other than maybe different templates) to separate Legacy
Vector from Vector" by intentionally leaving out any abstractions in
order to make it easier to compare with a follow-up patch
(Ib2ef15180df73360cc1de25b893e49d415d23e1a) which does use abstractions.

It is a good thing to question whether or not we need addtional
abstractions in VectorTemplate and if they will help us as unnecessary
abstractions can have the opposite effect and just lead to further
frustrations down the road.

Therefore, I urge you, the reviewer, to let me know your thoughts! If
abstractions are viewed as not making our lives any easier, the
follow-up patches may be completely discarded and that's totally okay
with me. :) I think it's a good think to talk about now though.

Important changes:

* The VectorTemplate constructor was changed to allow injecting the
config, templateParser, and isLegacy boolean (only the config was
allowed before this commit). According to MediaWiki's Stable Interface
Policy, "Constructor signatures are generally considered unstable unless
explicitly declared stable for calling" [3]. Given that VecorTemplate's
constructor is not marked as stable, it is justified to do this without
warning according to the policy.

* Due to the above, the 'setTemplate' method is no longer needed and was
marked as deprecated.

* VectorTemplateTest was made to adapt to the new VectorTemplate
constructor. Additionally, it now extends from
MediaWikiIntegrationTestCase which my intelliphense server can pick up.
I *think* MediaWikiTestCase is just an alias to
MediaWikiIntegrationTestCase [1] and MediaWikiTestCase file was renamed
to MediaWikiIntegrationTestCase in [2], but I'm willing to change it
back if there is pushback to this.

Open questions:

* What are VectorTemplate's responsibilities? To me, it acts right now
as a controller (because it echos the full HTML string from the
template), a model (because SkinTemplate::prepareQuickTemplate sets data
on it which it later retrieves through `$this->get()`), a presenter
(because it adds data tailored for a web-centric view), and a view
(because it renders HTML strings instead of letting the view/template be
solely responsible for that). Arguably, some business logic might be
mixed in there as well (because it checks to see if a User is logged
in/has necessary permissions to show x which my changes here add to).
This might not be a problem if we keep VectorTemplate relatively small,
but will it remain this way as we progress further in Desktop
Improvements?

* How do we write tests for VectorTemplate without exposing unnecessary
public methods? For example, if I want to test the `getSkinData()`
method to see what state will be sent to the template, how should I do
this? One option might be to use `TestingAccessWrapper` to expose these
private methods which is what
`VectorTemplateTest::testbuildViewsProps()` does. Another option is to
accept this method as public. Is there a better way? Keep in mind that
even with access to this method, there might be many things to mock.

[1] 0030cb525b/tests/common/TestsAutoLoader.php (L64)
[2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
[3] https://www.mediawiki.org/wiki/Stable_interface_policy

Bug: T243281
Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-26 17:39:47 -06:00
jdlrobson 4091a6729f Document setupTemplate method and mark Vector as @final
Various skins may extend SkinVector (although none are in production)
(https://github.com/search?q=%22extends+SkinVector%22&type=Code)
This makes it clear we no longer support that behaviour.

Because of the skins that are extending SkinVector currently we have
not resorted to using the final keyword at this time.

Depends-On: Ie3759c2acbf53c628577f6b05cfed17e0998a6bb
Bug: T248399
Change-Id: I2af8b2930c80f888791247bdaa2ae1c80576317e
2020-03-25 18:04:16 +00:00
jdlrobson 9a3a3d3c96 Ship different ResourceLoader module for different versions
To have a clean break for upcoming changes we will duplicate
index.less into legacy.less and create a new module to clearly
separate new styles from old.

The preferred name however does come with some caching challenges.
Cached HTML served to anons will continue to load the style module
`skins.vector.styles` for a period of 1-4 weeks

Provided we are careful with our changes during this period this
should be okay.

Change-Id: If32b59036e5cd62cbb804944ca93fa1a101c5129
2020-03-12 13:36:52 -07:00
jdlrobson 2dbe4d7af1 Drop usage of mediawiki.skinning.interface module in favor of SkinModule
Thanks to the dependent change, the print logo is now provided
in core so we can remove the custom Vector ResourceLoader module

ResourceLoaderLessModule is replaced with a ResourceLoaderSkinModule
and gains the features capability replacing the need for
'mediawiki.skinning.interface' making use of the changes added in
6845912bcf1.

Note that for cached HTML both 'mediawiki.skinning.interface'
and skins.vector.styles will be loaded. We can avoid this
by renaming skins.vector.styles if necessary (but I'm not
sure if we'd want to do that)

Bug: T232140
Depends-On: I00899c16c0325f36b671baf17e88c2b5187b3526
Change-Id: I569e0d800e147eabc7852567acd140108613f074
2020-02-05 10:02:47 +08:00
polishdeveloper 09671d768f Introduce PHPUnit tests in Vector
To make it happen, we also need to provide a way to
inject different TemplateParser.

Change-Id: I14d8474a2b52f040b688245cbd5bd6f12dddf846
2020-01-31 16:48:43 +01:00
jenkins-bot 9cf4eb0e7e Merge "Hygiene: remove vectorConfig and use the getConfig" 2020-01-13 22:43:12 +00:00
Piotr Miazga 02d4e4929f Hygiene: remove vectorConfig and use the getConfig
The SkinVector implements IContextSource, thus it has to provide
the getConfig() method. Vector skin is currently using
it's own `vectorConfig` in one place and it passes the VectorConfig
to the VectorTemplate class. Sadly the VectorConfig is the same
thing what $this->getConfig() provides. There is no need to make
this code more complex by handling two different config containers
which at the end are the same GlobalVarConfig instances.

If we decide to handle VectorConfigs differently, let's thing it
through, for now we should simplify code and remove all uncessary
logic. Thanks to that, there is also no need to override the
setupTemplate().

Change-Id: I89c8a77f7d96f867c8c72e61f9e104e14d9512d9
2020-01-13 23:01:42 +01:00
jenkins-bot f40247a9d4 Merge "Hygiene: remove SkinVector::setupSkinUserCss" 2020-01-13 19:38:35 +00:00
Piotr Miazga 8a8a44ca00 Hygiene: remove SkinVector::setupSkinUserCss
Tthe SkinVector::steupSkinUserCss is deprecated and
we should use the ::getDefaultModules instead.

Change-Id: I359049d0f159a0dfc374d1c0124e8989aeb4182d
2020-01-13 14:14:39 +01:00
Piotr Miazga 2f355a3e11 Hygiene: remove getPageClasses
Looks like the SkinVector::getPageClasses is doing nothing, only
calling the Skin::getPageClasses and returning the output.

Change-Id: I5becaa1505d46cbf9a07b8bfe73ddf324b740876
2019-11-18 15:13:24 -05:00
Fomafix 3aeac1615b SkinVector: Call parent::__construct in constructor
With this change the constructor of the parent class gets called like if
there is no local constructor. This allows the ancestor classes to
initialize themself in their constructor.

Change-Id: I4ec1ec935afa25b59be4020fca9ac71f23e62ad0
2019-05-12 11:36:38 +02:00
Umherirrender 4b5f4256e1 Add method scope visibility
Change-Id: If1705b4834fb1ebeb1260cde26a2e3e3c4ca94a0
2018-11-01 21:01:32 +01:00
Timo Tijhof 2fa3b7f69a Move class files to includes/
Cleans up the top-level directory a bit.

Change-Id: I29d3b8b7098def77e643232a386d8ba834d35704
2018-03-12 16:52:48 -07:00
Renamed from SkinVector.php (Browse further)