Part of a family of issues at #1787634: [META] Decouple layouts from themes

Problem/Motivation

It is not possible to use the Drupal 8 layouts in any way in Drupal core now. The proposed conditional page system (#1787942: Allow assigning layouts to pages) was deemed a usability issue because you could not actually create pages with it, you could assign layouts to existing page patterns with conditions. Therefore we need a simpler way of just creating blank pages. The term "landing pages" has been changed to "blank page" because it is laden with connotations related to marketing conversion funnels. This issue is simply about creating one-off pages like an "about us" pages or a "Terms and conditions" page or any other stand-alone page that does not neatly match a content type or view and is not necessarily a marketing "landing page".

Proposed solution

The "free form" page entity type solves at least that half of the problem. The other half, how the user "lays out" the pages can, of course, now be handled by the theme system with twig but I think that this is not an ideal solution for site builders, managers and editors. Indeed many modules have been built to allow the site builder to "lay out" the content well. That is the cowpath we should be paving here. Providing a straightforward way for the content editor or site manager to lay out a one-off page in-place and without code.

This could be done with the following:

  1. Create the default "blank page" entity type with only a title and a body field
  2. Set the default route for content creation for entities of that type to the front end—not the admin theme—enabling the user to lay out the page as it will be displayed
  3. As an example for site builders and themers, create a twig template for the entity type in bartik theme with an edge-to-edge content region with no sidebars following the paradigm of panels
  4. Create a default view mode applied to that entity type in which the title field is tokenized and embedded into the html of the body field.
  5. Extend edit module to enable it to edit the embedded title in-place (and at a later point, possibly any field the user adds to the type)
  6. Provide a lightweight Drupal-specific plugin to CKeditor and corresponding Drupal module that makes CKblocks responsive and draggable

Admittedly this solution potentially creates a kind of "two tiered" layout system in which laying out the content well is done in a different way than laying out the regions and blocks of the site, but on a great many Drupal 7 sites that roughly mirrors the current reality. These two tasks: laying out the site and laying out a page are performed today by two different users with different skillsets therefore matching UI patterns are less important.

Note: 4 and 5 are not absolutely essential to achieve the goal but would be nice and open doors to other things. MVP ia a responsive layoutable-in-place full-width body field.

Related issues

The final will depend on capabilities introduced with #1839278: Add layout template demonstration and #1817044: Implement Display, a type of config for use by layouts, et. all, however neither is in core.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

FileSize
42.3 KB

Forgot to add listing page mocks.

Gábor Hojtsy’s picture

Status: Active » Needs review
FileSize
36.63 KB
37.88 KB
12.19 KB

Initial patch. Does the following:

- establishes a new page.module to manage these pages
- all landing pages are config entities
- overridden config entity list controller to display the path and layout information in the overview
- ships with two sample pages

It *does not* do any menu registration yet as there are probably things people don't find comfortable with this implementation already, so I think we have plenty to discuss before I get into menu rebuilding when saving path objects, etc. Also, obviously no block assignment to layout regions, since that is being developed from #1839278: Add layout template demonstration and onwards. If we assume that patch is there, we could summon the demonstration at least here with some AJAX tricks. However, we need that extended with block placement capabilities as well even for master layout creation.

Screenshot for listing (note placement under admin/content):
LandingPagesImpl1.jpg

For editing:
EditLandingPage.jpg

Gábor Hojtsy’s picture

Issue tags: +Spark
jibran’s picture

It is awfully similar to Empty Page.

Crell’s picture

It's more akin to an under-engineered Panels 1. Which is not a bad place to start. :-)

+++ b/core/modules/page/page.module
@@ -0,0 +1,112 @@
+    'administer pages' => array(
+      'title' => t('Administer pages'),
+      'description' => t('Manage a set of landing pages with distinct layouts on the site.'),
+    ),

We probably need a less over-used word than "pages" here. Landing pages? One-off pages? Layout-only pages? Not sure, but "page" is going to be confused with the "Basic page" node, guaranteed.

+++ b/core/modules/page/page.module
@@ -0,0 +1,112 @@
+/**
+ * Load one page object by its identifier.
+ *
+ * @return Drupal\page\Page
+ *   Page configuration entity instance.
+ */
+function page_load($id) {
+  return entity_load('page', $id);
+}

Is there some way we can mark this as being just a menu load callback? I know it's needed for now, but I don't want to encourage people to use it for arbitrary loading.

DamienMcKenna’s picture

Why not just use a generic content type and customize that page's layout? Think node + Panelizer. Seriously. This issue feels like it's going in the wrong direction.

saltednut’s picture

Let's take a step back here. I disagree that this is a wrong direction. An empty page for this system will help users. Making a node bundle stand in for landing pages is also kind of confusing.

DamienMcKenna’s picture

Read through some of the code from the patch...

Ok, good, so it's an entity type - my reservations pretty much just vaporized :)

DamienMcKenna’s picture

Suggestion: on the admin/content/pages list change the title and/or path items to be links to the actual pages.

DamienMcKenna’s picture

Status: Needs review » Needs work

Also, while the module creates the /news and /about-us page records, both give a 404 error when accessed.

effulgentsia’s picture

Status: Needs work » Needs review

Why not just use a generic content type and customize that page's layout? Think node + Panelizer.

A lot of us discussed that at BADCamp. We came to the conclusion that custom layouts per node (Panelizer) would be better left to contrib, because it introduces a lot of technical and UI concerns that we don't think we have time to address in D8 core. For example, should per-node layouts be stored as config in CMI or as part of the node? If in CMI, core's default CMI storage is file-based and won't scale to hundreds of thousands of items. However, if it's stored as content, we're not sure how that would integrate into #1812720: Implement the new panels-ish controller [it's a good purple]. Plus, actually customizing the layout on a node by node basis can quickly make a site an unmaintainable mess, and having the ability to do it in core could send people who don't understand the pitfalls down that road, whereas less than 1% of Drupal sites are currently using Panelizer, and I hope the ones that are know what they're doing and how to avoid maintenance hell.

