Add a Stable base theme to core and make it the default if a base theme is not specified

+++ b/core/themes/stable/stable.info.yml
@@ -0,0 +1,7 @@
+description: 'Shelter from the Wild Wild West.'

Love the description.

Why are the libraries being moved to Classy?

Pair coding FTW!!

I still don't understand the "remove the BC layer later" argument. Aren't we talking about D9? When we start working on 9 we're going to want to update all the Classy templates, libraries, etc anyway.

Drupal 8 will have LTS release at some point. After that we are allowed to remove BC layers and that way break the BC.

1. +++ b/core/core.libraries.yml
   @@ -199,8 +199,6 @@ drupal.dropbutton:
   -    theme:
   -      misc/dropbutton/dropbutton.theme.css: {}
   

   Moving this seems out of scope for this issue?

2. +++ b/core/modules/system/tests/themes/test_wild_west/test_wild_west.info.yml
   @@ -0,0 +1,6 @@
   +description: This theme has been built by a crazy themer who wants to be wild and not use the Stable theme.
   

   Let's find a different word from crazy here.

3. +++ b/core/themes/classy/classy.theme
   similarity index 100%
   copy from core/misc/dropbutton/dropbutton.theme.css
   
   copy from core/misc/dropbutton/dropbutton.theme.css
   copy to core/themes/classy/css/system/dropbutton.theme.css
   
   similarity index 100%
   copy from core/modules/toolbar/js/toolbar.js
   
   copy from core/modules/toolbar/js/toolbar.js
   copy to core/themes/classy/js/toolbar/toolbar.js
   

   I don't understand why these changes are in this issue.

I guess that dropbutton is being moved to both stable and classy. But I'm not sure why that's in this issue.

I think it's worth considering setting the base theme of Classy to Stable.

Otherwise any BC layer protections we put into Stable may also need to be copied to Classy, except sometimes they won't, because Classy will often have its own copies of templates. So any issues that would need a Stable update will require a lot of manual evaluation to see if they need to be updated in Classy as well. Much better to make Classy depend on Stable, and then we won't need to worry about that hot mess.

This is an very interesting. Out of interest are there any cases we've seen during previous release cycles where we've been blocked from adding functionality due to the limitation of having to keep markup the same? It would be handy to evaluate those cases to see what kind of functionality or enhancements you would be missing out on if you chose to extend 'stable'.

Could an alternative be to keep all the templates in core stable, and provide markup enhancements in classy, acknowledging there will be markup changes between point releases? From a semantics perspective it makes more sense to me that a theme you are extending would evolve and change over time vs extending no theme at all. Could also be less disruptive for existing themes.

It would be handy to evaluate those cases to see what kind of functionality or enhancements you would be missing out on if you chose to extend 'stable'.

I think the idea here is that stable would block improvements to existing HTML+CSS. This includes simplifying existing CSS components, improving performance, etc. If a new feature was added (behind an experimental module) then Stable and Classy would also gain templates.

From a semantics perspective it makes more sense to me that a theme you are extending would evolve and change over time vs extending no theme at all.

It needs to be very clear that stable is stable mark up, no theme is not. There's still a lot of mark up and CSS in the default module output that we want to remove.

Yeah, I'm beginning to think maybe we need to rethink this. We have to jump through so many hoops to get this to work and trick core into tricking itself. Should we instead flip the scenario? Leave core alone and just add an experimental base theme to core? Anything we want to change, CSS, JS, templates, we move into the base theme. It is a lot easier to make the theme override core than have core change and make the theme put it back.

This at least puts the burden on the experimental base theme and not on core or people looking for stability. If CSS ordering changes slightly in the experimental theme, so what. If there is a slightly unexpected consequence for something we do, so what. You are using the wild west theme. Put that burden on the group that is best able to deal with it.

I don't see any difference from a BC perspective, because we have to maintain BC for any internal code we write anyway. And when we start working on 9, we just move what is in the experimental theme into core. I don't see the obsession with just deleting Stable. We have to do a lot of other things to remove the BC layer. This way at least all our changes are in one place and we can keep track of what we've been doing, and probably why.

