In #2348543: [meta] Consensus Banana Phase 2, transition templates to the Classy theme we agreed that admin template should not be copied to classy and in #2349559: [meta] Discuss the organization of subfolders in Classy we created an admin folder. Therefore we should remove it.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Unfrozen changes Unfrozen because it only changes templates
CommentFileSizeAuthor
#1 2448213.1.patch12.24 KBalexpott
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 88,061 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

alexpott’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
12.24 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 88,061 pass(es). View

Patch removes all the image style related styles from classy since theme image style creation is not in the 80% use case of classy and is definitely an admin task. It also removes the block-list template - this is a really poorly named template since it lists blocks in the admin interface. I've moved image-widget.html.twig to content-edit since this is a widget template and therefore used in content creation.

mortendk’s picture

Just to make it clear i have some opinions on this...

"hiding" away templates based on an assumption that they are not used by a themer and/or that its not usefull to change the markup / classes, is the mistake that have been made before in drupal and caused a lot of frustration.
when hiding templates we are not encouraging and making it super easy to make admin themes.

for me this is a big -1, and is not the way of the true banana ;)

alexpott’s picture

We have already agreed the principle of not copying the admin templates why are these few any different?

alexpott’s picture

@mortendk in the other issue you said:

The templates are not even connected besides of the module spits out the templates - modules are putting the same data structures out

Exactly how is image-style-preview.html.twig not only in existence because the image module creates image styles and uses image styles? We are not ready not for modules to not have admin templates - let's stop pretending we are, duplicating all the work for everyone to maintain and do it properly when we can.

And how can anyone argue that admin theming is anywhere near the 80% use case of themes? Give me the project specification where there is a requirement to theme to the image style creation form and I'll give you my extremely surprised look. Also, if someone is undertaking the task of creating an custom admin theme for a site then the location of the templates will not be their pain point. Please lets stop pretending it will be.

Yes it is worth maintaining the duplicate templates for anything that actually appears in the front end of site because all of this falls completely within the 80% use case of "I want to change how my site looks to my users and core should get out of my way". None of the templates being removed from classy by this patch falls into that category.

jstoller’s picture

In #2348543: [meta] Consensus Banana Phase 2, transition templates to the Classy theme we agreed that admin template should not be copied to classy...

That is not strictly true. We agreed to table moving a specific list of admin-oriented templates to Classy until some higher priority issues had been dealt with. It was always intended that we revisit the question of the remaining templates, time permitting.

We are not ready not for modules to not have admin templates...

Why not? I mean, really, what would the downside be? Bartik and Seven are both subthemes of Classy, so why can't all the default theme layer stuff live in Classy? That was the original goal of the Consensus Banana. We didn't want duplicate templates in the modules and in Classy. We wanted empty templates in the modules and sane default markup in Classy. Contrib admin themes can then follow Seven's lead and use Classy as a base theme, if they want most/all of that markup, or they can completely replace it with their own templates, copying liberally from Classy they wish. This would be no different than it is for so called front-end templates.

A benefit of this approach is that 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. 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!

alexpott’s picture

A benefit of this approach is that 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.

But we have not even managed to remove front end templates like node.html.twig from the node module. So as far as I can see we haven't got to the theme nirvana wrt to the most commonly changed templates in Drupal 8. And are we going to make a rule that Seven and Bartik should not be used as base themes so that they can move to Classy 2 or 3? Or are we going to get Bartik 2/3 and Seven 2/3 as well. All sounds extremely messy and unrealistic.

A module should not have unnecessary admin templates and we should definitely seek to minimise their use in core. We should ensure that admin templates are as simple as possible and are great examples for contrib.

jstoller’s picture

But we have not even managed to remove front end templates like node.html.twig from the node module.

And that is why we're waiting to move things like the views templates over. We need a little more time to clean up the templates that have already been moved. But that doesn't mean the others shouldn't eventually still be moved, time permitting, and it doesn't mean we should move back the templates that have already been moved to Classy.

And are we going to make a rule that Seven and Bartik should not be used as base themes so that they can move to Classy 2 or 3?

That's the general idea. We won't prevent people from using them as base themes, of course, but they are not intended to be base themes and the danger of doing so is supposed to be added to their documentation. Rather, they are usable default themes and good demonstrations of what can be built off of Classy. As I understand it, based on the previous discussions, moving Bartik and Seven to an updated Classy2 in a later 8.x release is completely within the rules. As long as we don't break the original Classy, we should be good.

Cottser’s picture

