This is a tracking (meta) issue to organize issues around adding editable responsive layouts to Drupal 8 core. These modules have been actively worked on in contrib for both Drupal 7 and 8, so some are readily ported to Drupal 8 and needs reviews while others need more work.

First and foremost there is considerable abstraction work going on to introduce layouts as their own concept in Drupal 8 core. Some of the work is in core, but there is mo to do, see #1787634: [META] Decouple layouts from themes for the tracking issue for that.

The responsive layout builder was originally built for Spark in Drupal 7 contrib to be proposed for Drupal 8 core and is readily testable with a Panels integration in the Drupal 7 Spark distribution: http://drupal.org/project/spark (Drupal 8 versions also available with up to date patches and modules). The responsive layout builder consists of the following pieces:

  1. A module to manage a dynamic list of regions. This is needed because editable layouts support adding any number of regions naturally. This is implemented in the http://drupal.org/project/region module. Core patch for Drupal 8 inclusion at #1813910: Add region module to Drupal core (for editable responsive layouts)
  2. Breakpoints to be able to have different layouts for different presentation sizes. The Drupal 7 implementation for this was in http://drupal.org/project/layout and a temporary Drupal 8 implementation exists at http://drupal.org/project/bunnypoint, but a much more mature breakpoint API module is in core now (#1734642: Move breakpoint module into core). The layouts and grids depend on this now.
  3. Grids to serve as snapping guides for easier and best practice layout creation. Grids are individually created but can be assigned to breakpoints so that layouts can relate region placement to the grid columns for each breakpoint. The existing Drupal 7/8 implementation for this is in http://drupal.org/project/gridbuilder. Issue to add into core at #1816650: Add swappable (dynamic) grid systems to core
  4. Responsive layouts themselves, which relate a list of ordered regions to grid columns for each breakpoint applicable to the layout. This is the most extensive user interface element proposed and would map into the standard set of layouts as recognized by the core layout system. See #1787846: Themes should declare their layouts and its related changelogs for more details. Issue proposing addition of responsive layout builder in core: #1822950: Add responsive layout builder to core

Comments

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Issue summary: View changes

Add regions patch reference

Gábor Hojtsy’s picture

Integrated gridbuilder and layout for Drupal 8 with core breakpoints in http://drupalcode.org/project/gridbuilder.git/commitdiff/fa2748a329ff5d0... and http://drupalcode.org/project/layout.git/commitdiff/938b906b3490fe09a71c... (no issues opened for them).

Gábor Hojtsy’s picture

Issue summary: View changes

Remove reference to issues that were never opened :D

Gábor Hojtsy’s picture

I've added #1816650: Add swappable (dynamic) grid systems to core for grids which is getting some lively discussion.

Gábor Hojtsy’s picture

Submitted #1822950: Add responsive layout builder to core for responsive layouts.

Gábor Hojtsy’s picture

Issue summary: View changes

add gridbuilder issue

Gábor Hojtsy’s picture

To play around with the current state of layouts apply these patches and click the region list, page library and responsive layout editor:

; Layout module bugfix
projects[drupal][patch][1822998] = http://drupal.org/files/set-theme-for-layout.patch
; Regions module
projects[drupal][patch][1813910] = http://drupal.org/files/region-module-7.patch
; Page library
projects[drupal][patch][1787942] = http://drupal.org/files/pages-28.patch
; Grid support
projects[drupal][patch][1816650] = http://drupal.org/files/grids-in-core-18.patch
; Responsive layout module
projects[drupal][patch][1822950] = http://drupal.org/files/rlayout-1.patch

I just updated the Drupal 8 version of the Spark distribution as well, once/if it is rebuilt, it should reflect all this functionality as well.

Shyamala’s picture

Issue tags: +Responsive Design
Gábor Hojtsy’s picture

Status: Active » Postponed

Well, anyway, due to core things not happening below this layer that we wanted to build on, we just need to go and focus on those things and will pretty likely not have a responsive layout builder (and therefore any of the proposed modules from it) in core. Unless someone comes and want to run with all these.

