Suggested commit message

Issue #2566771 by Cottser, mortendk, jstoller, LewisNyman, mdrummond, Gints Ērglis, sqndr, Chernous_dn, Manjit.Singh, axe312, emma.maria, davidhernandez, lauriii, jaxxed, akalata: [Voltron patch] Move all remaining *.theme.css to Classy

Problem/Motivation

See: #2489460: [Meta] Move module.theme.css files to Classy or Seven

All these patches conflict with each other.

Proposed resolution

Roll all the remaining module -> Classy issues into one patch once they have been tested and RTBC:

Remaining tasks

Get all the above issues to RTBC
Postpone all issues
Create voltron patch

User interface changes

None for Classy/Bartik/Seven. Stark is more stark

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

Issue summary: View changes
LewisNyman’s picture

Issue summary: View changes
LewisNyman’s picture

Issue summary: View changes
RainbowArray’s picture

Dropbutton is used by Quick Edit, so should maybe go in Seven with the funky stuff so that it works on the front-end even on non-Classy themes.

LewisNyman’s picture

hmm, I have no idea how we can handle that, we have no way of specifying scope of CSS yet. Whichever CSS is loaded last would change all the dropbuttons on the page. I think I suggest a few ideas in #2195695: Admin UIs on the front-end are difficult to theme but nothing we can achieve in 8.0.0

davidhernandez’s picture

I'm not to sure about moving drop button. Some will argue that should still work in Stark. I don't necessarily disagree with that argument.

LewisNyman’s picture

It functionally works in stark without the theme CSS but because it doesn't have a background color the actions don't stand out. I assume if people choose Stark they are going to implement their own dropbutton implementation using bootstrap or something, so the less we load the better?

RainbowArray’s picture

All of the work we've done to make theming without Drupal's default classes getting in the way is undermined by this and related changes.

I would like to build themes off of core's clean markup, but if I have to reimplement all the front-end admin UI to do that, it is much less appealing.

I do not want to make the toolbar or the quick edit or the contextual links look different in a theme. I don't want to care about that at all. So anything that makes me think about that at all is a loss. I don't think I'm alone in this.

I just can't imagine there are that many people really wanting to start from scratch on admin UI for user-facing pages.

Manuel Garcia’s picture

I can perhaps see admin themes being happy about core not shipping frontend css for admin UI elements, other than that... not sure.

LewisNyman’s picture

davidhernandez’s picture

There is still taxonomy.theme.css to move, right?

LewisNyman’s picture

Issue summary: View changes

Yes good catch. I've added it to the issue summary.

akalata’s picture

Issue summary: View changes
Status: Active » Needs work

#2489580-29: Move taxonomy.theme.css to Starterkit Theme and/or Claro decided that taxonomy.theme.css is really admin css and should not be moved; all remaining Voltron pieces are ready to go!

akalata’s picture

Assigned: Unassigned » akalata
akalata’s picture

Assigned: akalata » Unassigned
Status: Needs work » Needs review
FileSize
28.69 KB
LewisNyman’s picture

Status: Needs review » Needs work

Thanks! This patch removes the files but it does not add the files into Classy. It's almost there, just be sure to git add the files.

akalata’s picture

Status: Needs work » Needs review
FileSize
50.09 KB

This patch definitely adds the new files, but has a bunch of whitespace errors that seem to be coming from the new/moved images? If I re-save the patch file in my editor, it removes those whitespace errors but gives me a corrupt file instead.

davidhernandez’s picture

I believe all the no new line stuff is fine on binary files. They're not code files. I think it just does that automatically for any file.

star-szr’s picture

Agreed with @davidhernandez that should be okay. Also adding the following to your .gitconfig will help a lot with making a smaller patch (detects renames):

[diff]
	renames = copies

That's one of the things on https://www.drupal.org/documentation/git/configure.

akalata’s picture

Thanks davidhernandez and Cottser!

Here's an updated, smaller patch. One thing I noticed -- file icons are being moved to themes/classy/images/icons, but the forum icon is only moving to themes/classy/icons. Not sure which is correct, but we should standardize.

LewisNyman’s picture

Issue summary: View changes

Added suggested commit message:
Issue #2566771 by Cottser, mortendk, jstoller, LewisNyman, mdrummond, Gints Ērglis, sqndr, Chernous_dn, Manjit.Singh, axe312, emma.maria, davidhernandez, lauriii, jaxxed, akalata: [Voltron patch] Move all remaining *.theme.css to Classy

LewisNyman’s picture

Status: Needs review » Needs work

@akalata It seems like we should move all the icons into image/icons. Setting back to needs work to fix that.

gints.erglis’s picture

Status: Needs work » Needs review
FileSize
19.48 KB
716 bytes

Forum icons moved into image/icons.

gints.erglis’s picture

Ignore the interdiff-22-25.txt or read it from the other end.

jaxxed’s picture

Status: Needs review » Reviewed & tested by the community

looks good to me.

- libraries are moved;
- hook is used to overload, and extend libraries in theme;
- icons are moved
- library_load is used in twig templates to load libraries.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 8.0.x. Thanks!

webchick’s picture

Saving credit.

star-szr’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.