Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Goal
This issues serves as overview and should help to track progress towards a stable D8 release and discussion on what to keep and what to toss.
Top priorities
Removing Ruby dependencyRemoving sass-globbing but allowing it to be added back if needed.(we recommend using Ruby sass if you need globbing, the libsass alternatives are troublesomeAllow for libsass.
Remaining Tasks
These need issues if they don't have one linked:
Settings
Live reload: Replace with Browser Sync (partially done in HEAD)IE specific stylesheets: May be better to have these hacks in context in the sass files with HTML class prefixes?Breadcrumbs settings: How much of this functionality is needed? They are a OL list by default in D8.
Styles
.page-
and.section-
class prefixes
Discussion
Default Styles?
Should we remove some of our default styling to make it more basic?
Libraries
The convention from D8 is to build up libraries of JS/CSS assets and only attach them to the elements that need them.
Propose we follow suit and do this with any component styles we choose to implement (ie. tabs * messages)
Styles
- There are a bunch of #id being used, can these be removed?
Renamecomponents
tolibrary
andelements
tocomponents
to make some more sense?
Tools
SCSS or SASS syntax?
Staying with SASS syntax for launch.Grunt vs Gulp, should we upgrade to Gulp or remove Grunt?Staying with gulp for launch.
Current look of a Basic unpublished page:
Comment | File | Size | Author |
---|---|---|---|
#2 | Euismod_Jumentum_Ullamcorper___Site-Install_and_Slack.png | 132.52 KB | joelpittet |
Comments
Comment #2
joelpittetComment #3
joelpittetComment #4
Bojhan CreditAttribution: Bojhan as a volunteer commentedI thought the point of Basic is not to provide any styling for those standard elements.
Comment #5
joelpittetI think that's right, there are "elements" folder with some styles but they aren't loaded.
Tabs are the only ones that have some style but that may need to be paired down some too.
Was thinking using some bourbon to inline the breadcrumbs, and that's all.
Comment #6
leahtard CreditAttribution: leahtard at The Jibe commentedThanks for getting this started Joel! Here are some thoughts from me:
Looking forward to moving forward with this. I'll be pitching in wherever I can!
Cheers, Leah
Proposed Folder Structure
base
libraries (formerly components)
components (Formerly elements. Files just showing an example of syntax.)
nodes
layout
_config.sass
print.sass
style.sass (Only contains imports for folders above. All styles move to base folder.)
Comment #7
joelpittetGot the page/section classes working (a bit of a guess that it's as it should be, please check).
And Browser Sync is working as long as you have caching turned off.
Haven't sorted out how to clear the theme registry, or if we need to. I've got a crazy idea but it will have to be done in a module because I need an alter hook. But going to try to have the page/render cache clear itself with grunt + custom cache tag of the template name.
@leahtard got some of the sass folder structure changes which is great and that's starting to shape up better.
Any ideas on theme registry rebuild?
Comment #8
leahtard CreditAttribution: leahtard commentedHey Joel!
Section classes
I just pushed a small update. I noticed that a path like node/subpage/ would render a body class of "page-node/subpage". I added a str_replace so it would render as "page-node-subpage". This is how D7 Basic is currently being rendered.
Folder structure
I wouldn't mind any thoughts you, or anyone else, has on the new folder structure. I wanted something that worked well with: (1) The SMACSS folder structure and categorization in basic.libraries.yml, (2) Sass compiling with sass-globbing. (3) The ability to work with libraries.
Right now, we have two libraries in place for messages and tabs and I am not happy with how the files are just placed in the sass folder root. They make sense in the components folder but we obviously don't want them compiling to the global components.css. Don't know what is best here?
Theme registry rebuild
I can't say for sure, but I think was initially implemented to address D7 caching while developing your theme. So you wouldn't have to clear cache every time you wanted to see an update. With the new development mode for Twig, is this still needed?
Cheers, Leah
Comment #9
joelpittet@leahtard it seems if you put the site in 'dev mode' you don't need the clear cache but if you add new templates or rename them you will want to rebuild the registry. I'd really love if I could find a way we could turn that off/on through the theme or UI someplace.
Ideally we could clear cache and rebuild theme registry all within a drush script or something that could watch the theme for file changes. I think I'll open another issue for that.
Thanks for fixing the section class names!
RE: folder structure. Maybe an examples folder nested in components that's not globbed? or component_examples if you want to **/* it.?
Comment #11
joelpittetI've commented out the clear registry feature and added the equivelent code stub for it for D8. But it doesn't seem to be working:(
Comment #12
arkjoseph CreditAttribution: arkjoseph as a volunteer commentedFor those that enjoy GULP, Ive successfully transitioned to GULP from Grunt and will be posting a github link shortly.
Comment #13
arkjoseph CreditAttribution: arkjoseph as a volunteer commented@joelpittet - Is there a reason why base.sass does not contain a list of imports all in one file?
Current structure...
Proposed structure and slightly more DRY
base.sass ->
Comment #14
arkjoseph CreditAttribution: arkjoseph as a volunteer commented@leahtard - messaging.sass, print.sass, and tabs.sass.
Does it seem okay to put theme in sass/components/default/
Comment #15
arkjoseph CreditAttribution: arkjoseph as a volunteer commentedLooking into theme registry rebuild solution. if anyone has suggestions on how to implement within basic.theme it would be great.
Thanks!
Comment #16
joelpittet@arkjoseph I like that idea in #13 would you mind rolling a patch for that? @leahtard what do you think? I know that's how I do that setup usually.
re #14 print doesn't belong in components but messaging and tabs sure does. Not sure it needs to be in a sub folder.
Rebuild can be tricky, I was thinking of re-inventing that a bit.
We will likely be working on Basic on Friday 4pm PST at the Global Sprint Weekend and Saturday pacific time. Feel free to join us @arkjoseph. Likely going to jump on #drupal-pnw IRC channel.
Comment #17
leahtard CreditAttribution: leahtard at The Jibe commentedHey Guys!
This folder structure is a new approach for me as well. Historically, we compile everything to a single .css file. This was my attempt to use the SMACSS library/folder structure. Am I missing a better way to go about this?
The only reason I complied them to separate files what so we could let sass compile them to separate .css files. This allows us to then utilize the SMACSS structure in the library:
It's the same thing with messages.sass and tabs.sass. We are loading these through libraries to we actually want an individual .css file in the end:
I have definitely found it hard to wrap my head around this. We could do something with grunt that would move files around but then we are adding that as a dependancy.
I'm looking forward to polishing up the last little bits this weekend :)
Cheers, Leah
Comment #18
joelpittet@leahtard actually second thought your new approach seems better for the SMACSS to be aggregated by drupal.
There could be a better way to organize some stuff maybe but I'm in agreement that the D8 way is likely a good approach.
Comment #19
joelpittet@arkjoseph I use gulp too;) I'd like to make sure neither are a dependency for using Basic, but I personally wouldn't mind putting both starter files in Basic. As long as we can compile SASS without them both too.
I think the only thing that may cause a dependency lock would be autoprefixer implementation if we go with that.
If the other maintainers would prefer not to support both, I can understand that as well.
Comment #20
arkjoseph CreditAttribution: arkjoseph as a volunteer commentedJowelpittet, sounds good. Ill see about integrating both starter files as long as the maintainers believe its the right way to go. Although ill be happy to take on this task if its the desire.
With that being said, I think ill need some assistance with grunt as I was having some issues running grunt and globbing but ill post back later with the error.
Apart from that, let me know if theirs anything else I can help out with.
Comment #21
joelpittetLeah and I are the most active maintainers at the moment. We'll discuss bigger issues with the others but mostly we just take care of business;). And we'll all be at the sprint this weekend, I think, in the same office.
Use the non grunt way if it's giving you trouble but do share the troubles in another issue and maybe we can help.
Comment #22
johannez CreditAttribution: johannez as a volunteer commentedAfter a discussion at the coding sprint, we decided to not include the rebuild theme registry feature on every page load in Drupal 8.
Due to the current state of the caching system, we couldn't find a way to do this in the theme without clearing the whole cache and only rebuild the theme registry.
If somebody really depends on this feature for their development workflow and prefers this over "drush cr", we can look into moving this into a separate module where you have more powerful hooks/services available to you.
Comment #23
joelpittetUpdated priorities, thanks @johannez
Comment #24
joelpittetComment #25
joelpittetComment #27
joelpittetHasn't been touched in a while, closing