If I were to name such a theme, I'd call it something like 'evolutionary' instead of 'experimental'. It clearly describes that things gradually change for the better and doesn't imply that things are potentially broken or untested.

Should we instead flip the scenario? Leave core alone and just add an experimental base theme to core? Anything we want to change, CSS, JS, templates, we move into the base theme. It is a lot easier to make the theme override core than have core change and make the theme put it back.

This does not solve the problem IMO. The aim here is to be able to continue to evolve Drupal's default mark up. That is the baseline that we want to strip bare so in the future we can build anything we want off of core, without any default output.

If we add a theme that continues to remove mark up and CSS, we are effectively putting mothership in core. There's no point in having an experimental theme in core. It might as well be contrib like mothership is now, it can evolve even faster there.

Yes, adding mothership into core is exactly the point. It sandboxes the changes. The problem is no matter what we do we have to maintain backwards compatibility, and maintain it for the largest percentage of our user base. The changes we make can only be seen by a smaller percentage of the user base, so what difference does it make where those changes live? If we try to make Stable work we are essentially creating the anti-mothership in core which it seems is a lot more difficult to make work. If we instead add a theme where the improvements happen, we can do everything in a Drupal way and it doesn't require any theme system funny business on the backend to make work.

We'd also have the advantage over a contrib theme of being able to do things you can't do in contrib. Instead of doing certain things in preprocess to say add a template variable, we can just add that directly in core. If there are core changes needed to make certain things work in the experimental theme, we can do them, as long as we maintain BC which we would have to do anyway. The whole problem isn't the changes, it's the BC.

I am not sure that I understand the problems of having a theme that adds stuff on top of core? Isn't this what we do already in Classy? Is there a good example of the code we would have to right to get stable working as we want that is really tricky?

If we can manage to keep core clean and add stuff in stable/classy that would be idea, because the whole idea behind stark->classy instead of stark->bleach is that it's easier to add stuff on top of a clean base rather than take stuff away. I'm thinking about a crazy hook where we have to modify render arrays to remove one class or div.

Adding stuff on top is the easy part. If we just want to change the page template, and that requires putting the old copy in Stable, that's no big deal. The problem is all the other things we have to account for.

For example, if someone extends a template:

{% extends "@block/block.html.twig" %}

If the block template changes, we have to do more than copy it to Stable. We have to make sure these extends and includes still return the same template as before, which has been moved to Stable. Even if we get that to work, which is really tricky, I don't know how we account for someone wanting to get the new block template from the block module. (Extend @block, no really, I mean the real one not the fake one.) Adding that same extends line would presumably return the Stable template. That would be a giant WTF.

The same goes for macros, which I just thought about, which are done with includes. If you use a core macro like from the menu template and then we change how the macro works, we need to provide the old one for you. This is serious funny business behind the scenes.

And that is just for templates. We have to do the same thing for libraries and assets. If you remove system.admin.css with stylesheets remove, and later we decide we want to split that file up into components, we have to make sure that removal line still removes all the individual components. Or system.admin.css gets moved to Stable and we make the stylesheets-remove recognize that file with a library alter, but how do we account for the CSS we added in system as separate files? Only enable the library if you aren't using Stable? I don't even know how that would work if you use core directly. I guess we have to check if you have base theme set to false and then conditionally add the library? This is a lot of complexity and unpredictability we are adding to what the api essentially produces. It all makes my head spin, and makes me think we are over-engineering when we could just do it the other way. And doing it the other way means using all the tools core provides, the way they were intended to be used, in a way that is a lot easier to understand for everyone.

Also, the biggest worry I have is that we're trying to do this right before release without enough time to let the idea digest and without much testing, and without realizing all the scenarios we aren't realizing yet. I just thought of the old template versus new template thing, for example. I don't want to see us collectively put our faces in our hands six months from now and go, "oh, what the fuck did we do?"

