Problem/Motivation

For phase 1 of the consensus banana, we moved all classes from preprocess into the templates. In phase 2, we will copy those templates into the new Classy theme and strip the module version of each template of all unnecessary classes. This meta issue will serve as a place to discuss the process, how we'll group the changes, how we'll group the templates in Classy, and how we will determine what classes get stripped.

Proposed resolution

Copy the templates modified in phase 1 to Classy, and remove the classes from the original template. When done, all core templates should be free of unneeded classes. See Steps and Examples for specifics.

Use this Goggle doc to keep track of the templates and organize them. https://docs.google.com/spreadsheets/d/1vc79t_bwRfMryyo63BCbHblLpJZqRSa2...

Priorities

We want to focus on the templates that matter most. Admin templates, and rarely modified/used templates are low priority. Concentrate on the following:

#2349625: Copy block templates to Classy
#2349721: Copy node templates to Classy
#2349759: Copy system templates to Classy (The system issue has been broken up into a series of child issues.)
#2349775: Remove classes from Views templates
#2349715: Copy link templates to Classy
#2349687: Copy image templates to Classy
#2349683: Copy forum templates to Classy
#2349659: Copy comment templates to Classy

Remaining discussion

How should we group the changes into child issues?

Done. See sidebar for child issues. They are grouped by module.

How do we group the templates in Classy?

Done. They will be placed in module subdirectories of Classy's templates folder. For example, "templates/block/block.html.twig". There is an issue to discuss reorganizing after we are done. #2349559: [meta] Discuss the organization of subfolders in Classy

Do we move the hard-coded classes?

<div{{ attributes.addClass('aggregator-item') }}>
  {{ title_prefix }}
  <h3 class="feed-item-title">

Yes, we will treat these the same as the attribute classes. Remove them for the original template if they are not considered functional.

Do we copy more templates than just the ones touched in phase 1?

Copy all templates.

Steps and Examples

  1. Copy the templates listed in the issue to 'core/themes/classy/templates'.
  2. Remove any classes in the original template.
  • Determine if the class being removed affects functionality or styling in core. (Check everything. JS, etc, and not just CSS.)
  • Discuss in the issue whether the class is important enough to be left in the original template.

Ideally, we don't want core modules setting style rules, so we'll need to discuss solutions for problems that arise.

Examples

Below is the node.html.twig template. Currently, residing in core/modules/node/templates.

{%
  set classes = [
    'node',
    'node--type-' ~ node.bundle|clean_class,
    node.isPromoted() ? 'node--promoted',
    node.isSticky() ? 'node--sticky',
    not node.isPublished() ? 'node--unpublished',
    view_mode ? 'node--view-mode-' ~ view_mode|clean_class,
  ]
%}
<article{{ attributes.addClass(classes) }}>

  {{ title_prefix }}
  {% if not page %}
    <h2{{ title_attributes }}>
      <a href="{{ url }}" rel="bookmark">{{ label }}</a>
    </h2>
  {% endif %}
  {{ title_suffix }}

  {% if display_submitted %}
    <footer class="node__meta">
      {{ author_picture }}
      <div{{ author_attributes.addClass('node__submitted') }}>
        {% trans %}Submitted by {{ author_name|passthrough }} on {{ date|passthrough }}{% endtrans %}
        {{ metadata }}
      </div>
    </footer>
  {% endif %}

  <div{{ content_attributes.addClass('node__content') }}>
    {{ content|without('links') }}
  </div>

  {% if content.links %}
    <div class="node__links">
      {{ content.links }}
    </div>
  {% endif %}

</article>

Copy the template to core/themes/classy/templates. Then, remove the classes in the original template.

New original

<article{{ attributes }}>

  {{ title_prefix }}
  {% if not page %}
    <h2{{ title_attributes }}>
      <a href="{{ url }}" rel="bookmark">{{ label }}</a>
    </h2>
  {% endif %}
  {{ title_suffix }}

  {% if display_submitted %}
    <footer>
      {{ author_picture }}
      <div{{ author_attributes }}>
        {% trans %}Submitted by {{ author_name|passthrough }} on {{ date|passthrough }}{% endtrans %}
        {{ metadata }}
      </div>
    </footer>
  {% endif %}

  <div{{ content_attributes }}>
    {{ content|without('links') }}
  </div>

  {% if content.links %}
    <div>
      {{ content.links }}
    </div>
  {% endif %}

</article>
Files: 
CommentFileSizeAuthor
#39 image.jpg1.73 MBFabianx
#39 image.jpg1.65 MBFabianx

Comments

davidhernandez’s picture

Issue summary: View changes
mdrummond’s picture

In terms of which templates get moved into Classy, I think the first answer is every template that has classes, and the core/Stark version of that template will not. My guess is that this will be nearly all the templates, but maybe not every single one.

Once we have identified all the templates to move, I think we need to look at where that leaves us. Are there two or three templates we wouldn't need to move? Or fifteen? If there are just a couple, might be worth making sure every template is in Classy, as that would be awfully convenient for people. If there are a lot we wouldn't move, that may be more duplication than is worthwhile.

Other thing we need to clarify: with this phase, in addition to putting a copy of a template in Classy, we are also stripping out the classes of the core/Stark version of that template in this phase, right?

Within the templates folder, if there are no sub-folders it's going to be a pretty large number of templates. However I'm not sure that grouping by core module is the best way to simplify that. A slew of templates are in the system module, so I'm not sure that's a logical place for people to look for templates. One way to avoid bikeshedding organizational structure of the templates folder right now is to just focus on moving everything into the templates folder to start. After everything is in, it might be more clear if we need more organization and what a good way to organize that might be.

As for breaking this up, I suppose doing this by module is a good a method as any, with the caveat that system module has a ton of stuff. We may want to break that down further in case there is any debate as to which classes to remove from the core/Stark templates.

As far as which classes should be removed, I don't think that needs to have anything to do with what we did in the preprocess phase. We're having an Everything Must Go sale on classes. The few exceptions should be any classes that make admin tools like the toolbar and contextual links work. I don't think that themes based off of Classy should have to completely reinvent the wheel each time for how Drupal's key administrative functions operate.

davidhernandez’s picture

...I think the first answer is every template that has classes...

My question is what are we counting? Every template in core, including the ones we didn't touch in preprocess? Even if it just has a hard-coded class="blah" in the template somewhere?

Other thing we need to clarify: with this phase, in addition to putting a copy of a template in Classy, we are also stripping out the classes of the core/Stark version of that template in this phase, right?

Yes.

Within the templates folder, if there are no sub-folders it's going to be a pretty large number of templates

If we do intend to copy all templates in core, then absolutely. There is something like 150 template files.

As far as which classes should be removed, I don't think that needs to have anything to do with what we did in the preprocess phase. We're having an Everything Must Go sale on classes.

So, do people agree that if the core template has something like <h2 class="title">, that gets removed? Not just things that are being added through an attribute.

mdrummond’s picture

Yes, any template that has a class, whether it's hard-coded or in an attribute. Everything must go.

The point is to get us to two versions of markup. One with sensible classes and one with almost no classes (only those required for toolbar, contextual links, etc.).

tstoeckler’s picture

So since we have moved to doing

{% set classes ... %}

in all (most?) of the converted templates, it seems that it is only that part that is being removed from Stark, in other words, the two versions of a given template in Stark and in Classy will be completely identical except for the fact that one of them (the one in Classy) has the {% set classes ... %}. Is that correct?

If so, would it make sense to simply use Twig blocks to wrap the markup part of each template so that Classy could extend the Stark templates and just add the classes? That would reduce the amount of code duplication between the two. Of course, if the actual markup still should be modified in some cases that would still be possible due to the nature of Twig blocks.

I'm not really a themer, so feel free to tell me to STFU if this does not make any sense. I was just wondering about it and wanted to mention it.

davidhernandez’s picture

The set block is not the only thing being removed. Here is a small example from aggregator-list.

<div{{ attributes.addClass('aggregator-item') }}>
  {{ title_prefix }}
  <h3 class="feed-item-title">
    <a href="{{ url }}">{{ title }}</a>
  </h3>
  {{ title_suffix }}
  {{ content }}
</div>

This template will be copied to Classy. The version left in the core aggregator module will look like this:

<div{{ attributes }}>
  {{ title_prefix }}
  <h3>
    <a href="{{ url }}">{{ title }}</a>
  </h3>
  {{ title_suffix }}
  {{ content }}
</div>

There are many spots where these class assignments are scattered about. Some are added through a 'classes' variable added to the attribute, some directly on the attribute, some in multiple places in the template, some hard-coded. We thought about using Twig blocks at one point earlier in the process, but agreed it wouldn't work for most cases, and would add a layer of complexity that would make using/understanding the templates more difficult.

One of my concerns is something like this, the node edit form template:

<div class="layout-node-form clearfix">
  <div class="layout-region layout-region-node-main">
    {{ form|without('advanced', 'actions') }}
  </div>
  <div class="layout-region layout-region-node-secondary">
    {{ form.advanced }}
  </div>
  <div class="layout-region layout-region-node-footer">
    {{ form.actions }}
  </div>
</div>

If we remove all the classes from the template, aren't we eliminating any context for some of the sections, and left with just a series of empty wrapper divs?

davidhernandez’s picture

Issue summary: View changes

Adding the Google doc from phase 1. We can keep using it to organize stuff.

davidhernandez’s picture

