Split from #1775302: Do a UX review of Breakpoint module
Related to #1696302: [meta] Blocks/Layouts everywhere
Background: http://krisandju.e-webindustries.com/blog/drupal-8-blocks-layouts-everyw...
g.d.o.: http://groups.drupal.org/scotch

I created this issue so we can clarify how everything works together in the end, assuming all initiatives will make it to core. Apparently most people (including me) have problems understanding how everything will fit together.

This is what I understand from SCOTCH: page.tpl.php is going away and layouts are defined by core (php code, the layout module or something else).

In Drupal 7 the 'layout' is done inside the theme using mostly html and css, and it will be moved to Drupal core, so core is going to output html and css? So parts of theme.info and most tpl.php are going away and themers will need to write php code to be able to define layouts and regions? I would love feedback from themers on this.

from #1775302-27: Do a UX review of Breakpoint module about SCOTCH:
"The express goal of the blocks and layouts initiative is to make everything a little building block on the page (vs. custom things that there were before), with those building blocks much more flexibly configurable in themselves (eg. Kris is working on blocks instances so you can place the same block multiple times on the page with different configuration)."

Blocks need some love and I'm all in favor of doing this, but my main concern is the move from theme to core. As I understood is this was going to make blocks smarter (context, easier to create/duplicate, easier to extend, reuse) but apparently this also means that the whole rendering is changed. For the moment I don't see the need to change the theme part of the story.

"Building in a GUI to be able to put these pieces into a layout is a logical next step vs. just keep shipping core with hard-coded PHP developed layouts that are only modifiable to people who know PHP and CSS. That does not mean people who do want to have super-precise control should not be able to ignore any layout builder and do their own stuff hardcoding the layouts using the building blocks but stitching them together in code instead of a GUI. For those people, it should be easy to ignore whatever GUI we have for breakpoints, grids or layouts, they are just not part of the audience for this tool."

So themer need to learn how to build a new plugin in PHP to be able to add a region to their theme, and need to find a way to distribute it as well? Now (D7) the theme defines the regions and the layout so it's easy to distribute, but by changing this it means the theme isn't no longer responsible about the layout, but only about styling?

from #1775302-27: Do a UX review of Breakpoint module about the UI:
"Whether Drupal needs a GUI for this was proven by Panels (on 126000+ sites) and Context (on 69000+ sites) in contrib very well. Of course not everybody uses those, and whatever layout tool comes out , if it is included with core, it will not be mandatory either."

I checked some numbers:
Panels has 80,553 installs
Drupal 7 has 474,134 installs

So 17% of the installs use panels, 83% doesn't.

Disclaimers:

  • If I offended somebody in any way I apologize right away, I just want to clarify things.
  • I'll try to add some more information later today to clarify

Comments

attiks’s picture

attiks CreditAttribution: attiks commented

Feel free to rename this issue, title isn't probably reflecting what I'm trying to say.

attiks’s picture

attiks CreditAttribution: attiks commented

From #1775302-6: Do a UX review of Breakpoint module: "the spirit of the direction of layouts in core is moving which is that markup and layout CSS no longer resides in the theme but is now global to the site."
From #1775302-8: Do a UX review of Breakpoint module: "defining layouts is not at all in the responsibility of the theme"

Trying to understand this, using Bartik theme as an example

bartik.info will be changed to something like this?

name = Bartik
description = A flexible, recolorable theme with many regions and a responsive, mobile-first layout.
package = Core
version = VERSION
core = 8.x

- stylesheets[all][] = css/layout.css
stylesheets[all][] = css/style.css
stylesheets[all][] = css/colors.css
stylesheets[print][] = css/print.css

- regions[header] = Header
- regions[help] = Help
- regions[page_top] = Page top
- regions[page_bottom] = Page bottom
- regions[highlighted] = Highlighted

- regions[featured] = Featured
- regions[content] = Content
- regions[sidebar_first] = Sidebar first
- regions[sidebar_second] = Sidebar second

- regions[triptych_first] = Triptych first
- regions[triptych_middle] = Triptych middle
- regions[triptych_last] = Triptych last

- regions[footer_firstcolumn] = Footer first column
- regions[footer_secondcolumn] = Footer second column
- regions[footer_thirdcolumn] = Footer third column
- regions[footer_fourthcolumn] = Footer fourth column
- regions[footer] = Footer

settings[shortcut_module_link] = 0

Templates:
templates/page.tpl.php goes away and is replaced by a layout in code
What happens with templates/maintenance-page.tpl.php?
Is templates/node.tpl.php also being removed, as far as I understand it, it will?

CSS:
css/layout.css is removed and the css gets generated by core?
css/layout-rtl.css is removed and the css gets generated by core?