But if we reverse it, there seems like very little risk. We don't have to make changes to core, we don't need behind the scenes magic, and we don't have to care as much about the BC implications. If we make a breaking change in the experimental theme, too bad. Deal with it. You should only be using that if you know what you are doing. You are chasing the cutting edge of core. We have free range to do whatever we want with any breaking result. We can figure out what works, what doesn't, mistakes we make we can reverse later. I think it also gives us more justification to add other base themes. Say we do decide to add some kind of bootstrap base theme. That is a lot easier to do as its own thing than try to make core bootstrap compatible and undo all those changes in Stable. That gives us a lot more flexibility, with less risk, than constantly trying to reverse engineer core for BC every time we want to do something new.

Just thinking this though some more. The only way to account for the problem with extending the templates is to copy all templates to Stable. (which was one of the ideas from the Barcelona meeting) So the not copy all templates option I was hoping for seems undoable. If we did that we'd have to get everyone used to the pattern of always extending/copying/including/etc from Stable as the default for documentation and everything. We are otherwise making things very confusing. In the same vein we'd have to copy all libraries and assets to Stable as well. We can't tell anyone to extend @block or @system. Only extend @classy or @stable or shit will break.

(I'm working my self in circles)

I think we are in all or nothing territory. If we do Stable we have to put absolutely everything in core in it and make it work for release. Or we add an experimental theme that we don't have to deal with right now and can add to later.

Does anyone see a workable middle ground that is future proof?

That would also mean Classy would have to extend Stable. I don't think we are getting around that unless we copy everything to Classy as well which seems wasteful.

I'm really not trying to be negative here, but I'm seriously perplexed as to what this issue is really attempting to "solve".

Introducing a "stable base theme" in an attempt to fix the underlying issues and crux of the current "theme system" is almost laughable. This process, continuing to band-aid themes and the theme system in core, will almost certainly be doomed for failure (no matter really which direction is taken here) just due to the very nature of the existing cruft.

In fact, I find it rather amusing and quite sad that this community continues to focus or start very trivial issues when it comes to the "theme system" (class names, markup and css "perfection"). Theme BC breaks is really just a symptom of a much larger issue: a very, very broken/antiquated "theme system".

Core should not introduce something that:

1. Has not been tested/proven in real world use cases/workflows (e.g. that is what contrib is for). Sure things always sound good on paper, but real sites and real workflows often tell a different story. We shouldn't be adding theories to core, especially this close to an RC/stable release, no matter how "good it may sound".
2. Adds more complexity to an already complicated "theme system" without first attempting to actually fix the theme system in the first place.
3. Is marked as a "major task" when it has, in fact, always been an issue for themes (i.e. this is not a new problem).... let's be real, this is adding new functionality and is really a feature request.

I'm not saying that this is a "bad direction", but rather this needs some serious thought and practical use-case data behind it. As such, I'm moving this to 8.1.x (tempted to even say 9.x considering that this is actually a radical shift in how we approach themes, css, markup and JS) and marking it as a feature.

There's other ways to fix this problem, namely replacing the theme system with something that actually works in the first place. Shoving things in just so we can get around that pesky "BC" rule seems like a huge and massive RED FLAG.

P.S. I know this issue is a result of the meeting that was held, I was invited, but could not attend and would have brought all this up then.

I think there are better ways to respond to this issue than to call the work that's being done to get Drupal 8's front-end polished and ready "amusing", "sad", and "trivial."

There will be plenty of ways we will continue to evolve Drupal's theme system in D8 feature releases leading up to Drupal 9. The fact that more needs to be done in no way negates the incredibly good work that is being done. I completely disagree that the work that has been done to improve Drupal's default markup, CSS and JS is trivial That has been a continual hassle when theming Drupal sites, and the work that's being done is going a long way to make that better. I'd love to see further improvements down the line, like an OO rendering system that eliminates a lot of the mysteries involved with render arrays. For now, though, we can work to make tangible improvements.

We are making progress on cleanup work, but the concern has been, what do we do when the music stops, and most front-end assets are frozen? If we haven't finished the cleanup work on markup and CSS in particular, is there a way to continue to make improvements going forward?

I think in theory the Stable theme is a decent answer to that. If somebody likes Drupal theming to start with a fair amount of default classes (which are hopefully more sensible than before), then they can use Classy as a base theme, and we'll guarantee backwards compatibility for those who do so. However, if somebody wants to start from a clean base with only the few functional classes necessary for Drupal's admin tools (primarily), what then? If they use core's default markup and CSS, then we need to guarantee that markup and CSS stays pretty much the same to guarantee backwards compatibility. If instead we could use a Stable theme as our backwards compatibility layer, then we can continue to make improvements to the default markup and CSS in core.

It does seem like Stable may more challenging than expected. I think ideally Stable would start as a blank slate, with almost no templates and CSS. We would only move templates and CSS to Stable once they're actually needed, because we changed something in core. I think ideally Classy would also be based off Stable, so that we don't need to make BC changes to both Stable and Classy.

My understanding is that the two concerns for doing something like that are:

1) If we provide a CSS file in Stable, it may load in a different order than it would have in core, which could cause unintended side effects. That makes sense because theme CSS loads after module CSS by default (at least that's my understanding).

2) If we add a template to Stable, and it extends a template in core, or a template in core extends that template, will the @extends break? My memory was that we already did something so that extends takes into account which version of a template is loading, whether that is from the original module, a theme or a subtheme. If that's not the case, we have larger problems with extends.