I updated the template list in the Google doc. The count is 135 templates. If we included them all, break them up by module, (not including breaking up system,) we'd have 26 issues. Of that 15 would have only one or two templates.

Cottser’s picture

If we remove all the classes from the template, aren't we eliminating any context for some of the sections, and left with just a series of empty wrapper divs?

Yup, this is the biggest potential issue with removing classes wholesale in phase 2. I thought we had discussed that on the parent meta or phase 1 but I think it was all on Twig calls. It's kind of divitis vs. divitis with additional classes.

My general thought is that if we can get phase 2 done as quickly as possible in a straightforward way (whether we just remove the "set classes" and addClass usage or remove all classes wholesale) we can then churn through some "dream markup" (or dream markup lite) issues afterwards to strip down the Stark/core templates even further, now that we won't have to worry about Bartik/Seven for most of them. It's not really phase 3 but it's picking back up on the dreammarkup "initiative".

Edit: In other words, my suggestion is let's not worry about markup structure in phase 2.

jstoller’s picture

As I recall, back in Austin when we came up with this plan, Classy wasn't just about adding classes. Core templates were not supposed to add any classes, or markup, that wasn't absolutely required for their basic function. So all those wrapper divs should also go away in the core templates. They also would be added in Classy. The point was to make core output as minimal as humanly possible.

davidhernandez’s picture

Ok, so that is something that wasn't explicitly clear to me. That we would indeed strip the core templates of empty divs, and have markup that is essentially different from Classy.

This:

<div class="layout-node-form clearfix">
  <div class="layout-region layout-region-node-main">
    {{ form|without('advanced', 'actions') }}
  </div>
  <div class="layout-region layout-region-node-secondary">
    {{ form.advanced }}
  </div>
  <div class="layout-region layout-region-node-footer">
    {{ form.actions }}
  </div>
</div>

becoming this:

    {{ form|without('advanced', 'actions') }}
    {{ form.advanced }}
    {{ form.actions }}

This will create a lot of CSS problems with contextual links and other things. We can fix that, but I am concerned about that making phase 2 more complicated, and not getting done by RC1. I would propose then that we just remove the classes, but leave the divs and leave sorting out the markup cleanup for phase 3 dream markup follow up.

Reading back through #2289511: [meta] Results of Drupalcon Austin's Consensus Banana it does appear that everyone was onboard with copying ALL templates into Classy, so I think we can go ahead with that.

davidhernandez’s picture

I just talked to JohnAlbin and he agreed that it makes sense in this phase to remove the classes, but leave the empty divs. Then, we can follow up later (maybe not even in an phased approached) and do the dream markup cleanup thing. He also agreed that we should put all the templates into one folder right now and discuss organizing that folder when we are done.

davidhernandez’s picture

Issue summary: View changes
davidhernandez’s picture

Lauriii brought up something we forgot. We need to pay attentions to the tests. Many test are checking for the classes in output. Those should be web tests, which means they probably are using Bartik anyway, so they will probably still work. If they are not using Bartik they will need to be changed to Bartik or the test itself adjusted.

davidhernandez’s picture

I created the child issues. System is the only problem child. We'll have to discuss breaking it up, but I want to get something created.

Cottser’s picture

Heh, "problem child".

FWIW, most of the web tests use core (effectively Stark).

derheap’s picture

What do we do about id’s?

For example in taxonomy-term.html.twig an id is set for ever term:

<div id="taxonomy-term-{{ term.id }}"{{ attributes.addClass(classes)|without('id') }}>

If it is not neccessary for editing functionality (e.g. contextlinks) it is just a styling hook.
So I would prefer to remove them to.

mortendk’s picture

Yes we should remove id's as well & clean the mess up.

+1 on stripping classes out and leave the markup - then we can go all #dreammarkup on the individual templates later.

About the folder names, lets move em over & then we can later discuss what we wanna call em, module names are fine but i would like to bikesheed the system folder - cause its kinda a nightmare with all its templates, but lets do that as followups later

mortendk’s picture

May I suggest that we split each up into 2 different patches:

The first one where we copy over the template & strip out classes + ID's from core and keep them in classy

After that we then create a follow up where those that care about drupalcore markup can discuss what to put where - in that way we can get the basic of classy done without a bikesheed that have blocked all templates for months.

I think its the only way to get progress on classy - else we will end up in never ending discussions about which class to put where.

Fabianx’s picture

Agree with mortendk, lets do straight conversions first, then create more #dreammarkup.

derheap’s picture

+1 for straight conversions.

+1 for using the module names as folders in the templates folder.
So we match the structure of the template folder in classy to the structure in core.
Maybe later we can deside to split uo the system folder in some subfolders.
But that changes should be reflected in the templates folder in the system folder.

Fabianx’s picture

+1 to keeping things the exact same representation as in core currently.

mortendk’s picture

Were stumbling into issues with testing when we clean out stark completely for classes fx block.
So what do we do there ? - test up against classy instead (that would make sense) or whatta do we do ?

Cottser’s picture

I think we should be updating the tests.

davidhernandez’s picture

I'm seeing in the patches being worked on right now, people added the templates into subdirectories. I thought we agreed to put them all into the root of the templates folder in Classy?

mdrummond’s picture

I think one single folder with the templates is what we should aim for with this phase. System is such a dumping ground for random templates that grouping things by module is pretty unintuitive.

derheap’s picture

Ok, I give up on the folder structure for now.
Just shove them all in templates and make a bikeshading followup about the structure.

joelpittet’s picture

FTR I agree with @derheap about the folder structure. It helps enforce the association to where the folders would fall back to if they aren't there.

mortendk’s picture

one single folder with 147 templates in is gonna be a cluster for anybody to look at - so how about we just move em over and keeps them in the same name as the module that created the template's (i thought we agreed upon that here in Amsterdam ? ) then any other structure we can bikeshed that in the follow up, where the "what do we call stuff" also will take place?

@cottser - so update the test to use classy as a theme (how do i do that btw - rtfm?) - or do we add in data-attributes instead to keep it completely seperated ?

davidhernandez’s picture

We agreed not to put them in subfolders for now. I created #2349559: [meta] Discuss the organization of subfolders in Classy for that discussion, and to change the folder structure in a follow up. You're already starting to bikeshed. Just get the moves done first.

mortendk’s picture

about the test i created #2350823: Use the Classy theme in the Testing profile so we can use classy as the testing theme

mortendk’s picture

@david ok everything into classy/templates/ no subfolders no nothing

1 - 2 - 3 patch harder!

xjm’s picture

Priority: Normal » Major
lauriii’s picture

What about other attributes than classes? I can see patches around child issues where all attributes are being removed and for me that seems wrong since I thought classy is only about moving classes from modules to classy.

jstoller’s picture

@lauriii, don't let the name fool you. When we're done, any markup that isn't absolutely required for a module's basic functionality is supposed to be moved out of core and into Classy. It isn't just about classes.

webchick’s picture

Question, not sure if it's appropriate for this meta or should be moved somewhere else, but...

The issue summary lays out a plan for basically taking the existing templates that modules provide, copy/paste them into the Classy theme, then return back to the module-provided template and strip it down to bare tacks.

My question is: what are contrib modules supposed to do? Contrib obviously can't copy/paste its own templates into Classy, because that's hacking core. And core's Classy theme is not going to ship with e.g. themes/classy/flag.html.twig and themes/classy/og.html.twig and 15,000 other modules' twig files, because that would be insane. :) So presumably contrib modules would provide only the stripped-down version of their templates. But then how do you surface to themers that there are (for example: http://cgit.drupalcode.org/flag/tree/theme/flag.tpl.php) wrapper classes, convenience classes, etc?

davidhernandez’s picture

@lauriii, right now only classes and left over ids should be removed. No one should be removing the printing of the attribute itself if that is what you are seeing. Also, markup should not be changing. We are leaving markup changes for later.

@webchick, the choice of core/Classy should not really affect contrib modules. Classy is just providing templates a theme would normally inherit from core anyway. A module can still define its own Twig templates. We would prefer it only provide simple template files, and leave class assignment and big markup decisions to the themer, (it would be preferable to use data attributes instead of classes for things like JS) but as long as a template file is provided, it can be easily overridden by the theme. Also, if a contrib module really needs to add something to the attribute in a core or Classy template, it can still be done in preprocess.

webchick’s picture

So then it seems like we need a change record to explain to e.g. the Flag module maintainer how to port a "classy" template such as http://cgit.drupalcode.org/flag/tree/theme/flag.tpl.php to Drupal 8, in respect of this markup change. Otherwise, all of this effort will only hit about 10% of the problem, since most sites use 50+ contrib modules in addition to core. And since beta is when module developers who've been sitting on the fence start porting, the sooner that documentation exists, the more likely there won't need to be a massive clean-up effort after the fact in D8 contrib.

Fabianx’s picture

FileSize
1.65 MB
1.73 MB

@webchick Very good observation. We discussed this briefly in bof at Amsterdam and my stake was that core should support union folders:

E.g. Component=classy

Would search for templates/classy/x.html.twig first and then for templates/x.html.twig

That would solve a lot and would allow contrib to ship with both - if wanted, but would allow themers to make patches to contrib, while right now we would obviously split the crowd...

We also discussed a themers guide for module developers :-).

davidhernandez’s picture