On the other hand, as envisioned by this issue, "landing pages" do not have their own content and are therefore not nodes. They are pure configuration objects, like Views. They are for adding a URL to a site that assembles content from other places (blocks).

Also, by limiting the scope of this issue to just static URLs with no primary content, just blocks, there's a chance we can actually get a Layout UI into core by feature freeze, which we could then iterate on after feature freeze to support whatever other trickier use cases (e.g., #1787942: Allow assigning layouts to pages) the core maintainers approve of as still in scope for D8 core, and that could provide a foundation that contrib enhancements to page/layout/context management can leverage.

effulgentsia’s picture

Status: Needs review » Needs work

x-post

DamienMcKenna’s picture

@effulgentsia: You do, however, realize that there would equally be plenty of sites that are built exclusively using these landing pages and custom blocks? How would the alleged "hundreds of thousands" of landing pages hold up to management?

FYI I know of a "small" D6 site that was built that way, had 300 custom blocks that were all positioned in standard locations on a set of pages.

In Panelizer v2 you can create multiple default displays per entity bundle and select the one you want, thus greatly reducing the number of one-off pages.

Crell’s picture

I don't think there would be a scalability problem there, other than the UI needing a pager. We could throw a "panelize" tab (or appropriately renamed) on the entity for an easier way to get to the page. Viewing one landing page is still one entity load operation, plus a controller that "does stuff with it". Which is pretty much what a node page is now, and we know Drupal can scale to zillions of nodes.

I don't know how well CMI will scale to zillions of objects, but that's hardly a unique problem to this issue. Besides, we know that Drupal does not scale to zillions of content types nicely. If I see a site with 70 content types that is having performance issues on admin pages, I confidently say "you're doing it wrong". Probably the same applies here.

Gábor Hojtsy’s picture

I just created this fascinating little figure about our terminology mash-up, because I got continually confused. Now I have a place to refer and maybe a hope we will fix this all up when the time comes. :D

Gábor Hojtsy’s picture

Status: Needs work » Needs review

Also note the layout selection will need to be dropped from this, the populated *display* is inherited from the master layout, that is configured with #1841584: Add and configure master displays. No patch for that yet. But essentially where the design shows master blocks, those come from the master layout (prepopulated display) and the page blocks are added here on the page.

@DamienMcKenna:

Also, while the module creates the /news and /about-us page records, both give a 404 error when accessed.

This was acknowledged when the patch was posted. Of course the patch needs work, you cannot actually place blocks yet, the page is not created and there are no tests :D The point of posting the patch was to solicit reviews, such as Larry's. I do not want to discourage reviewers by this being in needs work. More reviews are welcome. We need to expedite the work on this.

moshe weitzman’s picture

I have a problem with reusing the term 'template'. That has a different meaning in Drupal already. For the bottom row, I propose: Layout => Populated Layout => Landing Page. This has the advantage of aligning the word Layout in the front and back ends.