My understanding is that the suggested solution to items 1 and 2 is to provide copies of all templates and CSS in core in Stable. That does seem like a fair amount of overhead. Again, though, I'm not sure if item 2 really is a problem.

I do think it's worth thinking about what we're actually getting out of the Stable layer. Yes, we could change markup and CSS in core, but to what end? I don't think it would be wise to base a theme on core markup if we're changing it regularly, unless you want to update your theme all the time. I also don't think you could remove the Stable theme prior to Drupal 9, as if we've made significant changes in core, then that would be a pretty big BC break. I suppose at some point you could say, well, now we're guaranteeing no BC breaks for core markup and CSS. Then it's a little confusing that core markup/CSS is stable, but so is the Stable theme, only with more problems.

It does seem that if what we really want is an even more more clean version of core front-end assets, then adding a Cleaner theme in 8.1 or 8.2 might be a simpler solution.

I do think we should keep this issue active for 8.0.x: the bits of this patch that define what happens if no base theme is defined seem worth keeping no matter if we add a Stable theme or not. I sort of think we might even want to define the default theme as Classy. That's more in line with how Drupal markup has worked in the past. I personally am a big fan of removing a lot of the default classes, but I do think that's the more advanced scenario for Drupal theming, and we should consider making the default something that works well for the 80% rather than the 20%.

Finally, while I think we shouldn't close this right now, I also think it makes sense to put the bulk of our efforts into finishing the last theme cleanup issues before RC1. I think there's a lot we can still accomplish if we can work together. I also think that means working together respectfully. I think it's awesome all the work people have been doing together. Let's keep that cooperative spirit going through the end of the time where we can make the biggest influence on Drupal 8's front end.

Yes, I believe it was agreed that this is a "try to figure out if there is something we can do before release" issue. We ultimately may not find a working solution, but we aren't punting the discussion or attempts. And to bolster what Marc said, literally laughing at people that are working very hard to find a solution to a problem that has plagued us for a long time is disrespectful and unproductive. We may not come up with a perfect answer, but there is no telling what we'll learn or come up with until we try. Even wrong paths are valuable in teaching us what direction not to take, and the more we push the system the more we learn about what needs addressing. Just discussing this problem forces us to understand the system better and the different ways the api may be leveraged.