We can add a change record when the first of the phase 2 changes go in. But, what we really need is good documentation with best practices, and lots of getting the word out. Documentation has been at the top of our collective lists, but we've been holding off on any kind of formal theming guide because so many things are changing. We have a Google hangout this week, so we should talk about it again.

mdrummond’s picture

To address webchick's concerns, my understanding was that we would still have the same attribute objects in the core templates, and that's how modules would pass in any necessary wrapper classes.

mdrummond’s picture

I think one point we maybe missed is that if there is CSS in core that is targeting the classes or (hopefully not but you never know) IDs, then that CSS should probably be moved to Classy as well, right? It doesn't make sense for core to output a bunch of CSS that never gets used.

davidhernandez’s picture

If there is styling coming from core that we can remove completely, we should. I would like to see us avoid putting any CSS in Classy at all. If there is CSS coming from core that Bartik or Seven are relying on, we should copy the styling to the themes themselves. I don't think we need Classy to dictate little bits of padding, margins, and such, just because core was doing it at some point.

Ultimately, though, I think we'll need to see some examples of what's hiding under the cobwebs to realize all the pros and cons.

LewisNyman’s picture

I can't speak for Bartik, but Seven is still going through a process of moving common administrative CSS out of modules, and turning them into reusable classes that can be used by core and contrib. I'm not really happy with the idea of inheriting all the junk CSS from every module in core. I still don't understand how this scale to contrib.

There is also styling that is functional. To move it into a theme would mean that functionality would break when using another theme. That's the definition of styling that lives in base.module.css

cilefen’s picture

@LewisNyman I think the idea is that the styling that is necessary for function remains in modules.

davidhernandez’s picture

Issue summary: View changes

Adding a note about checking JS. Everyone, please make sure to check every use case of a class before removing it from a template, not just CSS.

davidhernandez’s picture

Issue summary: View changes

Updating issue summary. Adding priorities.

davidhernandez’s picture

Issue summary: View changes
davidhernandez’s picture

Issue summary: View changes
davidhernandez’s picture

There are concerns about the idea of copying all the templates to Classy, including ones that don't require modification or are particularly relevant to themers (like the simpletest templates). I'll try to write up the pros and cons of both sides and we'll need to hash it out here to make sure we're all on the same page and on the right path.

alexpott’s picture

I think we have to recognise the difference between color and simpletest's templates which are backend UI and things like node, block and comment. If there is a use case for something being presented to not an administrative user (or developer) then yep let's put the template in classy and remove all the classes from the core implementation. But OTOH for super obvious cases like color and simpletest let's not. I would also argue that the views_ui sits with color and simpletest. But view templates should be copied to classy. Also note that not copying to classy does not prevent a theme that uses classy as base theme from overriding.

I think this strategy will allow us to focus on what is important for front-end developers and keep the maintenance burden low.

webchick’s picture

Right, #51 is more along my lines of thinking. I understand the desire for core developers not to have to arbitrarily decide on a template-by-template basis on whether to copy or not, and making the rule "So just copy all of them" addresses this concern. OTOH, I feel the absence of core developers making a decision here pushes the mental burden instead to themers themselves, who now need to be able to sift through 50+ templates in Classy to find the ~10 that matter in most themes. This is particularly difficult for those brand new to Drupal who, for example, don't know what a "node" is yet and how central it is to everything.

In #2349759-43: Copy system templates to Classy Alex said:

There are templates for the front- and back- end here. I think all the front-end templates should be copied and we should leave the back-end templates where they are. If we can't decide whether something is front or back then we should err on the side of copying.

That seems like a simple enough rule to satisfy the "not wanting to make arbitrary decisions" while at the same time getting a lot closer to "what 90%+ of themers will want."

Jeff Burnz’s picture

I see a couple of different perspectives and arguments being drawn here. I think these are worthy of a discussion.


#51 alexpott says:

I think we have to recognise the difference between color and simpletest's templates which are backend UI and things like node, block and comment.

I think we do recognise the difference, however is this (Classy theme) where we need mark this distinction? I think what you are saying here is that since most of the time a themer won't need simpletest template therefor we should not include this in Classy, and that since templates like node and comment are commonly required, those are OK to move to Classy.

I think that sounds like a reasonable argument, however it does draw a distinction between front end and back end with regards to theming, which is arbitrary and assumptive. Meaning that we can never know what a themer actually requires, we only make assumptions about such things. We don't know if the only job this particular themer will ever have in Drupal is to build their client an Admin theme.

There is a theme that wholesale copies every core template - Omega. I can take a pretty good guess why they did this - because not doing this makes dangerous assumptions and introduces an inconsistency in the theme system. What themers really want is a systematic approach that makes sense all the time, i.e. consistent. It is not surprising to me that the vastly experienced front end developers who built Omega made this decision, because that is precisely what we want.

So I have to disagree with you - I don't believe we can assume what is important to themers, the group is far too diverse, and when you make the arbitrary distinction between front and back end templates you can only do this by making assumptions about what is important for one this or that particular task.

I am not convinced Classy should be making this distinction, at least not along the lines of "front end" and "back end".

keep the maintenance burden low

Here you mean for Drupal maintainers. I think we know this is not a DRY approach already, we've worn that burden as a group and will continue to do so - because we recognise the benefits outweigh the costs. Its plausible that not moving a particular template is not a free lunch either, simply because we now must maintain two lists of templates - those that reside in Classy and the sub-set that do not. I would argue this is an additional burden for Drupal core template maintainers in itself, who must remember that such and such a template is hidden away in a core module somewhere.


#52 webchick says:

OTOH, I feel the absence of core developers making a decision here pushes the mental burden instead to themers themselves who now need to be able to sift through 50+ templates in Classy to find the ~10 that matter in most themes. This is particularly difficult for those brand new to Drupal who, for example, don't know what a "node" is yet and how central it is to everything.

Thats a lot of arguments in a few sentences but I think I can distill them down to one - discoverability.

I think what you are really driving at here is that by having all the templates in Classy we make it harder to discover what we need to find. Again I think that sounds like a reasonable argument, but I don't think that leaving templates out of Classy to reduce the list size is the necessary answer to that issue.

I agree that discoverability is an issue in itself, and we should discuss ways of making it better, such as using sub-directories in the templates folder, group template by module or other logical categorisations.

Simply leaving templates out (not moving them to Classy) does not solve the root problem of discoverability, for any group no matter what their experience level. In fact it could make it worse, by hiding required templates in core under the assumption they are seldom or not required. So for one group you actually make this harder (those that need that particular template). I already alluded to the idea that maintainers will need to know about those templates, as will anyone building an Admin theme that needs that template. Please note this is not an outrageous claim, its not every day work but in a way it is, because its about processes and consistent approaches.

The "new to Drupal" argument I think we need to particularly careful about. Many new themers are vastly experience front end developers, this stuff is a normal day at work. Also the system is the system, if you are going to theme Drupal you need to learn the system, and you want a systematic system. The English language is so hard to learn because at every step it has an exception to the rule. I would say Drupal is hard to learn because so often it has exceptions, or as I like to call them - inconsistencies.

So to sum up, sure discoverability is an issue, lets solve it, but do it in a way that does not add an inconsistency to the system.


Honestly I found this hard to write, because in many ways I do agree with both alexpott and webchick, however I am also deeply aware that we need to banish this idea that its OK to build in inconsistencies because of arbitrary arguments, such as making it easier for this or that group, or making assumptions about what is important. I would vastly prefer a system that is 100% consistent with itself, because no matter what task I have at my desk that day, I know how to solve it, even if it takes me a few seconds longer to scan a list of files.

mortendk’s picture

Rant on:
Themers are sick, tired & frustrated of having markup and or templates hidden from them cause somebody (who probably dont work with the themes) X amount of years ago (in d7 cause now somewhere between 5-8 years) thought it would be a good idea to shield the themer from the evilness of complicated code.
The end result is then that the themer now have to both battle Drupal and the frontend hell of markup,css & 200 different devices
/Rant
Sorry had to get it off my chest, but its what makes Drupal hard to work with, lets not repeat histories false assumptions of what a themer want.

BUT yes we can "accept" that a template like the simpeltest is not moved into classy, but unless theres an extremely good reason and that reason would be "No themer or frontend ever in the world of drupal would ever ever ever work with this template, or wanting to modify whatever we put into it now" if thats not the case it MUST go into classy.
We cant end up with yet again a system where its not clear where the stuff is. Yes there will be a ton of templates (that we will organize into little folders, to make it less scary the first time).

Just cause a template is used for the backend does not make it a template we dont wanna work with (we do want backend themes now dont we)

So Dear Developers give us all the templates - dont worry we will be allright, we wont break it - were grownups, and we have a fire extinguisher ;)

alexpott’s picture

As omega in D7 shows you can have all the templates already. But we have to remember that with contrib and custom front-end developers will have to look in the module directories anyway. So what makes core special? And is not inconsistent with contrib and custom to say look in the modules for their templates and in core everything will be in classy. The reality is this situation exists because of complexity. With custom, contrib and core and themes, modules and profiles we have an extremely complex system of deciding where to find stuff.

mortendk’s picture

First of all thats directly against what classy is about - and 2nd were talking about how core works outta the box for the themer, Im not saying stuff is not gonna be complicated, what i don't wanna see is that we now begin to hide away templates, cause we might think thats not gonna be a template that the themer wants to use. The idea with Classy was that it would be easy for the themer to find everything that he needs to build a theme.