IMO much of this discussion is probably better suited to the banana phase 2 meta issue (or some of it even its own new issue) since it's really starting to get into some overarching and fundamental concepts. The idea of core having "no markup" also does not sound like banana to me but I have always been on the outskirts of banana even though I helped a fair amount with phase 1.

I would suggest that the admin theme creator audience would at least know how to use twig_debug HTML comments and I don't think these templates are hidden in any way, or as @alexpott put it:

Also, if someone is undertaking the task of creating an custom admin theme for a site then the location of the templates will not be their pain point. Please lets stop pretending it will be.


This patch is RTBC from my perspective, but I don't want to start a status war so I'm not setting it to RTBC. I'd rather us agree on a way forward :)

I'm a bit surprised that now that we have classy split out (or at least mostly), we aren't jumping into #1980004: [meta] Creating Dream Markup or similar? I'd much rather see time and effort going into those types of issues because markup is frozen once RC1 hits and at that point it will be too late.

On that note I'd like to mention a related anecdote: If the Twig team hadn't decided before DrupalCon Portland to narrow our focus from converting both theme_ functions and .tpl.php to only converting .tpl.php to .html.twig (#1757550-40: [Meta] Convert core theme functions to Twig templates) Twig would not be in core today, full stop. Yes, we still have 13 theme functions in core (#2348381: [META-0 theme functions left] Convert/refactor core theme functions), but we have Twig and I'm really glad that all of our hard work so far has paid off. So I would suggest that we set aside the admin template concerns for the time being and focus the banana/frontend efforts now on the big wins and on making the D8 frontend as awesome as we can in the increasingly small amount of time we have left.

davidhernandez’s picture

I agree with Cottser, and was about to draft something similar. Thanks for saving me some time. :)

I see little value in getting into what is currently a philosophical debate. We only have a few months before we are, hopefully, at RC. We need to use our time judiciously. There may be benefits to having admin templates in some use cases, and having everything organized in a perfect way, but we are way past the phase where we can play around. We don't have time for people to try things out, make adjustments, try new ideas. We have to aim for the most common use cases, and prioritize what is important for release.

This Banana work was always an intermediate step. The goals are dream markup, css refactoring, css/js separation, stylesheet handling, etc. Themers are going to care about these things, not whether the image-style-preview template is free of classes and there is a copy of it in Classy. I've always wanted us to get through the Banana phase as quickly as possible so we can work on these other things. Classy itself shouldn't be seen as the goal. It is the means to allow us to tackle some of these other problems, and the more time, and physical (and emotional) energy we spend dealing with this, the less we spend on those bigger wins.

mortendk’s picture

Status: Needs review » Reviewed & tested by the community

F*.. it lets move forward!
i am though taking a flamethrower to the templates in core and cleaning em up - so WHEN we create admin themes we dont get stuck in drupalism's, which im afraid were gonna end up doing when we dont do a forced cleanup :(
But thats also just up to us to clean up

But we got seperation js-, classname seperations on menu's etc thats way more important, so if this can keep drama level down a bit im game ;)

Bend not broken...

jstoller’s picture

I think my biggest concern is that, based on the rules as written, any markup in a module is static. Whatever is there in 8.0.0 will still be there in 8.5.9, years down the road, in order to maintain backwards compatibility. But history tells us this is bad. We don't want our display output frozen in time like that. Classy gives us a way out of this trap, allowing us to create a Classy2 while leaving the original Classy in place to maintain that backwards compatibility. So, if we're going exempt admin templates from moving to Classy and keep them locked away in their modules, then can we also exempt them from the backwards compatibility rules in future releases? If admin themes are these highly specialized things, with higher barriers to entry, that are only supposed to be created by elite front-end devs, then is it OK to occasionally brake contrib admin themes in a 8.x release and force these elite front-end devs to update there stuff?

  • catch committed 78d22bc on 8.0.x
    Issue #2448213 by alexpott: Remove admin templates from Classy
    
catch’s picture

Status: Reviewed & tested by the community » Fixed

I think it's more likely that we'll end up providing alternative admin interfaces than tweaking the markup slightly on the the image style admin page. Although also I don't think the image style admin page is one that's likely to be specifically overwritten by an admin theme. A lot of that still needs fleshing out in terms of how we handle semantic versioning in terms of markup changes.

Either way I agree focusing on the front end markup is much more important than this discussion, and we should keep things consistent in terms of classy until there's a general agreement to copy all admin templates over. I'd also want to see that those pages don't get completely broken without the additional markup in the templates.

Committed/pushed to 8.0.x, thanks!

Status: Fixed » Closed (fixed)

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