Regarding #49-2, if someone extends a template and lets the theme system discover the correct template (from within the theme, up to the base theme, or on up to core,) I believe that process is working correctly and would pull the correct template. But using extends/include you can specify where to retrieve the template. If someone extends a core template directly, to maintain BC, we'd need to still provide the old version of the template. This particular scenario is poking holes in the Stable idea, since I don't think there is a way we can provide the old for those that want it and the new for those that want that instead. We need clear, predictable separation. We also have some similar problems with CSS. The ordering is one problem, but themes can also target assets directly with stylesheets-remove and library alter. So the problem of how to interpret the intention of the themer is the biggest problem in making any BC work right.

If a custom theme did stylesheet-remove: css/system.js.css then this would break if we moved this theme into Stable right? It would require stylesheet-remove: @stable/css/system.js.css

I don't think the generic removal lines even work any more. We had to change that a while back to specifying the exact location of the file or using a placeholder.

So either this:

stylesheets-remove:
  - core/modules/toolbar/css/toolbar.icons.theme.css

or this:

stylesheets-remove:
  - @toolbar/css/toolbar.icons.theme.css

In any case, the above methods work. So if at some point we change the toolbar CSS in this file, we'd have to move the file to Stable. But these remove lines are still pointing to the file in the toolbar module, and a new file in Stable gets loaded in the page because it isn't being removed. Also, if we renamed the file to toolbar.icons.css, the file being removed disappears and a new file starts showing up.

We have an even bigger problem if we try to continue splitting up the files into components. system.admin.css is on that list to be broken up. If an admin theme removed that file and then we split it up into ten separate files, how do we keep it working the same as before?

There's an issue somewhere to provide ids for files in libraries, which would help with that problem.

Even if we had ids though, it'd still be an issue if one file gets split into 3. I think we could look at providing aliasing within the library system, so that you specify the old file and an array of new files, and stylesheets_remove on the old file still works.

Alternatively we can state explicitly that the location of files in the filesystem is @internal and don't use stylesheets_remove unless you're prepared to update. We've said similar for hook_form_alter() already.

Just a note I'd originally wanted to do this with a module rather than a theme. That could help with css ordering, and templates could still move to the theme.