tkoleary’s picture

Is that re a reason why "layout" on the backend can't be changed to "template". Seems like it makes more sense since it maps to the twig template and will be easier for themers to comprehend?

effulgentsia’s picture

Re #17 and #18, I opened #1841824: Terminology: figure out proper words to use in the UI for describing unpopulated layout vs. populated layout. Let's discuss terminology there rather than here. For anyone with thoughts on terminology, please leave feedback on that issue. Thanks.

Gábor Hojtsy’s picture

FileSize
4.24 KB
12.6 KB

Made changes based on suggestions:

- renamed "administer pages" to "administer landing pages"
- removed page_load_all(), added @todo note to remove page_load() when hook_menu() does not need it anymore
- added actual path registration for pages, which necessitated an empty page callback, an always accessible path and a full menu rebuild on save (debate welcome :)
- linked in pages from the overview

Gábor Hojtsy’s picture

Issue summary: View changes

Add listing page mocks.

rvelhote’s picture

This is a great feature but please don't leave us stuck with a solution that does not allow translation of this type of content and requires a bunch of modules and hacks to get around just like it happens with menu translation in D7.

andypost’s picture

#20: landing-pages-20.patch queued for re-testing.

brunodbo’s picture

Are you also thinking of including other features from Panels, such as:

- CSS class/id assignment to pages
- Visibility settings for blocks (although that should probably be up to the blocks, not the landing pages)
- Contexts: eg. per node type layouts vs per node layouts (which according to #11 won't be part of this patch)
- ...

Just trying to get an idea of where this is going: it currently looks sort of like a bare bones Panels implementation, so wondering how much this would overlap with Panels.

andypost’s picture

Looks like this would go to contrib for D8.
Anyway his useful for small sites because provides a complete path to page.

For entities the panelizer (per bundle) page edit looks preferable

Bojhan’s picture

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

Yup, this does not look like D8 material anymore.

quicksketch’s picture

Doh, sad panda. I was catching up on SCOTCH today and came searching for this issue (which I knew had to exist somewhere). Thanks @GáborHojtsy for your work on this nonetheless. From what I see here it looks like a great start. I would have loved to see Drupal ship with the frontpage done as a page provided by this page.module instead of the river of news callback /node provided by node module.

I also love the idea that page.module is back. For a good laugh at simpler times, check out the Drupal 4.6 page.module.

quicksketch’s picture

Issue summary: View changes

Updated issue summary.

andypost’s picture

Latest code pushed to My sandbox and I going to make some work on it

tkoleary’s picture

Version: 9.x-dev » 8.1.x-dev
Issue summary: View changes

The design will have to be revised significantly but I think this is a good candidate for 8.1

moshe weitzman’s picture

There are hundreds of landing page build/analyze/optmize services on the web. We should study them when revisIting this IMO. See https://www.google.com/webhp?q=landing+page+service

Bojhan’s picture

@moshe Could you explain that a little bit, I have no idea how that is related? There are also hundreds of CMS's on the web :D

andypost’s picture

Issue tags: +Page Manager

#15 exposes the architecture but we still missing layout as a thing.
Also landing pages mostly require a different theme and page template

DamienMcKenna’s picture

Food for thought: how should pages created with Views tie into this?

tkoleary’s picture

Title: Add simple landing page creation capability » Add simple blank page creation capability
Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

@DamienMcKenna

Re#6 See the revised issue summary, two years late. :)

tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Issue summary: View changes
quicksketch’s picture

I'm happy to see this conversation picking back up again. Things have changed a lot (for me and Drupal both) since 2 years ago when I last posted. Ideas for how this can work in Drupal can be taken from the new Layout system in Backdrop CMS, which we've been building for the last 6-8 months. Backdrop clearly has been borrowing heavily from Drupal issues and patches, following a different approach for a different audience, but in this case there are a lot of ideas which could be very beneficial for Drupal to leverage. We've been thinking about this for almost a year, building on the "cowpaths" @tkoleary mentioned, effectively porting Panels with an entirely new UI and simplified concepts.

Introductory video: https://www.youtube.com/watch?v=xoD6gDZmE3o

Highlights as bullets:

  • Separate themes and layouts entirely. This makes every theme responsive, and no longer responsible for layout. There's no such thing as a "three column" theme, as the provided core three column layout can be used with any theme.
  • This separation means you could switch between themes at any time, maintaining the block positioning and structure regardless of theme.
  • Layouts would be a new top-level concept (not included at the time of the video), akin to a module or theme. So "themers" would likely become responsible for layouts and themes, built in the same manner, just as two separate concepts.
  • Layouts could also be provided via modules, so something like the existing Spark-initiated Drupal Layout module could generate layouts to be used across themes.
  • Layouts would be able to create stand-alone pages, or override any existing path in the system. This would allow layouts to make landing pages, as well as take control of paths like node/%/edit, utilizing the same two-column layout as the rest of the site.
  • A "default" layout could be provided for the front-end and back-end, allowing for any page without a specific layout to utilize the site-wide defaults (providing the upgrade/migration path for existing sites).

Layouts in Backdrop were built as a port of Panels/CTools/Page Manager, so all the functionality from the most popular system existing are possible (if not fully ported/implemented at this time). It's taking a proven system, making it easier, and resolving all the conceptual conflicts between the theme-base region system and a Panels-based layout system.

tkoleary’s picture

Issue summary: View changes

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.

andypost’s picture

Related issues: +#2296423: Implement layout plugin type in core
SKAUGHT’s picture

#32 maybe Views shouldn't make pages, only blocks. there are/will be too many control points for making pages which is as confusing for both site manages and dev's (later in project lifespans).

tkoleary’s picture

Issue summary: View changes

@SKAUGHT

maybe Views shouldn't make pages, only blocks.

Well I can see that being controversial, but it sounds to me like a good idea. Now that I look back at the summary of this issue it should really be updated to reflect recent changes but I think the core idea is still valid.

If we assume that layout plugin and page manager make it in to core then all the underpinnings for this would be present and the remaining task would be to create a simple user-centric flow for "create and lay out a blank page".

If that was the primary experience of creating a one-off page then certainly having other ways to create a page (eg. views page display) would be orthogonal and potentially confusing to the user and should potentially be removed. The new flow could be:

  1. Click "create blank page"
  2. Provide name and path
  3. Choose layout
  4. Choose content
  5. Save and preview

Where "content" is what goes into the "main content" region and can be any block including a views block, but is *not* a node.

This way there's a single flow to create any page that is not a node.

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

#44 is an interesting idea.
There is a LOT of similarity between the Views routing code and the Page Manager routing code.

We could maintain the current UX of creating views "page displays" and under the hood make a block display with a corresponding page entity.
But regardless, that would likely be a follow-up.

Tagging.

tkoleary’s picture

I think what has frustrated me, and perhaps many Drupal users, about this problem space is that conversations about the problem move too quickly from the 'why' to the 'how'.

An experience that would make sense to most users would be:

  1. I open my site where I prominently see some kind of "add page" dropdown
  2. When I expand it I get three options: Blank page, Content page, Listing page
  3. Content page triggers choose content type
  4. Listing page triggers add view
  5. Blank page triggers add page (I assume page manager page)

It's just a menu, and it could be built in five minutes. My point is that to solve a lot of the user pain around understanding how to make different kinds of pages we can do some pretty simple things. We don't need to get into arguments about fundamental structural underpinnings.

Of course there are UX issues around what happens once the user is 'making' the page, particularly in the page manager instance, but looking at it from this angle forces us to follow the user to their logical next step and build on that experience in a way that makes sense. For example:

If I clicked 'add blank page' the thing that is top-of-mind for me is not what conditions or contexts the page will appear under or even what it's layout will be or who will see it. What's top of mind is *what will be on this page*. If we take a content-first approach, just providing a route and letting the user start populating it with content, when the user comes to the point where they need to make choices about who, when, under what conditions the page will be displayed, those choices will be easier to make because the content will dictate them.

For example, if my page is 'news and events' and I start adding things like a custom block that contains some basic intro copy, an events view block, and a news view block, I am likely assuming an audience (anonymous users), which means i'm probably not going to need anything keyed off 'user'. This may not be the best example, but the point is that the content will naturally focus the users mind on decisions about the conditions which Drupal currently front-loads on the user before they have made content decisions.

tim.plunkett’s picture

Status: Needs review » Needs work
Bojhan’s picture

Issue tags: -Spark +Usability

With layouts in how much of a possibility is this? Is it merely a route builder?

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.

andypost’s picture

Looks we can close it as LB in core doing that

abedih’s picture

@andypost

I don't think so. the problem with layout builder is that it is saved in the form of content an also the pages you create with layour builder are most likely NODES and they don't have fixed and absolute paths.

this is mostly problematic when you want to transfer configuration from your development environment to production. I did not used page manager module so much but I think that is the real solution but it is very complex

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.