Problem/Motivation

See discussion in: #2195695: Admin UIs on the front-end are difficult to theme
See: #2489460: [Meta] Move module.theme.css files to Classy or Seven

Shortcut links are an administrative UI component that appears on the frontend of sites. It's important that they are consistent with the Seven style guide and that other admin themes can control the look and feel.

Proposed resolution

Our CSS standards define module CSS as: “the minimal styles needed to get the module's functionality working.”
Theme CSS is defined as: “extra styles to make the module's functionality aesthetically pleasing. ”
Move the theme styling into the Seven theme
Add a library alter hook to load the admin theme CSS. Example: #2341221: Node preview bar has usability issues, is difficult to use on mobile, not usable without Bartik, and does not align with the Seven style guide and current toolbar designs

Remaining tasks

Write the patch.
Test.

User interface changes

None

API changes

None

Data model changes

None

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

LewisNyman created an issue. See original summary.

LewisNyman’s picture

Component: contextual.module » shortcut.module
Status: Needs review » Active
jibran’s picture

Out of the box shortcuts module supports all the core themes so moving to classy makes sense but I'd be reluctant to move it to seven.

Moving to classy means that for every conrtib them which supports shortcuts has to be a subtheme of classy. Neither omega nor bootstrap is using classy as a base theme and @JohnAlbin hasn't made any decision to use classy as a subtheme for zen but I have an inside news that he is not planing to use classy for zen. Shiny doesn't have a D8 branch yet so I don't know about it. adaptivetheme does use classy as base theme. Given all that moving to classy doesn't make sense as well.

I just had a quick look at shortcut.theme.css & shortcut.icons.theme.css all the classes are added in shortchut.module file. IMO the css file names are wrong because this CSS is not specific to any theme at all.

If we end up doing this anyway I would like to see all the (ltr+rtl) screenshots from all the themes in core just to make sure that we are not introducing any visual regression here.

I'm not a front-end expert so I might be missing a bigger picture here but I have done my due diligence as a module maintainer.

Thanks for creating the thorough IS.

LewisNyman’s picture

I was just thinking about this after #2544390: Fix shortcut action link styling in bartik. I guess moving it to Classy instead makes the most sense, then theme maintainers have a choice if they want to style it themselves or they want to use the default styling. If we moved it to Seven we could also implement it in a way where it is loaded in the frontend. We are using this technique for a lot of issues under #2566775: [Voltron patch] Move all remaining *.admin.theme.css to Seven for admin widgets that appear on the frontend. Do you consider shortcuts to be an admin widget?

The key decision here is that not choosing Classy for your frontend or admin theme means that you want to take over the styling of everything yourself. Shortcuts should only be functional.

jibran’s picture

Do you consider shortcuts to be an admin widget?

I think shortcuts functionality is more helpful for content editor. It helps admin to create workflow for content editor with useful links for them.
+1 to move it to classy.

theme maintainers have a choice if they want to style it themselves or they want to use the default styling.

+1 to this as well.

gints.erglis’s picture

LewisNyman’s picture

Status: Active » Needs review
tstoeckler’s picture

FileSize
19.58 KB

Re-rolled with -C -M, looking at that one now. Not sending for testing, because it's the same code.

tstoeckler’s picture

Re-rolled with -C -M, looking at that one now. Not sending for testing, because it's the same code.

jibran’s picture

Issue tags: +Needs screenshots

Please post before and after screen shots of all themes so that we can confirm there is no regression after this. To enable shortcuts for themes other then seven see #2544390: Fix shortcut action link styling in bartik.

gints.erglis’s picture

I want to provide another solution for this issue. This patch provides moving all CSS to Seven, declaring library 'drupal.shortcut' in Seven theme, including this library in Classy theme. As Bartik theme is based on Classy, the shortcut style works there. If custom theme don't want to use a Classy base theme, but wants to use a default shortcut style, then library could be included like in Classy.
I would like avoid using this alter hook in the core modules, doesn't seem clean for me.

Status: Needs review » Needs work

The last submitted patch, 11: move_shortcut_theme_css_to-2566841-11.patch, failed testing.

jibran’s picture

+++ b/core/themes/classy/classy.info.yml
@@ -8,3 +8,4 @@ core: 8.x
+  - seven/drupal.shortcut

I'm all for avoiding alter hook but this doesn't seem right.

Other then this I think this is ready and an interdiff please. :)

gints.erglis’s picture

@jibran I agree with you, then we should move CSS to Classy instead Seven.

jibran’s picture

Issue tags: -Needs screenshots

I +1 that in #5. We need classy maintainer to sign this off.

davidhernandez’s picture

Gints, do you have an updated local install? I'm pretty sure we killed the shortcut star functionality when we converted page title to a block.

Something doesn't seem right here. That last patch is adding the library in Classy's info file which includes it globally, which we definitely don't want. This would be an administrative function, only available to people with edit shortcut ability. It is removing the library from shortcut module, but not modifying it's conditional inclusion. You'd have to us the alter to keep it working the same way.

However, I'm still not seeing the benefit of moving this to Classy. It's admin functionality with styling provided by the admin theme. Admin themes in all likelihood would want to style it differently, and provide their own icons, which is why I think we are considering its current styling a property of Seven.

The last submitted patch, 11: move_shortcut_theme_css_to-2566841-11.patch, failed testing.

gints.erglis’s picture

davidhernandez,

Gints, do you have an updated local install? I'm pretty sure we killed the shortcut star functionality when we converted page title to a block.

Yes, I have updated local install. The shortcut for frontend theme was enabled for testing Bartik. And there the idea comes from about including shortcut CSS globally for all Classy based themes.
Do you agree with declaring shortcut css as library in Seven theme, so other themes can include that library as needed?

gints.erglis’s picture

Shortcut library included only in Seven theme.

LewisNyman’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 19: move_shortcut_theme_css_to-2566841-19.patch, failed testing.

LewisNyman’s picture

@Gints Ērglis Yeah I think it makes sense to declare a separate library, but does it make sense to load a Seven library in Classy/Bartik? What happens if Seven is not enabled?

The last submitted patch, 19: move_shortcut_theme_css_to-2566841-19.patch, failed testing.

LewisNyman’s picture

I'm not very sure about the approach here, the approach discussed in #2566775: [Voltron patch] Move all remaining *.admin.theme.css to Seven was intended so other admin themes could control the look-and-feel of these frontend widgets. I am right in thinking that the above solution only allows Seven to modify the CSS? That would be a shame.

I think this is the wrong issue to discuss the general solution, we should be doing that in the meta: #2566775: [Voltron patch] Move all remaining *.admin.theme.css to Seven

Also, if we want to change the approach a day before RC lands, we are effectively postponing this work until 8.1 or 9.x. I don't think we have a perfect solution but it's the best we have right now...

Manjit.Singh’s picture

Version: 8.0.x-dev » 8.1.x-dev

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.