Please correct me where I'm wrong

EclipseGc’s picture

EclipseGc CreditAttribution: EclipseGc commented

OK, first let me thank you for making this issue. Implications of the initiative are very important and you've hit on some that I think a lot of people haven't managed to think through yet.

Second, you have a few errors here, so I'll just correct/clarify those first.

In Drupal 7 the 'layout' is done inside the theme using mostly html and css, and it will be moved to Drupal core, so core is going to output html and css? So parts of theme.info and most tpl.php are going away and themers will need to write php code to be able to define layouts and regions? I would love feedback from themers on this.

First let's discuss the layouts part of this. Layouts are intended to be a new plugin type. They should ultimately be rather painless in their implementation, and largely consist of what you might imagine an existing page.tpl.php file to be if you stripped out any notion of where the logo, menu, etc are going to display and all you had was html and either php or twig to identify the various regions in which blocks could reside. This is a 1 column layout plugin template in panels today, and we'd be striving to get as close to this sort of approach as possible, because it's super simple: http://drupalcode.org/project/panels.git/blob/refs/heads/7.x-3.x:/plugin...

Second, with regard to "most tpl.php are going away" I suppose that depends on how we define "most". If by most you mean that the vast majority of custom themed websites have a ridiculous number of page-some-naming-scheme.tpl.php files in them, then yes, most of those will go away assuming we succeed the way we want. If you mean we'll replace most of the tpl.php files in the system with layouts, that seems less likely to me. Things like node.tpl.php COULD potentially go away, but I think that's certainly not reasonable in our current time frame, and I think it's debatable as to whether or not it's even desirable.

So themer need to learn how to build a new plugin in PHP to be able to add a region to their theme, and need to find a way to distribute it as well? Now (D7) the theme defines the regions and the layout so it's easy to distribute, but by changing this it means the theme isn't no longer responsible about the layout, but only about styling?

So... in a word, no. Layout plugins should ultimately be distributable by the themes (and modules) so that you can choose how it is that you'd like to package and distribute these layouts. Off the top of my head, we'll likely enforce some sort of simple directory structure for this and expect a "layouts" directory in your theme, and then you can put subdirs there to segment your various assets for a layout (meta data, css, js, twig file). It's more an enforced organization for discovery purposes and should be relatively trivial for any themer to grasp. With regard to your statements about theme responsibility being primarily styling, I actually agree. The theme will be able to provide layout plugins, but they'll be available to any theme on the site so long as that theme is enabled. In this way, I expect an agreed upon standard of layouts to likely emerge (much like zen and a few other base themes have today) and for other themes to leverage those layouts and provide new styling for them. This does not preclude a theme from providing a layout though, so in reality what we're doing is really 2 fold.

First, we're giving themers the ability to provide multiple approved layouts for their theme, and the associated styling information for those layouts. Instead of having to build one master tpl file that has a ridiculous amount of logic in it to support their varied use cases, they should be able to switch layout usage through the UI. There are notions on how this could be done without the UI, but I think our best bet at this point is to just make those things possible in contrib and get it on the next cycle after the approach has had some time to mature.

Second, we're giving themers who don't want to write all their own layouts the ability to provide some rather simple style guidelines for existing layouts and leverage other people's work quickly. I truly hope to see libraries of robust layouts competing in the next cycle of drupal for themers styling expertise (kind of a css zen garden approach but for drupal and without the enforced strict adherence to a lock structure in the DOM).

Also, your bartik info file looks reasonable. We might ultimately decide to register layout plugin within it (just saying it's one way) to get themers more control over their directory naming scheme, but nothing is yet decided there. I'm just spitballing.

Hopefully this helped to explain some things?

Eclipse

attiks’s picture

attiks CreditAttribution: attiks commented

Thanks for clarifying, my head no longer hurts.

"They should ultimately be rather painless in their implementation, and largely consist of what you might imagine an existing page.tpl.php file to be if you stripped out any notion of where the logo, menu, etc are going to display and all you had was html and either php or twig to identify the various regions in which blocks could reside" Nice, so this is everything in blocks. EclipseGc++

"most tpl.php are going away" I meant node.tpl.php, thanks for clarifying

"Layout plugins should ultimately be distributable by the themes" ++

attiks’s picture

attiks CreditAttribution: attiks commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Version: 8.x-dev » 9.x-dev
Status: Active » Postponed

This issue doesn't really make sense anymore. It maybe should be closed, but at a minimum it's not relevant for D8. :)

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch as a volunteer commented
Status: Postponed » Closed (duplicate)

Blocks everywhere is done.

Layouts have other issues open. Closing as duplicate.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.