If we begin to separate backend vs. frontend were also gonna say that the backend should not have new themes.
Lets not make that mistake, when you open up classy the first time you should have everything outta core that you need to make a kickass theme no matter if its frontend or backend.

I would like to see a list of the files that is an issue, besides of simpletest & maybe the ckeditor templates (which im still on the fence on, cause we wanna build kickass frontend architecture also for the backend) else its just the arbitrary discussion, which i do belive is a discussion we have had.

LewisNyman’s picture

I think the use case for administrative templates is much smaller than other templates, but it is still a use case. We have maintainers of contrib admin themes and we also have situations where you would need a custom admin theme on a project. What's the threshold for including a template in Classy? It feels a little inconsistent.

Classy is a core theme, so I don't think it's illogical to have all core templates in Classy, even if contrib templates are not.

I'm not against the idea of having a different rule for admin templates, especially because we are already encouraging module developers to add classes to their templates to take advantages of Seven's reuseable CSS components. I'm just skeptical that excluding a handful of templates really benefits all themers more than it hurts the minority that are looking for these files. If it ends up being half of the templates, then maybe that would be helpful for the majority of themers.

I think we can also improve findability of templates in Classy without removing them in #2349559: [meta] Discuss the organization of subfolders in Classy

mortendk’s picture

on the concern of classy theme that haves a ton of tempaltes in The template folder will get subfolders #2349559: [meta] Discuss the organization of subfolders in Classy

from a talk on irc with mr. alex pott i understand that issues are with these templates ?

  • views_ui
  • color
  • locale
  • language
  • simpletest
  • update
  • admin-*,
  • system-*,
  • status-*,
  • install-page
  • maintenance-task-list

did we miss anything - could we get all the bodies on the table :)

alexpott’s picture

just to re-iterate @mortendk's comment and my opinion. From a quick glance I would not copy views_ui, color, locale, language, simpletest, update, and the admin templates in system. The admin templates in system are (i think) admin-*, system-*, status-*, install-page and maintenance-task-list

Toolbar's template is the one where I sit on a fence - but considering that this is just one template and it does appear whilst using the front end I would err on the side of copying.

Cottser’s picture

We've talked about whether to copy identical templates or not at least a couple times on the Twig hangouts. At this time I'm not one of the main drivers behind the consensus banana so this is just from my perspective as one of the theme system component maintainers. I'll say up front that the main motivation behind my concerns is not around having to patch things twice in the core queues, it's actually theming experience (TX).

This is long, so I'm splitting this up into three main points, hopefully that's not too obnoxious :)

1. Why are we only striving to improve classy's TX?

I can definitely see the appeal of having all or most of the templates in one spot to start with. But what about core itself? The part that is a bit weird to me is that (I think) many of the people fighting for the idea of duplicating templates into classy are actually not in the "classy" camp at all, and would rather use the stripped down templates in core itself, which won't come all packaged up in a neat little folder. So that's a bit sad, why do the classy people get things so easy?

Related to this, I think it would be helpful to try and examine an idea that I'm (maybe mistakenly) picking up in the motivations behind this: "new people will use classy" - I'm not convinced of that at this time.

2. We have discovery tools to help find templates

If we're concerned about template discovery I'm of the opinion that currently twig_debug trumps any attempt at a consistent "copying" scheme, which as we've talked about on the calls and more recently on d.o, becomes inconsistent as soon as 1 contrib module with a template is installed or as soon as you extend from a contrib base theme that doesn't include every single core template within its templates folder. From my perspective just copying everything is less consistent than overriding templates only when needed - it breaks down quickly and gives us yet another exception to explain to newcomers.

3. Embrace the cascade

With our current theme system the overriding/cascade of templates needs to be learned sooner or later and to me it's not radically different than that other "cascade" themers need to know about: CSS.

If we start duplicating templates unnecessarily in the name of consistency or discoverability, to me it feels like we're just trying to delay the inevitable and deny how the template system actually works. And I can't help but think we'd be creating more inconsistencies in the process.

Jeff Burnz’s picture

Well, to illustrate the point that we can't easily differentiate based on arbitrary distinctions like admin/non-admin, front/back-end, I am using status-messages.twig.php in my D8 theme. So we have an exception to #58/#59. Its in contrib right now, so I will reiterate, you can't just demarcate along a blurred line what does and what does not meet a set of criteria.

My vote stays as "copy them all" and if we have an exception it must be exceptional, i.e. what morten suggests in #54, however we know this case doesn't exist :)

I would point out is that we have 3 very experienced Drupal front enders actually agreeing with each other. How rare is that!

alexpott’s picture

#61 my bad, status-messages.twig.php should be copied - I thought it was part of the status-report - it is not.

Jeff Burnz’s picture

The part that is a bit weird to me is that (I think) many of the people fighting for the idea of duplicating templates into classy are actually not in the "classy" camp at all

For me at least this is not true, I am using it. I have a specific set of reasons for doing this at this time, mainly because I see potential risk in not using Classy as I am generally distrustful of module contrib and how they often tend to rely very heavily on core markup and classes, particularly in JS, and this will create a deluge of issues in my queue if I do not use Classy.

With regards to #3, what inconsistencies do you think we'd be creating here, I'd like to hear what your thoughts are on that.

mortendk’s picture

The theming Experience will be truly magical with having all templates in one place (yes we have the debugging tools - one good dont remove another good thing), so now from core its extremely easy to "just copy the folder" and start my new theme - Its Theming <3 to the max. That will satisfy every themer that just wanna rely on "what core does" and change a little bit as they go along, without being caught up in the mess of finding templates.

Remember were trying to satisfy the "just gimme what core does" vs. the "i like to write 150 templates so i know exactly what goes on group" its 2 very different groups of people, that think & work with the themes in 2 very different ways.

Core needs to be clean clean (clean) - totally stripped for any assumption of markup or classes.
We cant again (as in all previous versions on drupal) build on a frontend architecture that is turning ancient within a year & then lock us self down into that.

The reason we wanna strip core complete out, is to make sure that nothing rely on core - So when i go and create "theme2020" then i can build it up on a markup & css that does exactly what I need, and not having to work around drupal.

Duplicate templates, if we happen to be so lucky that a template in core & classy dont have any markup or css (is there two or something that dont have that) is it worth not being consistent, just cause of 3 files (admitted i dont know the exact numbers)

We might not burn down the castle (...) if not add views-ui templates to classy, but only because its probably gonna take loads of time to completely clean it out, classy should have everything that core needs for any theming.

May i suggest that we get a list of templates that can be an issue - discuss them this week so we dont block all the patches ?

mortendk’s picture

Ladies, gentlemen, developers & themer's I created a google doc with a listing of all templates i could find today in my latest version of 8.

I have listed em all by modules & added comments where it could be argued that its a "admin" theme element.
TBH i only see simpletest to be a template that we dont wanna copy to classy

1. We wanna make it 100% clear that a template should be functional without markup (we use data-- for js selections right ... right ?) - thats why its in classy, our default markup system for all things drupal. A theme that wanna break out of whatever we wanted todo today in 2015 wont be bugged down by that in 2018.

2. There can be edge cases where we say "ok lets not use 400 hours on fixing views ui - its our UI for drupal & we are acknowlidging that it will be locked into our 2015 markup"

plase jump in and put colors & comments in - but please first read up on the concensus banana principles.

https://docs.google.com/spreadsheets/d/1EVpPXXOem1fId00YH62-nH0mqlp6Rutk...

cheers!

jstoller’s picture

I'm with @mortendk on this. An admin theme is still a theme. It may provide access to the back-end of Drupal, but it's still a front-end interface for the people using it and the same design principles still apply. Bartik and Seven are both sub-themes of Classy, so Classy should contain all the templates.

Looking at the spreadsheet I only see two templates I would consider leaving out of Classy: simpletest-result-summary.html.twig, and install-page.html.twig. Simpletest feels like a special case and a developer thing, and there seems to be a good case that the instal page template belongs in an installation profile.

When it comes to Views UI and any other edge cases, my inclination is to include the templates in Classy—even if they are identical to templates that are also in the module—just for the completeness of Classy as a reference tool. That approach seems most consistent with the consensus banana principles. Of course if time and resources allow, it might be good to go back and refactor the module templates to remove as much markup as is humanly possible.

When we established the consensus banana the goal was to remove all the markup and CSS from core modules that wasn't absolutely required for the module to work. We didn't say "just markup that impacts published content." We were targeting ALL markup. Our ideal was to have no display markup in the modules at all, if we could help it. Classy is the place for all the generally applicable defaults (a.k.a. the Zen theme approach), while special needs can go into the individual sub-themes.

davidhernandez’s picture

There is a lot to consider. I wanted to write out as much of it as possible so we are all on the same page and can discuss the current path as well as potential options for moving forward. To clarify, copying doesn't just mean get a template in Classy. The important point is that the templates in core are modified, with extra css and markup removed.

There are five potential paths that have been discussed at some point in the past:

1. Copy all templates

  • Makes finding and copying templates easier.
  • Avoids inconsistancy in which templates are copied. Anyone working on a core template will know there is a copy in Classy.
  • Will take the longest to complete.
  • Will continue to encounter problems with tests and other peculiarities.

