wikimedia/mediawiki-skins-Vector
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/skins/Vector.git synced 2024-11-17 20:52:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-skins-Vector/includes/templates/Sidebar.mustache

25 lines
908 B
Plaintext
Raw Normal View History

[Dev] processTemplate used in one place Moving all the templateParser calls to one function so its easier to see how the template is composed. The diff of changes to the stories folder highlight the internal changes which are: * html-portals replaced with html-sidebar in main template * new Sidebar template added which outputs to html-sidebar * Mention of "MainMenu" replaced with better understood "Sidebar" This is precursory work to adopt templatePartials Change-Id: I6b2196e39087f818e774d04b2d1b9ab8cb8816a1
2020-02-14 20:33:54 +00:00
{{!
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] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
@typedef object emphasized-sidebar-action
@prop string href
@prop string text
[Dev] processTemplate used in one place Moving all the templateParser calls to one function so its easier to see how the template is composed. The diff of changes to the stories folder highlight the internal changes which are: * html-portals replaced with html-sidebar in main template * new Sidebar template added which outputs to html-sidebar * Mention of "MainMenu" replaced with better understood "Sidebar" This is precursory work to adopt templatePartials Change-Id: I6b2196e39087f818e774d04b2d1b9ab8cb8816a1
2020-02-14 20:33:54 +00:00
string html-logo-attributes for site logo. Must be used inside tag e.g. `class="logo" lang="en-gb"`
Simplify menu code SkinMustache in core provides most of what is required for Vector to generate its menus. In the interest of having a canonical source of truth for menus across all skins, Vector should use this data. To ensure the HTML generated is (mostly) the same after this patch to prior, a few modifications are necessary: * The data from core is decorated so that Vector can continue having its own custom class names on menus. This is done using the decoratePortletClass method. * There is no support for a menu having a header representing the selected menu item, as is currently the case with variants. This is achieved via an extension to getPortletData. It's assumed that later when variants are merged with languages, this can be removed. * Menus are agnostic to how they are displayed, so we must continue to add the is-dropdown template variable to drop down menus. In future we may want to rethink our Menu partial to make this unnecessary in PHP. * The portal-first class is redundant in the modern Vector as we can use the first-child selector. Previously we introduced a class to service the legacy skin where this rule doesn't apply as #p-logo is the first child. However, the legacy skin can do this using a special next sibling selector instead. Bug: T268157 Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
2020-09-04 19:18:57 +00:00
MenuDefinition data-portlets-first
MenuDefinition[] array-portlets-rest
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] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
emphasized-sidebar-action data-emphasized-sidebar-action For displaying an emphasized action in the sidebar.
[Dev] processTemplate used in one place Moving all the templateParser calls to one function so its easier to see how the template is composed. The diff of changes to the stories folder highlight the internal changes which are: * html-portals replaced with html-sidebar in main template * new Sidebar template added which outputs to html-sidebar * Mention of "MainMenu" replaced with better understood "Sidebar" This is precursory work to adopt templatePartials Change-Id: I6b2196e39087f818e774d04b2d1b9ab8cb8816a1
2020-02-14 20:33:54 +00:00
}}
Remove unused `mw-checkbox-hack-target` class Even if we were to use it, we might sign up for side-effects when more than one checkbox hack is used per view. Change-Id: Ic31e48a4bf3e39e903300acd522b7af0391fafa9
2020-06-11 21:51:43 +00:00
<div id="mw-panel" class="mw-sidebar">
Simplify menu code SkinMustache in core provides most of what is required for Vector to generate its menus. In the interest of having a canonical source of truth for menus across all skins, Vector should use this data. To ensure the HTML generated is (mostly) the same after this patch to prior, a few modifications are necessary: * The data from core is decorated so that Vector can continue having its own custom class names on menus. This is done using the decoratePortletClass method. * There is no support for a menu having a header representing the selected menu item, as is currently the case with variants. This is achieved via an extension to getPortletData. It's assumed that later when variants are merged with languages, this can be removed. * Menus are agnostic to how they are displayed, so we must continue to add the is-dropdown template variable to drop down menus. In future we may want to rethink our Menu partial to make this unnecessary in PHP. * The portal-first class is redundant in the modern Vector as we can use the first-child selector. Previously we introduced a class to service the legacy skin where this rule doesn't apply as #p-logo is the first child. However, the legacy skin can do this using a special next sibling selector instead. Bug: T268157 Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
2020-09-04 19:18:57 +00:00
{{#data-portlets-first}}{{>Menu}}{{/data-portlets-first}}
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] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
{{#data-emphasized-sidebar-action}}
Merge EmphasizedSidebarAction.less into Sidebar.less The opt in link is part of the sidebar in the current modern version of vector. The legacy sidebar has been split out and frozen. For this reason I think it makes sense to move the styles for the button into the sidebar stylesheet. The class name is renamed to reflect the hierarchy. We are not using BEM but we are using hyphens to describe location so the newly proposed names `mw-sidebar` and `mw-sidebar-action` seem more applicable than the previous generic class names. This doesn't impact caching given anonymous users cannot see the opt in/out link. Change-Id: I2991e941592a0678f40c73bb6daeab71ada6b7c3
2020-05-26 17:38:24 +00:00
<div class="mw-sidebar-action">
Refactor: All messages should be listed from skin.json This allows us easily to identify in templates what messages are used and where, as well as allow us an easy way to tell when messages are no longer being used. Change-Id: I610224d551ebea54ae32e9e79901befe80cfd5ce
2020-08-05 20:27:38 +00:00
<a class="mw-sidebar-action-link" title="{{msg-vector-opt-out-tooltip}}"
href="{{href}}">{{msg-vector-opt-out}}</a>
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] https://github.com/wikimedia/mediawiki/blob/0030cb525be6cabc1d63de80586b2017d4bbe354/tests/common/TestsAutoLoader.php#L64 [2] Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76 [3] https://www.mediawiki.org/wiki/Stable_interface_policy Bug: T243281 Change-Id: I0571b041bcd7f19bec9f103fa7bccdd093f6394d
2020-03-17 20:21:33 +00:00
</div>
{{/data-emphasized-sidebar-action}}
Simplify menu code SkinMustache in core provides most of what is required for Vector to generate its menus. In the interest of having a canonical source of truth for menus across all skins, Vector should use this data. To ensure the HTML generated is (mostly) the same after this patch to prior, a few modifications are necessary: * The data from core is decorated so that Vector can continue having its own custom class names on menus. This is done using the decoratePortletClass method. * There is no support for a menu having a header representing the selected menu item, as is currently the case with variants. This is achieved via an extension to getPortletData. It's assumed that later when variants are merged with languages, this can be removed. * Menus are agnostic to how they are displayed, so we must continue to add the is-dropdown template variable to drop down menus. In future we may want to rethink our Menu partial to make this unnecessary in PHP. * The portal-first class is redundant in the modern Vector as we can use the first-child selector. Previously we introduced a class to service the legacy skin where this rule doesn't apply as #p-logo is the first child. However, the legacy skin can do this using a special next sibling selector instead. Bug: T268157 Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
2020-09-04 19:18:57 +00:00
{{#array-portlets-rest}}{{>Menu}}{{/array-portlets-rest}}
Languages can be moved out of sidebar A new config flag wgVectorLanguageInHeader is added to allow us to render languages in sidebar or outside sidebar, in the header. it defaults to false to allow for further development and to not disrupt the status quo. To accomodate the new menu, a new header is added based on the design in Minerva to contain the heading and language button. The language button is floated to the right. The new menu is not styled. That exercise is left for the follow up task T268241 No caching implications of this change, as legacy and modern experiences remain touched without changing the default value of the new config flag Bug: T260738 Change-Id: I5af1522cac3831c1c833388461fe254c03191f65
2020-08-18 21:30:25 +00:00
{{^is-language-in-header}}
Simplify menu code SkinMustache in core provides most of what is required for Vector to generate its menus. In the interest of having a canonical source of truth for menus across all skins, Vector should use this data. To ensure the HTML generated is (mostly) the same after this patch to prior, a few modifications are necessary: * The data from core is decorated so that Vector can continue having its own custom class names on menus. This is done using the decoratePortletClass method. * There is no support for a menu having a header representing the selected menu item, as is currently the case with variants. This is achieved via an extension to getPortletData. It's assumed that later when variants are merged with languages, this can be removed. * Menus are agnostic to how they are displayed, so we must continue to add the is-dropdown template variable to drop down menus. In future we may want to rethink our Menu partial to make this unnecessary in PHP. * The portal-first class is redundant in the modern Vector as we can use the first-child selector. Previously we introduced a class to service the legacy skin where this rule doesn't apply as #p-logo is the first child. However, the legacy skin can do this using a special next sibling selector instead. Bug: T268157 Change-Id: I5f7adc1840441b508ffee40139b85b64021789e6
2020-09-04 19:18:57 +00:00
{{#data-portlets.data-languages}}{{>Menu}}{{/data-portlets.data-languages}}
Languages can be moved out of sidebar A new config flag wgVectorLanguageInHeader is added to allow us to render languages in sidebar or outside sidebar, in the header. it defaults to false to allow for further development and to not disrupt the status quo. To accomodate the new menu, a new header is added based on the design in Minerva to contain the heading and language button. The language button is floated to the right. The new menu is not styled. That exercise is left for the follow up task T268241 No caching implications of this change, as legacy and modern experiences remain touched without changing the default value of the new config flag Bug: T260738 Change-Id: I5af1522cac3831c1c833388461fe254c03191f65
2020-08-18 21:30:25 +00:00
{{/is-language-in-header}}
[Dev] processTemplate used in one place Moving all the templateParser calls to one function so its easier to see how the template is composed. The diff of changes to the stories folder highlight the internal changes which are: * html-portals replaced with html-sidebar in main template * new Sidebar template added which outputs to html-sidebar * Mention of "MainMenu" replaced with better understood "Sidebar" This is precursory work to adopt templatePartials Change-Id: I6b2196e39087f818e774d04b2d1b9ab8cb8816a1
2020-02-14 20:33:54 +00:00
</div>
Reference in a new issue Copy permalink