Gábor Hojtsy’s picture

BTW help with the underlying issues at #1787634: [META] Decouple layouts from themes so we can implement this in contrib at least.

chx’s picture

Did you check that this can't happen with catch/Dries?

Gábor Hojtsy’s picture

Dries is the product owner for these issues, yes. Within the Spark team there are multiple other issues that were contentious and more important to get in, such as toolbar, wysiwyg and in place editing. The layout capability was/is the last in terms of priority among these. And on top of that, the underlying display/block placement infrastructure is not there to support this and based on the parallel progress there so far, that set of issues need more help (#1787634: [META] Decouple layouts from themes) and would not be complete without our involvement. Finally, there have both been minimal feedback on the responsive layout builder sub-issues linked from above and we consider the region module, grids and the responsive layout builder to be features and not "refactoring of already present functionality", so we think these are subject to the December 1st feature freeze.

Gábor Hojtsy’s picture

Version: 8.x-dev » 9.x-dev
Status: Postponed » Needs work

Given feature freeze yesterday, this is clearly not going to be in Drupal 8. Watch http://drupal.org/project/layout (or more precisely the renamed version) for Drupal 8 if that appears. Moving this one and the following issues to Drupal 9:

- #1813910: Add region module to Drupal core (for editable responsive layouts)
- #1816650: Add swappable (dynamic) grid systems to core
- #1822950: Add responsive layout builder to core
- #1787942: Allow assigning layouts to pages

Gábor Hojtsy’s picture

Issue summary: View changes

Add responsive layout issue

philsward’s picture

I really, really hope this is targeted for 8.1.0

I'm a site builder and hate dealing with responsive on D7 because of the lack of consistency of how each theme framework deals with responsive layout.

When responsive began hitting the D7 scene, not much was known about it and the only solution was for each theme maintainer to do the best of their abilities to create a responsive theme/framework. The concept is all the same but the way it is handled is completely different, even between various bootstrap forks. Very frustrating.

What I truly believe needs to happen, is for Drupal to generate the entire responsive grid system to allow themes to do what they need to do: wrap it in a pretty bow.

I was excited for the spark initiative for this, but sorely disappointed it missed D8. I understand why, but looking at the future of Drupal, when D8 launches, theme frameworks are again going to pop up out of the woodworks, doing things however they see fit instead of following a common set of pre-generated guidelines. It's hard enough trying to learn and master the plethera of awesome Drupal modules. Learning a "hacked together" theme framework can have a higher learning curve than learning how to do responsive layout by scratch...

Point is, I would love to see Drupal accel in this area and very quickly. Make Drupal do the heavy lifting and allow the themes to spend more time making the pretty bow before the countless frameworks get out of hand with doing things the way they want to do them. In my opinion, a person should be able to jump from theme to theme without having to spend several weeks just going through the documentation of how this or that maintainer thought the best practice should be. Joomla or WordPress doing this yet or are they still hacking away like iPhone and Android just came out? There's got to be an easier way...

catch’s picture

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

Nothing inherently stops this going into a minor version.

EclipseGc’s picture

Status: Needs work » Postponed
Issue tags: +Blocks-Layouts

This should likely be moved to the layout_plugin module, but postponing this for the time being at the very least.

Eclipse

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.

tim.plunkett’s picture

Issue tags: -Blocks-Layouts

This is explicitly out of scope for #2811175: [plan] Add layouts to Drupal, untagging

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Category: Feature request » Plan
larowlan’s picture

Do we still need this?

If so I think we should be targeting site builders only.

We could have a config entity that resulted in a derivative plugin for layouts.

https://www.previousnext.com.au/blog/creating-layout-plugin-dynamic-regions has some prior art for config based regions but I think we could simplify that here.

I don't think this should be given to content-editors, as in my experience that works out as well as giving them the ability to edit font colours and backgrounds.