2. Copy “front-end” templates

  • Fewer templates means a smaller Classy.
  • Classy concentrated on “more relevant” templates.
  • Likely faster to complete than copying all templates.
  • Fewer peculiarities.
  • Creates an odd, arbitrary distinction between front- and back-end.
  • Creates inconstancy as to which templates have been copied. (You’ll always have to check.)
  • Templates with classes and extra markup are still in core.

3. Copy only templates we modify. The decision to copy the template to Classy is based only on whether it will be modified. If there are no classes to remove or markup to change, the template isn’t copied.

  • Fewer templates.
  • Still ensures that all templates in core are clean.
  • No solid reasons for a template being there other than a legacy class existing.
  • Still encounter all the problems of copying all the templates, without having them all.
  • Would likely take just as long as copying them all.

4. Copy only a subset of templates that are identified as important. (Page, node, block, views, etc.) The key is not to think about what should be in Classy, but which templates are important to have “dream markup” in core.

  • Fewest number of templates.
  • Fewest problems.
  • Should be the fastest to complete.
  • The absolute most arbitrary in deciding what is or is not copied.
  • Leaves the most templates in core that have classes and won’t get “dream markup” attention, which undermines the main motivation for doing this.

5. Copy all templates, but only modify the core templates that require “dream markup”. I don’t think we’ve talked about this one much. This would copy everything to Classy for completion sake, but then leave templates, like in simpletest, unmodified.

  • Gives Classy completion.
  • Avoids fiddling with core templates that people are likely to ever care about, or have classes for good reason.
  • Leaves some core templates with classes.
  • We’ll still need to discuss which templates in core receive attention.

I also discussed with alexpott and webchick some issues with the current method of getting templates moved over. There are concerns with the breakup by module, especially the recent breakup of the system templates, which resulted in patches that did nothing more than copy one template file. Another big concern is getting Classy into a shippable state. Meaning Classy will have what it needs in place, even if some of the individual issues are not completed in time for RC. There are a few ways we can handle this, somewhat dictated by which result we are looking for from above.

1. Continue with the current plan.

  • Will take the longest.
  • Longest to get Classy in a shippable state.
  • At any given time during development Classy will only contain what is done.

2. Copy all templates that we intend to have in Classy in one patch.

  • Gets Classy in a shippable state immediately.
  • Avoids those single copy patches.
  • The individual issues we work on will mostly be dealing with the core templates.
  • If we fail to complete by RC, there may be confusion as to why some templates are in Classy but not fixed in core.

3. Copy all the templates that don’t require modification in one patch, leaving the others to still be worked on in their respective issues.

  • Does not get Classy into a shippable state, but gets it closer.
  • Avoids those single copy patches.
  • If we fail to complete by RC, there may be even more confusion as to why seemingly random templates are in Classy but not others.

I hope that lays out our options. Some I think are better than others.

In moving forward there are a few things I am concerned with, the biggest being the how much time we have to RC. In case anyone doesn’t realize, we need all of this to done by the first release candidate (RC.) Not just moving templates to Classy, but all of it. Getting Classy organized, working out the css and libraries, the dream markup follow ups, and everything else we want to do.

I feel like we have enough time to do it, but we leave ourselves very little room for QA. Yes, QA. The thing no one seems to care about. If we are done days before RC, I don’t see that as a success. We know bugs will be found, additional hurdles will appear, and we don’t have enough of this in place to have large numbers of people theming in the wild to discover how well this idea is working. I want to make sure we have plenty of time to make adjustments. I’d like, in a dream world, to be done by DrupalCon LA, and use our time there testing and concentrating on the actual themes and theming experience.

We also have to remind ourselves what we are aiming for; a theming experience that is easier for themers to use, and flexible enough to allow themers to stretch their creativity without jumping through technical hoops. We are certainly getting there. Phase 1 was the biggest part of that, because if we don’t get all of the templates in core “clean”, themers can still override them, add/remove classes, etc. If we don’t end up with perfection, we can at least ensure we end up with something a lot more awesome than it was.

I won’t claim to be the themer that Jeff, Morten, and Lewis are, and I don’t have a passionate attachment to this vision. I also disagree with some of the concerns Angie and Alex have brought up in the past, but I definitely won’t claim to have the same appreciation for the pressures and vastness of concerns that affect a core committer. But, if I can play a part in this, it is to make sure these two sides marry and we deliver a completed product. If all the features people want don’t make it in, we need to make sure the ones that do are fully done and done properly. To do so, at this late stage, we need to proceed very pragmatically.

So I’m fine proceeding with #2 from the top (concentrating on front-end templates) as it’s closer to having all templates, and satisfies many of the concerns of the committers. Concerns that I am not comfortable strenuously arguing against without evidence of how this new system will play out in the real world.

I, and others here, would probably be even more fine with it if alexpott and webchick are open to re-opening the “all templates” discussion if we get the front-end templates done with enough time to tackle the rest. I think people would appreciate knowing the door isn’t completely shut, if it’s later proven there is real value in having all the templates.

I’d also like clarification/confirmation whether those template changes can be included in future releases, if need be. (8.1, 8.2, etc.) I lot of people still have the mindset that if they don’t get everything in, it will be that way for another four years. If 8.0 gets us 80%, and we can get 100% six months later, that’s still good progress.

webchick’s picture

Thanks for the very thorough write-up, David. I can't speak for Alex or catch or Dries, but my personal opinion is:

- The amount of work left to do achieve the penultimate vision does indeed seem rather daunting. Agreed that "X weeks/months prior to RC" is the real deadline, if we're serious about making sure it's shippable.
- So figuring out a way to make a more modest and achievable "minimum viable version" seems like a decent strategy. +1.
- I don't hear anyone arguing against putting in front-end templates so that subset of templates feels like a good place to focus first, especially if themers are roughly in agreement that they're far more vexed by not being able to easily find html.tpl.php and field.tpl.php than simpletest-whatever-stupid-thing.tpl.php.
- I'm open to the idea of doing another check-in later on when all of the front-end templates are moved and "de-classified", and "dreamed," assuming we still have ample runway to RC, and assuming people outside of the consensus banana movement have tried it and given some user feedback indicating this is what they want. DrupalCon LA might be a great time to gather this sort of discussion, if you're looking for an interim goal deadline to help move things along.
- I'm a lot less sure about making these sorts of changes post-8.0.0, though. AFAIK the intent of Classy was to effectively be the base theme for everyone out there who is not Morten ;) and wants to write some CSS to do most of the work. What was discussed at #2135189: Proposal to manage the Drupal core release cycle was we need to preserve backwards-compatibility in later point releases. So if we're into a situation where developer X sub-themes classy for a custom theme for client Y on 8.0.0 (and then subsequently moves onto other projects so is no longer available to client Y), and client Y updates to 8.1.0 six months later and suddenly their theme breaks horribly because templates moved around, that's not really going to fly. We'd have to discuss the impact on end-users of doing this in later point releases, basically, and possibly look at other strategies that could retain BC while still making further improvements.

mortendk’s picture

1. "Copy all templates" - yes we shold do that. This is the right way :)