On triviality while individual markup changes might be small, something like a field template can have a large effect on page weight overall, which in turn affects bandwidth, dom size, rendering time. And it does that for every request to every Drupal site (that hasn't overridden the template).

Making the change directly in core means that people copying templates will copy the up to date one etc. so I think that's worth pursuing if we can.

I think we should copy everything to Stable, seems like whatever happens that will be less work than trying not to.

Just to note if Stable turns out to be very difficult to implement, we also just discussed documenting that anyone not using Classy or another base theme should copy core templates to their own theme as part of the theme creation process. That's still an option if this doesn't work out I think.

I think if the alternative to Stable not working is everybody needs to copy templates to their own theme, I think we're better off just copying all the templates (and css if necessary) to Stable. Templates hide in a remarkable number of places, and asking everybody who wants to use the clean markup that core provides to dig into all those nooks and crannies to copy everything manually seems wrong.

I really love what we've achieved in terms of cleaning up Drupal's markup, and providing an option for a clean base. Something like Stable makes a ton of sense as a way to make it easier and more reliable to achieve that.

Yes, copying things over means a little more work changing things in multiple places going forward, but it also gives us the freedom to continue to evolve core markup throughout the D8 cycle.

I'm all for a hangout to discuss this if necessary. Before we decide to do that, though, are there any strenuous objections to the "copy everything and be done with it" approach? If not, let's just do that. Time is short before RC1, would love for this to move forward.

If we do copy everything, we will need to decide if we do what we've done with Classy in terms of organizing templates into grouped folders. I think it's worthwhile being consistent with Classy, and a folder with a hundred some templates in it isn't very friendly, so I'd go for using the same grouping we use for Classy.

I'd also still suggest that we change Classy to use Stable as its base, to reduce maintenance on Classy going forward. Any thoughts on that particular change, catch (or anything else)?

Discussion from today's front-end hangout:
- Copy all templates, CSS, JS and library definitions into Stable
- Stable should be the default theme if no base theme is set (too big a change to switch that now)
- Classy should use Stable as a base theme to minimize maintenance

If we move everything to Stable, then there is nothing left in core to evolve and improve? I'm not sure what the benefit is. Why not just move everything we would want into Classy in the remaining time?

Replace move with copy. The same way Classy has copies of core templates, but core still has its templates.

Think of Stable as if we froze Drupal core's front-end assets in carbonite.

In Drupal 9, Boussh shows up, frees Stable from carbonite, except Stable wakes up refreshed because we've done lots of work behind the scenes to have everything fresh and cleaned up.

Or... something like that.

We still want to get everything we can done before RC1. Stable is just a really big boost so we can keep working behind the scenes after RC1.

I'm going to start working on copying all core templates, CSS and JS into Stable. Hopefully my next patch can be titled Attack of the Clones.

@catch

There's an issue somewhere to provide ids for files in libraries, which would help with that problem.

Do you know what issue that is?

@catch

There's an issue somewhere to provide ids for files in libraries, which would help with that problem.

Do you know what issue that is?

This adds all core templates to the Stable theme.

This fixes the use of @extends within Stable. Only one thing that needed fixing. I'll need to check all other core themes as well though.

This fixes the other usages of extends in other core themes and also sets Classy's base theme as Stable.

Corrected interdiff.

This adds in all the CSS and JS and adds the library definitions to Stable, including path changes in the libraries.

Passing this over to Cottser now, who is going to work on the libraries alter work so that Stable is replacing core's library definitions with Stable's definitions. Or at least that's how I understand it. Would be nice if the libraries override patch went in. Might make that part loads easier.

One thing I also wanted to do was add default blocks for the Stable theme in the standard profile in order to provide a more sensible starting point, and for there to be actual content on the page should somebody make Stable the default. So this does that. This is a mix of Stark's blocks with a few additions that seemed to make sense from Bartik, adjusting for which regions are available and such.

Also copied the logo and screenshot from Stark into Stable.

Added similar blocks to Classy in #2578429: Enable blocks in Classy.

Can now be rerolled with #2451411: Add libraries-override to themes' *.info.yml now in.

@Cottser, I assume it is ordering the assets based on how the theme would do it regardless of its original placement? It kind of makes sense now that the theme assets are intermingling. To correct for that maybe we need to adjust the weight of the assets or put them all in base category in their original implementation?

I haven't tried replacing a library with a library, but if you replace a specific CSS file it does put it in the exact same place.

See attached screenshot where I replaced toolbar.icons.css with blah.css.

I played with replacing a library with another. The dependancies were processed as they normally would be and ended up where they normally would. The CSS I added ended up where it normally would for a theme. Honestly, I can understand it working this way. Replacing one library with another can't work exactly the same way since you could be replacing anything with anything. I just replaced a library with several dependencies, javascript files, and multiple CSS files in different smacss categories by one CSS file. How would it determine what it is replacing and where it should go?

But it seems we could make this work asset by asset, which means Stable doesn't need libraries, just one giant libraries-override. Does that sound too daunting?

I think there's trouble with ThemeInitialization. getActiveThemeByName() is looking for base theme ancestors, and my guess is that it's getting thrown off because Stable is Classy's base theme, but it isn't declared. The default nature of Stable probably needs to be accounted for here and maybe elsewhere too.

Simple reroll now that #2348729: Convert theme_views_view_field to twig is in.

Checking if we explicitly define stable as the base theme for Classy if that fixes some of the test failures.

Also some of the test failures are due to checking for specific paths for JS and CSS files, which are different now that they are being loaded in Stable. So a few fixes for that.

Specifically declaring Stable as the base theme for Classy does not fix the errors at all.

Also, turns out if you forget to do git diff -C, the patch gets really really really big.

Change record drafted at https://www.drupal.org/node/2580687.

@mdrummond I changed the change notice a little to make it more scannable. Let me know if this is correct.

@Bojhan: Looks good. I made a few minor edits, but looks solid.

1. +++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
   @@ -282,6 +283,11 @@ public function rebuildThemeData() {
   +      if (empty($theme->info['base theme']) || $theme->info['engine'] != 'twig') {
   +        unset($theme->info['base theme']);
   +      }
   

   Should we be removing the base theme if it's not twig? That seems a bit extreme, other engines may have base theme support.

2. +++ b/core/themes/stable/stable.info.yml
   @@ -0,0 +1,7 @@
   +name: Stable
   +type: theme
   +description: 'Shelter from the Wild Wild West.'
   

   Sure hope we can hide these base themes or at least demote them somehow in the UI.

Based on IRC discussion, suggest we change the theme description to something like 'A default base theme using Drupal 8.0.0's core markup, CSS, and JavaScript.'

This makes it a little more clear as to why you might use Stable as a base theme.

1. +++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
   @@ -282,6 +283,11 @@ public function rebuildThemeData() {
   +      if (empty($theme->info['base theme']) || $theme->info['engine'] != 'twig') {
   

   I think we have to set the default only when theme engine is Twig. This logic seems wrong because it unsets base themes always when theme engine is not Twig

2. +++ b/core/modules/system/src/Tests/Theme/StableThemeTest.php
   @@ -0,0 +1,70 @@
   +  public static $modules = ['system'];
   

   Docs are missing.

3. +++ b/core/modules/system/src/Tests/Theme/StableThemeTest.php
   @@ -0,0 +1,70 @@
   +    $this->assertTrue(empty($base_themes), 'No base theme has been set.');
   

   Nit: This could be "No base theme has been set when theme has opted out of using stable"

4. +++ b/core/modules/system/src/Tests/Update/StableBaseThemeUpdateTest.php
   @@ -0,0 +1,54 @@
   +    $theme_handler->refreshInfo();
   

   We could explain here why this is necessary because it might seem wrong when first looking at this

+++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
@@ -282,6 +283,11 @@ public function rebuildThemeData() {
+      // Remove the default Stable base theme when 'base theme: false' is set in
+      // a theme .info.yml file or the Twig templating engine is not being used.
+      if (empty($theme->info['base theme']) || $theme->info['engine'] != 'twig') {
+        unset($theme->info['base theme']);
+      }

Actually I feel like removing this completely. I think this should remain the same by default for all engines. There shouldn't be technical limitation for using theme using other engine as base theme

This addresses points 1 and 3 in #115. Not entirely sure what I did for #1 is correct.

PIFR makes this looks much worse than it is due to rando AWS fails.

Looks to me like only two real fails. Trying to add base theme: false in case that helps, although I don't know if that's the real fix that's needed here.

Tested locally and passes as it did in #126. @Cottser's self review caught all the nitpicks. Concerns were addressed in #117 and fails #126

Reviewed the code and the tests and everything seems copacetic.

+++ b/core/modules/system/system.install
@@ -1808,5 +1808,18 @@ function system_update_8011() {
+}

Shouldn't info['base theme'] always be set to either something else, stable, or explicitly to FALSE? The isset() looks like it could hide errors.

Similarly, is the theme info guaranteed to be up to date here?

1. +++ b/core/lib/Drupal/Core/Extension/ThemeHandler.php
   @@ -282,6 +283,11 @@ public function rebuildThemeData() {
   +      // Remove the default Stable base theme when 'base theme: false' is set in
   +      // a theme .info.yml file.
   +      if (empty($theme->info['base theme'])) {
   +        unset($theme->info['base theme']);
   +      }
   

   Given we're dealing with Yaml here I think this should be === FALSE

2. +++ b/core/modules/system/system.module
   @@ -906,6 +906,11 @@ function system_get_info($type, $name = NULL) {
   +        // Remove the default Stable base theme when 'base theme: false' is set
   +        // in a theme .info.yml file.
   +        if ($type == 'theme' && empty($info[$shortname]['base theme'])) {
   +          unset($info[$shortname]['base theme']);
   +        }
   

   I'm not sure that this is necessary. Doesn't this come from the data built by rebuildThemeData()?

Looks to me as if the feedback from catch and alexpott has been addressed. For what it's worth, I manually tested using Stable as a default theme. That works fine. I also created a subtheme of Stable, Schmable, and that worked well too. So back to RTBC.

Oh, I forgot, the one thing that felt odd to me was that Stable doesn't have a screenshot or logo. So that looks broken. I think you could just copy over the screenshot and logo from Stark into Stable, and that would work just fine. Once that's in, I'll move this back to RTBC.

I checked, and a subtheme of Classy with no logo in the subtheme folder also has a broken image icon. So this is no different. No screenshot is not the end of the world either. If we really want to tackle that, it can be done in a follow-up. Let's get this in.

Ticking credit boxes for everyone who attended meeting in Barcelona to discuss the creation of this.

We should also credit: emma.maria, webchick and mortendk who were also present at the meeting in Barcelona.

It's gunna bug me if I don't ask. What exactly has been tested?

Thanks.

Commenting to help with credit. Thanks all!!

Patch looks great to me.

Observation with 'Stable' that I keep reading it as $table, this is not a problem except in issue titles - in context you can't possibly get confused.

Not committing just because I'm in the process of heading afk for a couple of hours.

Awesome, this looks like what we talked about. I think this is great because it gives front enders the choice between classful or classless markup, without coupling that choice with stability vs. wild west.

Well, not until we get everything copied over. I assume we are clear to do that post RC?

Yes, until RC, core markup can still change.

I'm saying after RC1 is released, which I assume is coming out tomorrow. This patch doesn't copy any of the templates or assets over. This isn't fully BC until that is done.

See #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS

Yes, sorry, I was agreeing with you. I meant "that's correct; we'll want to hold that patch until after RC, because up until RC markup can still change."

Committed/pushed to 8.0.x, thanks!

This needs a follow-up to copy the templates/CSS over - CNW until that follow-up is opened (but let's do two issues for git history).

Yep, that follow-up is filed at #2575737: Copy templates, CSS, and related assets to Stable and override core libraries' CSS.

Moving to fixed.

*puts my cowboy hat on*
... yes a very internal joke

Seriously this is awesome.

It's a bit unclear to me how Stark fits in the picture now that we have Stable ?

Also, Stark is the only core theme with a README.txt. If we now intend Stable and Classy to be the main base themes for actual uses by actual themes, we might want to make them at least as "inviting" as Stark by providing READMEs as well ?

Also, from Stark's .info.yml :
"An intentionally plain theme with no styling to demonstrate default Drupal’s HTML and CSS. Learn how to build a custom theme from Stark in the Theming Guide"

Maybe we should update that, if Stark is not really intended to be a base theme anymore ?

(according to this graph attributed to @mortendk at the end of https://www.lullabot.com/articles/a-tale-of-two-base-themes-in-drupal-8-..., stark is only there for our test suite now ?)

yched pretty much - stark is afaik dead, and is a leftover from D7
we should take the last step and remove it completely to make it clear for everybody

I thought stark remained as the way to see "naked" Drupal's markup, which will shift in 8.1, 8.2... whereas Classy/Stable won't?

@mortendk @webchick is correct, it's to see 'naked drupal core markup', though since we strongly discourage using Drupal core's markup directly (so we can change it). I'd suggest we use Stable to this end and relegate Stark to a test only theme. This will allow us to test core markup, and not encourage Stark's use.

I'd suggest we use Stable to this end and relegate Stark to a test only theme

Not sure how disruptive that would be at this point, but big +1, that would make the "base theme landscape" way clearer :-)

I'd suggest we use Stable to this end and relegate Stark to a test only theme

@joel & @webchick yup which means in reality stark is dead ;) long live stable

A stable component was recently added to the issue queue. Moving this issue there to make it easier to find. (I came looking for the back-story to stable.)