2. "frontend templates" I have made a spreadsheet for all the templates afaik theres about 20 templates that we "only" use for a theme from the editors perspective.
its not "backend" its adminstrators. This could be a RC-1 goal, im (almost) ok with doing this.
Still this will bite us hard later admin themes will end up depending on both classy & stark, would get messy :(

3. + 4 would make it worse & illogical simply to many wtf's

5. Copy all the templates, only clean out the ones that "in the real world for 80%" needs it for RC-1.
Im all for this as a compromise, its 1+2 - its effective the same as #1. We can then clean out core templates, and seven & bartik can then begin to work the way the should.
I cant see there should not be an issue with us cleaning up markup out of core templates in "stark" post RC-1, at that point is should be the same as cleaning up documentation, and those that would go apeshit about it, is the morten's of the world, and they can fix that stuff emself + they know that they are on thinner ice.

Theres a HUGE blocker that haunts us atm: #2409811: Kernel tests should explicitly install themes and we can't move the templates to classsy, before thats fixed :(

Drupal 2020 - Later release
Heres one of the (many) beauty's of classy: When we release Drupal 8.5 (in 2020), and considerable parts of core have changed (cause of "something"), we could then create "classy-eightdotfive", make it live along side of Classy.
Then we don't burn down 8.0-8.4.9999, they will still work with pure upgrading, but the new stuff in 8.5 would be new & fresh, making it possible for the frontend to move forward. Classy is not only about theme-moaning-over-drupal-core its true seperating markup from evil php.

davidhernandez’s picture

@webchick, I'm still a bit confused about the BC stuff. I originally assumed that BC will be maintained through all minor releases, but then I've seen discussions that said there will be breaking of BC. Will BC be rigidly maintained, or mostly rigid followed by a big asterisk?

Regarding your scenario, if someone is using Classy, BC should always be maintained. Classy's very existence is about compatibility. If in 8.0 we don't modify toolbar.html.twig, but we do in 8.1, the existing module version of the template will get copied to Classy. Anyone using Classy as a base will inherit the template from Classy's directory instead of from the Toolbar module. All they should need to do is clear cache. The difference will be for the Morten crowd. They will see the core/module version of the template change. It is up for debate how big a change people consider that, but it is a change. There may be visual difference that have to be adjusted for, but I don't think there would be anything that could cause white screens or something bad like that.

@mortendk, we won't be able to clean up any markup after RC1. Everything is frozen at that point.

webchick’s picture

"but then I've seen discussions that said there will be breaking of BC. "

Hm. Not that I'm aware of. There is a lot, LOT more details in #2135189: Proposal to manage the Drupal core release cycle but basically, in order to get the security team's buy-in on semver, we need to drop support for 8.0.x as soon as 8.1.0 is released. That means we need to provide the same level of compatibility between minor releases of D8 as we currently do in bug fix releases for D7. So while there might be some one-off reason to break BC to fix a nasty critical or something (we broke menu API between ~6.2 and ~6.3 for example to adjust for a security hole iirc), it'd be incredibly rare circumstances in which we'd do that, unless I missed something somewhere.

And yes, agreed that the "morten" markup in particular gets finalized at RC (and honestly, some variation of this "dream markup" initiative has been going on for at least three years, so I don't feel this is unreasonable at all). The end-user scenario I laid out in #68 is the same regardless if Classy or Stark were chosen as the base theme... you can't break a site in a stable release in a way that requires an end user to go digging around in code (unless absolutely necessary, such as the menu API security hole example). Agreed though that we can continue to improve markup with additional optional, turned-off-by-default themes or some other workaround to maintain BC.

Jeff Burnz’s picture

OK, can I clarify things for myself here. I see two emergent ideas with regards to BC, for me BC is a critical aspect of the whole Classy initiative.

1. Copy all templates to Classy, we do what we can dream markup wise until RC. Thereafter its locked in stone until?

2. Copy only what is changed dream markup wise, then if a template changes in core (post RC) we first move the template to Classy and core gets the change, not Classy.

Both these preserve BC for Classy - correct?
Mortens crowd absorbs the maintenance of chasing core - correct?

webchick’s picture

No. All markup freezes at RC. Any markup changes after RC, whether in core or in Classy, would be limited to critical issues only. Once 8.0.0 ships, themes built using either Stark or Classy as a base theme are expected not to break in later minor releases.

Post-8.0.0, we could explore some ways to introduce further markup improvements in a non-BC breaking way. The most straight-forward way would be additional, optional base themes.

mortendk’s picture

Dreammarkup clearification.
Just to make it clear, #dreammarkup is not just about "the markup" do use a <h2 class="foo"> vs. <h1 class="bar"> its the themer experience from templates debughin default markup etc. It was a way to make less php-geeky-developer-types-people (aka frontenders) gateway into the issueques & discuss what we needed in d8 (

The idea of having one (dream)markup that we write once and we then use for the next 5 years is fundamentally wrong - its life or death for frontenders to change markup. if we cant easy manipulate markup / css / js were basically stuck with dirty css tricks & both fighting Drupal & 10 browsers & 200 divices isnt fun.
So to state that we had "3 years to figure it out" makes little to no sense from a frontend persective - the markup changes constantly and in 3 days there will be a better way to write a form label so it works with X browser on Y.

Forward!
Again I would love to see and it would be really helpfull to see what templates it is that "we should not move to classy".
Im ok with making a (small) compromise on the simple-test & install templates - theres solid arguments for not moving them, anything else should be move moved to classy & so we can burn the core template to the ground with only the {{ vars }} inside of them ;)

we need to get em all moved over, so classy can get organized in folder structures etc & stark + bartik, can see whats up, and we dont end up having another test not using classy :)

@jeff i proudly take on chasing the dragons inside core

@webchick: so in a 8.1 release we would be able to fix markup right but not in 8.0.1

webchick’s picture

I'm really not sure how I keep being unclear here, but let me try once again. 8.1.0 is the same as 8.0.1. We can't break people's stuff in a stable release of Drupal 8. So, no. We do not touch markup that 8.0.0 ships with after RC (we can add new markup that won't affect existing themes, however). Again, unless we made some weird provision for markup code in some conversation at some sprint that I was not privvy to (in which case, please point me at documentation of this decision).

But if we did decide this, I worry about how to handle the scenario I laid out in #68, because it means some hapless end-user with no theming skills gets stuck trying to fix their theme in a minor version update of Drupal 8 when the markup changes out from under them and their CSS no longer works, as punishment for hiring a front-end developer who knows what they're doing.

davidhernandez’s picture

Yeah, if BC is strict we have to have everything in by RC1. Otherwise, wait until 9.x. If we made changes in the future we can assure Classy stays compatible, but the core templates would not, which appears to be a no-go.

The only alternative is the aforementioned Stark2 which could contain the core changes people want. It doesn't break BC, because it is a new feature. I'm not sure if that makes sense though. We'd have to think about it, and see how that fits in a long term strategy. There is no point to a Classy 2 with added templates, because the only point is modifying the core templates, which we can't do.

webchick’s picture

I'm definitely sympathetic to the desire to not be dealing with 2015 markup in 2019. I talked this over some with catch in IRC because I was genuinely confused why this BC policy was somehow new information to so many people. He said it ultimately depends on how we define an "API."

It sounds like you guys are defining Classy as the API (meaning, the thing that won't break in later point releases, and the "safe" option to sub-theme from if you are building a theme for a client that you don't anticipate working for in a year) but core markup as not the API (meaning you could continue to make changes to this in perpetuity). However, that feels a bit backwards. If anything, one would expect core's default markup to be the API that doesn't change much (just as core's public developer APIs don't break after release), and sub-themes themselves to continue to get updates throughout the life of Drupal 8. Like, I would expect us to add a disclaimer to Seven / Bartik that people shouldn't sub-theme from them because we want to continue to make improvements to them in later point releases.

That might mean core ships with an "Edgy" theme or something, that starts as nothing, but gradually gets more template overrides as markup evolves. But I'm struggling a bit to understand the use case here. I guess "you are building a theme for a company that employs front-end developers and has no problem with those people taking time away from solving business problems to chase core's markup every 6 months."

davidhernandez’s picture

I think the likely BC breaking scenario is people not wanting to scream at the same DIV they hate for four years, knowing it can't be changed. As opposed to wanting to re-envision all the core templates every six months.

The Edgy thing is weird to me, unless people do plan on re-envision the templates every six months. Otherwise, it will just end up with a couple templates here or there that have some slight markup change.

The ideal, really, is to get as much markup out of the core templates as possible. People want core to be more of a blank canvas. Then, we won't need to have most of these struggles in the future when the markup is very minimal. And Classy would continue its purpose of being legacy/starter base.

I don't know if I can argue that we should be allowed to break BC, as I'm sympathetic to the fact that some people we struggle to adapt, but we should be clear on the possibilities so we can plan accordingly. If it is off the table we need to make sure we don't leave out something critical thinking we might get into a later release.

webchick’s picture

I think the likely BC breaking scenario is people not wanting to scream at the same DIV they hate for four years, knowing it can't be changed. As opposed to wanting to re-envision all the core templates every six months.

Hm. Not sure I agree with that. At the end of the day, we're all building Drupal sites for users, and their needs should trump the needs of front-end developers, who are able to take care of themselves and have ample workarounds (custom base themes, etc.) if Drupal isn't doing what they need by default.

Also, I wasn't suggesting that all templates would change every 6 months; I meant that we only do a "minor" (feature) release of Drupal 8 every six months, so that's the increment at which core's markup could change and themes "in the wild" may need to be re-adjusted if we allowed further changes to markup post-RC.

So I think for now it's safe to assume core's default markup is an API, and it therefore follows the rules of all other APIs in core, in that it doesn't make BC-breaking changes post-RC, barring a critical issue. Which means you need to make all of core's markup the way you want it for 4+ years by RC1. Sorry if this is new information, but that's been my understanding at least since forever, and I remember particularly emphasizing it at the original "Consensus banana" talk in Austin.

davidhernandez’s picture

Hm. Not sure I agree with that. At the end of the day, we're all building Drupal sites for users, and their needs should trump the needs of front-end developers, who are able to take care of themselves and have ample workarounds (custom base themes, etc.) if Drupal isn't doing what they need by default.

I don't see us disagreeing. I was just saying the more wanted scenario is being able to "fix" things in markup occasional, not chase core every six months. Obviously, user needs are going to trump it. The BC convo started as question more than new information, so we can chuck that and proceed knowing everything will be frozen.

So I think the next steps are ... hmm other people get your thoughts in while I think of some clever, happy middle ground.

We do have a Twig call tomorrow (7am Eastern) so we'll probably hash it out.

jstoller’s picture

Based on what I’m hearing here, I would strongly recommend taking the following approach:

  1. Move ALL markup and CSS to Classy. Completely remove it from core modules. This can be done in one mega patch.
  2. Refactor Classy as much as is possible in the time allowed, with the goal of making it a nice clean base theme that has the sane defaults most people would expect/appreciate.
  3. If there is time and IF it is deemed generally important to all, add tiny bits of markup and/or CSS back to select core modules, just to support minimum viable functionality.

This recommendation is based on the following:

  1. The default Core themes (“front-end” and admin) are already based on Classy, so this change would have no impact on them.
  2. Most people creating custom themes who would want the kind of basic markup that now comes out of Core (or Zen) should likewise make their theme a sub-theme of Classy. There’s little reason not to. Core does it.
  3. The Mortens of the world will get exactly what they’re asking for: a completely blank slate. If you want to build a custom base theme from the ground up, then you’ll need to provide ALL the markup. And that’s OK! Some would even say it’s ideal! Especially since we’re making it drop-dead easy to copy over any templates from Classy that you don’t really want to deal with yourself, like Views UI. Or you can just duplicate Classy and hack away at it to get yourself started.
  4. We never have to worry about breaking backwards compatibility if we want to remove some long outdated markup from a core module, since there is no more markup in Core to remove. :-)
  5. We now have complete freedom to make sweeping theme changes in 8.x releases. With all display logic in its own little box, this now becomes an additive process. Classy will stay forever the same—a snapshot of front-end's past—while Drupal 8.1.0 brings us Classy 2, with everything we wished we could have done in the original Classy, and Drupal 8.5.0 brings us Classy 3, with the latest in HTML6 technology! All of this without ever breaking backwards compatibility. Down the road we could even release a Low-Class base theme for people who need some bare minimum markup, but not as much as what Classy is providing. The possibilities are endless!

In my mind, this seems to offer the best compromise between different use cases, with the least downside, and by far the best opportunities for future growth, all while maintaining BC. And it's the closest to what we agreed to with the Consensus Banana in Austin, which should not be taken lightly. There were a lot of people with a lot of different perspectives in that room and they all agreed.

Jeff Burnz’s picture

OK, long hard think about #67.

Have to agree with morten here, its #5 and probably method #2, and then we get on with this now, and use megapatches for things like blanket removal of set/addClass().

Quick question, is it feasible to remove everything from core templates other than the docblock?

alexpott’s picture

I just don't get why it has to be all the templates - the list of templates not to copy is:

./core/modules/color/templates/color-scheme-form.html.twig
./core/modules/views_ui/templates/views-ui-container.html.twig
./core/modules/views_ui/templates/views-ui-display-tab-bucket.html.twig
./core/modules/views_ui/templates/views-ui-display-tab-setting.html.twig
./core/modules/views_ui/templates/views-ui-expose-filter-form.html.twig
./core/modules/views_ui/templates/views-ui-rearrange-filter-form.html.twig
./core/modules/views_ui/templates/views-ui-style-plugin-table.html.twig
./core/modules/views_ui/templates/views-ui-view-info.html.twig
./core/modules/views_ui/templates/views-ui-view-preview-section.html.twig
./core/modules/locale/templates/locale-translation-last-check.html.twig
./core/modules/locale/templates/locale-translation-update-info.html.twig
./core/modules/language/templates/language-negotiation-configure-form.html.twig
./core/modules/simpletest/templates/simpletest-result-summary.html.twig
./core/modules/update/templates/update-last-check.html.twig
./core/modules/update/templates/update-project-status.html.twig
./core/modules/update/templates/update-report.html.twig
./core/modules/update/templates/update-version.html.twig
./core/modules/system/templates/admin-block-content.html.twig
./core/modules/system/templates/admin-block.html.twig
./core/modules/system/templates/admin-page.html.twig
./core/modules/system/templates/system-admin-index.html.twig
./core/modules/system/templates/system-config-form.html.twig
./core/modules/system/templates/system-themes-page.html.twig
./core/modules/system/templates/status-report.html.twig
./core/modules/system/templates/install-page.html.twig
./core/modules/system/templates/maintenance-task-list.html.twig

Apart from an admin theme does anyone have any reason to copy these templates? We can not make admin theming easy in Drupal 8 - it is an immensely complex subject and copying these templates to classy makes it harder rather than easier. There is not one comment on the issue that offers evidence to the contrary - most comments seem to be saying here is a rule "core should not have markup" and then based on that a deduction that, therefore, we have to copy all the templates to classy. Nothing acknowledges the reality that modules provide administration screens with javascript that depends on the markup. This is not going to change before release. Therefore the rule "core should not have markup" is false. And applying it will lead to problems.

We can achieve a more subtle version of the rule, "core should not have markup using classes that appears on the frontend".

And honestly, if anyone looks at that list of templates what is a front-end developer itching to override the first time they meet Drupal? Remember just because they are not in classy does not mean that a sub theme cannot override them - in fact seven does override a couple of them.

Jeff Burnz’s picture

#83

I can't speak for how others view this entire issue but this is my take on the underlying concepts driving the arguments.

The point is no markup in core is a pattern that many of us want to adopt, a best practice, a total separation from "core" - which amounts to variables available to templates, and "design" - the usage of and wrapping of those variables in markup.

The very moment a "core template" engages in the practice of manipulating a variable or adding markup and classes it becomes highly opinionated about what that should be, how it might work and what the output might look like. This is a violation of the best practice.

This is what allows me to ask outrageous questions like "is it feasible to remove everything but a docblock"? It is likley possible to do that in the scenario where all templates are in Classy, bar a few very minor exceptions, respectively. Note my question is driven in part by advocating for a DRY approach, least maintenance etc. Again, not crazy questions to be asked.

How hard an admin theme to build is not really relevant, nor about JS hooks, since Classy is Sevens base them and Classy provides those hooks, or Seven overrides a Classy template and provides more of its own, just like any other theme.

I think webchick said it quite well along the lines of Classy would become THE base theme for all themes, which is actually quite right, but still lets not loose sight of the fact that that is still not a highly relevant point. The pattern/best practice is what is at question here, a least that is how I see it.

davidhernandez’s picture

We ranted about this quite a bit in the twig call a few hours ago. We'll basically go back to my original suggestion to proceed with #2, and we'll just use Alex's suggested list of templates. There is no sense spending more time arguing over it right now. We have too many more important templates to work on, and need to prioritize. We can revisit what remains once we are done, and see if we have time to do more.

There is a question whether to continue making individual changes or copy all the templates needed in one mega patch. If we use a mega patch, we should probably organize the templates into folders at that time. We would also need to postpone the other issues, or at least proceed knowing the templates don't need to be copied. The problem with that is some patches will not pass tests until the Classy templates get copied.

mortendk’s picture

just to cleary the ranting concensus:

- We agreed upon move alle the other templates first & clean that up, and then if we had the time, to come back and clean the last bits up. Where views-ui & simpletest would be the very last templates, that should be cleaned up.
- seperating "admin templates" away from drupal cause of some obscure idea that they dont matter the same is planly wrong. The only reason we were not moving everything is simple cause of the fear of not having time, so classy & the css dont gets into good shape.

- Mega patch would be a bad idea & create another cluster, so as i recall it. We will continue to move one module at a time, starting with block & node and get them moved over.

webchick’s picture

My concern with continuing to go template-by-template is it's leading to arguments like this, which is just further stalling the initiative and making people really frustrated. It also leaves us open to the risk of getting to RC with templates half moved, half not, half converted to classless, half not, and basically a totally inconsistent experience for themers because whatever templates get done are the ones someone bothered to work on; not that they followed any specific logic or order to them.

The advantage of copying all/some discrete subset of the templates in one fell swoop is we're instantly in a "shippable" situation. Classy's now no worse off than HEAD. You lay out your vision at once, not piecemeal. Everyone understands that from Day X onward they need to make markup bug fixes in two places (and the benefits of why they're doing that). Module templates can continue to get classes removed on an as-we-get-to-it basis, and if we don't get to them all, oh well. It's still better than Drupal 7.

The disadvantage is it's a really nasty patch that's big and hard to reroll. It also requires re-rolling those patches that took special care to both copy the template and modify the original. I don't see these outweighing the advantages, personally.

So my recommendation (and we should get confirmation from alex and/or catch to see what they think) is to take the path that gets us to a shippable state now, which then affords you to time to spend on the dream markup you want to do. The "path of least resistance" in terms of a shippable state at this point is moving all front-end templates (which no one disagrees with) to Classy in whatever directory structure you think is best in patch #1, then getting those "upstream" templates done and dusted de-classifying-wise in per-template patches #2 - N, and then seeing where you're at respective to the critical queue countdown when that's done and see if you have time to make the case for admin templates as well.

emma.maria’s picture

I agree with the bulk moving over of key templates to get the theme acting like a usable theme asap. And then we can clean up core like we are doing now.

Two people have messaged me in the last few weeks on how they should theme real d8 projects right now and I have to say you can't use Classy as it is, it hardly contains anything, just copy all the templates you need to a custom theme or to Classy yourself and amend them yourselves.

It would be terrible to do all this discussion, arguing and feeling like we are achieving things when in reality at the end of it as we run out of time we achieve nothing.

Edit: Apologies for disagreeing with some frontenders. I just feel at this point we need to do what is most efficient with the time and team effort we have available to us right now.

mortendk’s picture

Dont get me wrong im perfectly ok with doing a mega patch, but we have seen that everything in the frontend is moving extremely slowly :(
So why would a mega patch do that faster, do we simply ignore the cleanup fase in core modules? and then fix that later, cause thats the core concept.

About not using classsy now... then people still dont understand what classy is (which maybe require me to write a loooong blogpost)
Classy is the default markup that drupal puts out - nothing more nothing less & at this moment

Jeff Burnz’s picture

#88 You can use Classy now, sort of, there is a critical bug that gets well in your hair though: #2414255: Subtheme template inheritance working in reverse order

davidhernandez’s picture

Adding on the what Morten and Jeff said. There is no reason not to use Classy now, if you want the sensible defaults. It inherits all the templates it needs. People are not going to see any difference in the future as templates are added.

I've been holding off on the megapatch because I'm concerned with how disruptive it can be. Right now there are only six child issues to worry about, each with their own collection of work to be done, so none of the them are one line patches. The system templates are the real issue, but going off of Alex's list, most of what is left have template changes to make. But for the mean time I've left the System issues postponed.

My concern with the mega is that we have to postpone everything and then reroll all the issues that are currently being worked on. Every time we change the process we loose momentum. I'm also worried about how much time we loose waiting to get the patch right and waiting to get it committed.

Adding to that is

Everyone understands that from Day X onward ...

when/how do we schedule that? Does that mean spending a week getting a megapatch right, and then waiting another week for a countdown when it can be committed because we need to notify everyone? We are in a postponed state during that time.

Jeff Burnz’s picture

I use classy, from my point of view, in terms of timing, "some time before RC" is good enough for me. This is compatible with how everything else works pretty much, to be honest this is rather trivial by comparison to many other changes over the past 6 months to 1 year its not a big deal for madcap themers going at this now and chasing head.

webchick’s picture

Assigned: Unassigned » alexpott

Does that mean spending a week getting a megapatch right, and then waiting another week for a countdown when it can be committed because we need to notify everyone?

No, it means that as soon as the megapatch made it in, we'd publish the change record + probably post to g.d.o/core to notify people more broadly. No need for scheduling anything.

I've said my piece, you've said yours, assigning to alexpott to provide some feedback.

webchick’s picture

Although... I have to say I'm curious about this discrepancy:

@emma.maria in #88:

Two people have messaged me in the last few weeks on how they should theme real d8 projects right now and I have to say you can't use Classy as it is, it hardly contains anything, just copy all the templates you need to a custom theme or to Classy yourself and amend them yourselves.

@davidhernandez in #91:

Adding on the what Morten and Jeff said. There is no reason not to use Classy now, if you want the sensible defaults. It inherits all the templates it needs. People are not going to see any difference in the future as templates are added.

Obviously, we need to fix #2414255: Subtheme template inheritance working in reverse order so leaving that aside... I don't understand how you actually can instruct a themer to use Classy right now because of the very problem we're discussing.

What you want is the ability to write documentation like this:

"To start a new theme in Drupal 8, simply add the line base theme: classy to your theme's .info.yml file. Choose any templates you wish to override from the core/themes/classy/templates folder and copy/paste them into your theme, then modify them there directly."

But right now, said documentation would read like this:

"To start a new theme in Drupal 8, add the line base theme: classy to your theme's .info.yml file. If you want to override a given piece of markup, grep carefully for the location of that template file. Some are in core/themes/classy, but they could also be in core/modules/foo. (There's no way of knowing, really; it all depends if someone got it it yet or not). Once you found the location of the proper template, copy/paste it into your theme, then modify it there directly."

I think we need to get out of that situation ASAP, because until we do, we're hampering the ability for this initiative to move forward by making getting started in theming in D8 much harder than it needs to be, and onboarding new front-enders is essential to completing the markup cleanup you want to do.

davidhernandez’s picture

I don't understand how you actually can instruct a themer to use Classy right now

Since it went in it is the thing that maintains compatibility. Nothing has changed about that, so I don't understand the confusion. From the beginning we've told people to use Classy as your base, even when it was empty, if you want the classful markup. You would have problems as a themer if you do it the other way, and don't use Classy. The core templates are changing, so templates you were inheriting yesterday have changed today. What doesn't change is what you inherit from Classy. Otherwise, you are chasing head. Morten's crowd is the one that is chasing.

Choose any templates you wish to override from the core/themes/classy/templates folder

Because of the prior conversation in this thread, this will never be correct. We aren't copying all the templates, so instructions are going to always say use Twig debug to make sure you find the right template for the exact piece of markup you want to override. Yeah, we'll get to the point where most of them are there, but now we have exceptions.

I'm not going to argue that a megapatch is some god awful thing. There are just concerns about constantly getting roadblocked and waiting around for yet another thing. Every time we do that people disappear and we have to get back up to speed again. We got the node templates in today. That wouldn't have happened if we postponed everything again. And block is currently RTBC. Outside of the System stuff, which is all postponed, there are only a few issues left, and they've all been active. So if we have to do a single copy, we need to do it pretty quickly start-to-finish, because everything freezes until it gets committed.

My only other thought is let the issues in progress continue, but copy all the System templates in one patch (no editing.) That would be 40-something templates, including page, html, field, menu, etc. It doesn't interfere with anything, since all the System stuff is postponed. We could also reorganized the templates currently in Classy into directories. The other issues in progress can continue, they just need to adjust the path they copy templates to, but they wouldn't have to stop.

lauriii’s picture

I've also been telling people that they should use Classy to not break their themes. Beside #2414255: Subtheme template inheritance working in reverse order it should be all right to use Classy. If you override template it will stay as overridden even after we've copied new templates into Classy. When working on a theme template is not located in Classy you would just have to know to copy the template from modules (located in core or contrib) but this is very similar to the way it worked in Drupal 7 when you had a base theme. So people should be aware of that all templates might not exist in your base theme. Especially because of contribs.

I don't have a very strong personal opinion whether we should fix it by creating a mega patch or work on smaller issues. On that I want to trust on Webchick and other more experienced people than me. What I saw in Classy pt 1. was that it was easy to get the things done when the flow is good and you have people working on it.

But what we've been experiencing during Classy pt. 2 isn't unique to this case. The bottle neck in our project is people doing reviews. In Classy pt. 2 reviewing a patch is way larger task than actually writing the patch and that's definitely one of the reasons why it's so hard to keep it going. I don't know whether this problem would be fixed by merging issues to one or not.

Cottser’s picture

I'd just like to say that I'm really happy to see the momentum here lately, RTBC's and commits :)

davidhernandez’s picture

@Cottser, yeah, I feel a lot better about things after this week. Morten, in particular, pushed a lot forward. Now that all the active child issues are done, I can make a patch to organize subfolders, and copy all the System templates. We'll still use the System grandchild issues to do the class cleanup, but we'll already have everything in place in Classy. Everybody wins! (except for Views :(((( )

mortendk’s picture

i can still go in with an axe & flamethrower and clean out core templates after mega patch right ;)
- cause thats on my bucket list. Lets get this first system hell over with, then we can set in an attack on views later on, when we have the css structure clean out & its clear to everybody why views also needs a solid amount of frontend love.
So when is megapatch coming ;)

davidhernandez’s picture

The remaining child issues have been committed. I added a patch to copy the slightly shorter list of system templates and re-organize the existing Classy templates to the System issue #2349759: Copy system templates to Classy.

davidhernandez’s picture

System templates were committed today. Except for Views, Classy now has all the templates agreed upon. I'll un-postpone the System child issues so people can work on declassifying the original templates. And now that everything is copied, we can start figuring out a game plan to tackle the CSS/libraries.

mortendk’s picture

i have restarted the discussion about how the templates should be organized in #2349559: [meta] Discuss the organization of subfolders in Classy first patch is up.

davidhernandez’s picture

Update: The Views copy just got committed, so Classy now has all the templates we agreed upon. We still need to remove classes from Views and some of the system templates. Regardless, Classy is now "shippable".

Cottser’s picture

Assigned: alexpott » Unassigned

:)

Manuel Garcia’s picture

mortendk’s picture

so we can officially close down banana part 2 ?

davidhernandez’s picture

Not yet. We still have a few system templates to finish.

davidhernandez’s picture

It looks like we only have three issue to complete. One last push?

cosmicdreams’s picture

which three?

davidhernandez’s picture

joelpittet’s picture

Issue tags: +rc target triage

tagged for morten;)

lauriii’s picture

Component: theme system » Classy theme

Adding to Davids and Mortens queue

xjm’s picture

Thanks for tagging this for rc target triage! To have committers consider it for inclusion in RC, we should add a statement to the issue summary of why we need to make this change during RC, including what happens if we do not make the change and what any disruptions from it are. We can add a section <h3>Why this should be an RC target</h3> to the summary.

kevinquillen’s picture

Sorry, I am coming into this a little late and trying to understand something.

I've also been telling people that they should use Classy to not break their themes.

So, what should contributed themes do that do not want to extend from Classy? Do we have to be redundant and set all classes and provide all templates that it does just to maintain expected behavior (block/field classes, etc)? If so, how many templates have to be provided in a contributed theme? Everything in Classy?

davidhernandez’s picture

If you do not extend Classy, you will be extended Stable by default (unless you set base theme: false.) Stable has a copy of all templates coming from core, with limited CSS classes and reduced div wrappers and such. You can use either one.

kevinquillen’s picture

Okay, so its extending stable unless explicitly told not to.

In my case, I have my own base theme, with subthemes generating from it. We were trying to figure out what happened to the classes.

davidhernandez’s picture

Yes, if you don't extend Classy most of those Classes go away, as well as the CSS that goes with them. If you want many of them back, you'll have to add them manually. If you are doing lots of that, I'd recommend just extending Classy.

kevinquillen’s picture

Can a base theme extend Classy that still has subthemes extending the original base theme (not Classy)?

So, Classy > contrib theme base > contrib theme subtheme?

davidhernandez’s picture

Yes, I don't think there is a coded limit to how many parent-child theme relationships you can chain together.

kevinquillen’s picture

Well then, that seems to work. I never knew you could chain them down like that. Thanks.

Jeff Burnz’s picture

@kevinquillen I copied all the Classy templates to my base theme. It was either that or unset all of Classy's CSS (I don't want it). Those templates won't change in D8 so it's safe to do this + I was overriding about half a dozen of them anyway.

xjm’s picture

Issue tags: -rc target triage

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

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should 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.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.