[Research] Landing page integration

Thanks for this write-up!

Currently Experience Builder is not integrated with any Drupal content model.

That's not quite accurate — see DynamicPropSource. That is the technical foundation that will power 7.1 Tokens and 7. Content type templates. See the discussion at 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active .

The problem is that no designs exist for that yet, but XB is definitely intended to leverage Drupal's structured content (aka content model aka base/bundle fields).

That being said, yes, there is a need to for simple landing pages that don't use Drupal's structured content! So, +1 for this:

I like to think of it as Landing Pages (XB) with unstructured content and then there are Nodes with structured content (which eventually can be designed using XB.)

And I think that automatically means only the first choice you present really makes sense:

Create a custom content entity type that works solely with Experience Builder

This is the only way that truly is guaranteed to work/be controllable, and it makes for a very nice/clear separation of concerns: this new LandingPage or UnstructuredPage or FreeformPage or UnstructuredContent content entity type would be the clear special case.

If somebody wants landing pages with some structure, fine, then don't use this new content entity type: just create a specific bundle of Node that has the structure you want to share across your landing pages.

I think you already state that in your proposed resolution, where you wrote — agreed!

I dislike page as a name because it does not convey enough, and is too easily confused with the Page bundle for Node when talking about it. I think FreeformPage best captures the semantics (until I see a better proposal), and makes sense as the default human-readable name for it.

Menu (menu_ui_form_node_form_alter() and friends), Views support and permissions are your only 3 concerns. Of those, I only see the menu integration bits as unfortunate duplication, everything else seems trivial to support?

The problem is that no designs exist for that yet, but XB is definitely intended to leverage Drupal's structured content (aka content model aka base/bundle fields).

I didn't mean to say it's not intended, more so "we need a launching point." I'll find better words for this sentence.

I dislike page as a name because it does not convey enough, and is too easily confused with the Page bundle for Node when talking about it. I think FreeformPage best captures the semantics (until I see a better proposal), and Landing page makes sense as the default human-readable name for it.

This works for me. I wouldn't mind just doing:

• Entity type ID: freeform_page
• Class name: FreeformPage
• Label: "Landing page"

When thinking about internal code and performing queries or whatever, using freeform_page feels more explicit than just landing_page. I know landing page is a generic term, but for me I think of it in terms of the marketing landing pages you build in HubSpot or Mautic. Not pages on a website. So freeform_page gives us a more descriptive option than just page

When thinking about internal code and performing queries or whatever, using freeform_page feels more explicit than just landing_page.
[…]
So freeform_page gives us a more descriptive option than just page

That's exactly why I proposed that 😄

#3++

updating IS with name

Added node-specific things to consider for LinkIt and LinkWidget

I'm still working through the UX implications with @bostonjillian. I'm planning to meet with her tomorrow.

I'm not a specialist in trademarks but it seems that Apple has a product called Freeform. It probably means it's better for us to avoid using that as the name. Also, the human readable name that has been used so far has been just "Page".

Being able to create sorted lists of landing pages and structured pages

The /admin/content route would list structured content for all content types (nodes). There would be a new tab (like Media and Files) for "Landing pages" at /admin/content/landing-pages. These would list all unstructured content landing pages.

This is a stronger con from me when having a separate content entity. Having a separate list for landing pages seems hard to justifying? It’s only a technicality why we need a separate list in the admin UI.

I guess also integrations like:

Entities would need to use Dynamic Entity Reference to support referencing nodes and landing pages

is also a Stronger con imo

Having a separate list for landing pages seems hard to justifying?

I'm curious why? You'd have to filter /admin/content to find them anyway, and in most CMS each type of content is usually its own page. I agree it set off my "Drupal-senses", but then I did comparisons with other CMS or CMS-adjacent products.

Going back to "Being able to create sorted lists of landing pages and structured pages", this is actually feasible with Search API and is a common pattern for mixed entity type result lists.

is also a Stronger con imo

Do folks often reference landing pages from regular content like this, as an entity reference? I'm not saying it shouldn't be allowed. I'm just curious. Usually its landing pages which reference specific types of content used in collections (events, articles, etc.) In my experience things like articles usually reference one specific type of thing "Related articles" or "Documentation" or "Suggested products." In this case it could be a direct reference to a landing page.

Thought of a few things:

• A custom entity type avoids naming conflicts with existing content types (machine names.)
• If folks don't want to use the unstructured page, they just don't use it – don't grant the permissions for usage – and use XB on nodes (which comes after pages)

fix example screenshots

started some ideas on the entity implementation, hopefully shows how it makes it easier to get started with building

Had a chat with Lauri about this and said I would comment.

Despite best efforts, someone can still delete a locked down configuration entity and break the Experience Builder integration.

This doesn't feel like a great reason to treat it separately, given all of the knock on effects. We can protect against doing dumb things in the UI, e.g. you can't delete a content type if there are any instance of it. You could still find a way, but there are a million ways to break a site if you really want to, and I don't think we should expect to fully prevent this? But admittedly I don't understand all of the technical side of why it's hard to properly lock it.

Existing LinkIt profiles will have to be updated to allow referencing the new entity type. However, existing profiles would have to be updated for the new content type anyway

This isn't quite right, most profiles are set to not filter by bundle, so new content types are added automatically. Not a huge deal, especially since we are trying to replace Linkit basics in core, so we could support it there. And if you have an existing site that you are moving to XB then updating a Linkit profile is the least of your concerns :)

I agree the entity reference example isn't that relevant, because if the entity has no view modes, it's not likely to be used that way.

From a UX perspective, we could achieve separation without using a new entity type and that would avoid all of the other problems that come from it. So that also doesn't seem like it should be the reason?

If folks don't want to use the unstructured page, they just don't use it – don't grant the permissions for usage – and use XB on nodes (which comes after pages)

But will this result in a weird UX where there is this section that just never gets used? Many site users will have admin permissions, so hiding it that way doesn't always work.

Lastly just on the naming, I don't think 'Pages' works. Conceptually this is no different from 'Content' which many people think of as a list of pages. The naming problem is actually a good reason NOT to separate it!

The naming problem is actually a good reason NOT to separate it!

The naming isn't the main reason.

We can protect against doing dumb things in the UI, e.g. you can't delete a content type if there are any instance of it.

My concern isn't the UI. We're expecting people to export the config this module introduces and keep it maintained. Which means someone can edit it and import it, and we're responsible for also updating it if need be. I'm biased here, so maybe someone else should have researched this. But I don't see why we should be forced to manage configuration when it can be managed in code. Especially if the goal is to provide a very specific and tailored experience in this use case.

But admittedly I don't understand all of the technical side of why it's hard to properly lock it.

We're going to write a bunch of specific code to deny access to operations and hope we did the right ones and then have to maintain these code paths. Which takes away from the main development tasks.

Whatever is decided, I believe the items in Entity implementation from the IS can be applied to a node type. We can use a bundle field definition in code to attach to our bundle without field config and provide a conditional view builder.

Do folks often reference landing pages from regular content like this, as an entity reference? I'm not saying it shouldn't be allowed. I'm just curious. Usually its landing pages which reference specific types of content used in collections (events, articles, etc.) In my experience things like articles usually reference one specific type of thing "Related articles" or "Documentation" or "Suggested products." In this case it could be a direct reference to a landing page.

I've been looking for use cases where sites would reference landing pages. What I've seen many existing users of Layout Builder do is set up simple content model to simplify the entry of meta tags fields for content editors. This would include title, description, and an image.

In a call today where I walked through some customer use cases, I discovered that in some cases, these are being used to create a teaser/card view mode to build multi layered navigation. This could be used to create generic navigation patterns that some sites adopt. For example: https://www.landelijkegilden.be/over-ons and https://www.nokia.com/industries/. The Nokia example is interesting because it's essentially a nested tree of landing pages. It might be better built not using the page content type but especially in the case where the site isn't particularly large, this works fine.

How would it impact our decision if we there was a chance that in future we may decide to allow adding additional view modes to these landing pages? Is this something contrib could enable if we decide to not support this but it's something that is needed in some cases?

This made me realize also that just exposing the meta tags fields is not enough. We'd likely have to build something more custom for it because the meta tags field doesn't provide sufficient controls over meta tags – specifically it doesn't allow adding images. This obviously raises the question; what source should we use for the image, i.e. media (and which bundle) vs image field?

How would it impact our decision if we there was a chance that in future we may decide to allow adding additional view modes to these landing pages? Is this something contrib could enable if we decide to not support this but it's something that is needed in some cases?

View modes are not attached to Field UI / field configuration management. They're managed under "Structure" so they can be managed/designed via 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active when that is completed (regardless if standalone entity type or locked content type.) Maybe XB will allow creating view modes itself.

This made me realize also that just exposing the meta tags fields is not enough. We'd likely have to build something more custom for it because the meta tags field doesn't provide sufficient controls over meta tags – specifically it doesn't allow adding images. This obviously raises the question; what source should we use for the image, i.e. media (and which bundle) vs image field?

We should eyeball what the Drupal CMS SEO recipe has done for more information. @lauriii and I discussed that there would be a minimum of a title, description, and image field. Then Metatag can be configured to use these for most common purposes (like embedded links in social media.) We'd want to use a media field, though, versus just uploading one off images via the image field. We can limit the allowed media types based on their allowed source field type (image.)

We should also provide a default Metatag field so that Metatag works.

I'm not convinced by the configuration management fragility arguments of node bundles as the reason for a new entity type.

Despite best efforts, someone can still delete a locked down configuration entity and break the Experience Builder integration.

Can't we prevent that with a config import validator?

However, I do think the question is intriguing as to whether the concept of an "un-modeled" page is sufficiently different from "modeled content", such that creating that split at the entity type level ("node" = "modeled content", "machine_name_tbd" = "un-modeled page") would actually make Drupal easier to understand to new Drupal users (content creators and site builders) without taking any power away from existing Drupal experts.

I'm using the term "(un-)modeled" here rather than "(un)structured", because the entity type being proposed here would still have fields (e.g., the XB field itself and SEO-related fields), so the distinction isn't fields or no fields, it's whether or not there's a content model. For example, for content types like Product, Event, JobPost, there's a content modeling process involved in creating those for a site. And most of Drupal's awesomeness derives from letting people do that content modeling in the UI and then being able to use that content model in powerful ways.

But what happens when someone is new to Drupal, or wants to build a quick new site, and doesn't want to first go through a content modeling process, they just want to create a few pages? Currently, Standard Profile provides that via the "Basic Page" content type, but does it actually make sense for "Basic Page" to be one content type among Article, Product, Event, JobPost, etc.? Or is the concept of "Basic Page" somehow special, different from those other content types? And would Drupal be easier to understand if we leaned in more into that specialness?

For example, within XB, I think there's designs for making the content creation links say "New page" and "New CMS content", where "New page" lets you create a new un-modeled page and "New CMS content" would then show you links for "Article", "Event", "Product", etc. Now, we can achieve that by having a config setting within XB for which node type is the one that "New page" creates, but the fact that user research led to designs that partition in this way leads me to wonder whether there's a real conceptual difference between un-modeled pages and modeled content, and whether creating a new entity type for un-modeled pages would help us both refine our understanding of that difference, and optimize various Drupal UIs accordingly.

However, my biggest concern with un-modeled pages being its own entity type, is then what happens when someone starts by creating some un-modeled pages, but then discovers that those pages could benefit from a content model. There are contrib modules, such as https://www.drupal.org/project/convert_bundles → , for converting a node from one bundle to another, but that wouldn't work for converting a not-a-node to a node. Instead we'd need to create a new node, move the not-a-node's XB field data (and SEO field data) to the node, and move/redirect all links and references from the former to the latter. Links I think we could handle (e.g., by implementing the toUrl() method on the class for this not-a-node entity type), but references would be really tricky. However, we can avoid this problem by disallowing references to the proposed not-a-node entity type. Which I think would fit... why would you need an entity reference to an un-modeled page? If you do need an entity reference to it, that's probably a sign that it should actually be a modeled node.

I'm still not 100% clear on whether a separate entity type vs. a special node bundle is desirable or not. But I think the decision should be based on to what extent do we think un-modeled pages are sufficiently distinct from modeled content, rather than on concerns that we won't be able to implement sufficient config import validation to prevent people from making config changes that will break the code.

I need to read #22, but dumping some notes I forgot to put on Friday.

By using a custom entity type, all contrib which influence and effect nodes do not work. This can be problematic but also a blessing. And it prevents random contrib from breaking things due to us treating a specific node bundle as a snowflake. So that should be considered.

I'm becoming indifferent. I believe a new entity type makes it easier to work with and removes a lot of extra work before all entity types and bundles are supported in XB. But it seems like "make a third party settings and hack nodes" is the easier route in terms of debate and just getting started, now.

mglaman → changed the visibility of the branch 3482259-research-landing-page to hidden.

mglaman → changed the visibility of the branch 3482259-research-landing-page to active.

I was asked to open an ADR, https://git.drupalcode.org/project/experience_builder/-/merge_requests/390 based on the issue and discussions thus far.

But I think the decision should be based on to what extent do we think un-modeled pages are sufficiently distinct from modeled content, rather than on concerns that we won't be able to implement sufficient config import validation to prevent people from making config changes that will break the code.

Agreed, and that was the initial basis of my thoughts. I figure there will be. Then it just spiraled from there into focusing on arguments on technical tidbits since I knew it'd be controversial for most technical Drupal users.

Now, we can achieve that by having a config setting within XB for which node type is the one that "New page" creates, but the fact that user research led to designs that partition in this way leads me to wonder whether there's a real conceptual difference between un-modeled pages and modeled content, and whether creating a new entity type for un-modeled pages would help us both refine our understanding of that difference, and optimize various Drupal UIs accordingly.

From a content creators perspective, it's different from the rest of the content types because it doesn't come with a predefined template / structure. They are also more tied to the specific page that is being built (i.e., usually less or no additional view modes, not being displayed in lists, etc.). To a large extent, you could accomplish this with a content type, although it's not guaranteed to hold the same meaning across sites.

One related quote from a user interview earlier this year:
Interviewer: "You have this content type called page. What is that?"
Participant: "That's actually the content type that I use the most. Whenever we have something that's got more like set structure, that's when we use a content type that is more kind of identified and clear. But whenever we have something that needs to be a little bit more flexible, we use the page. Page is much more bare bones than the more specific content types."

Currently, Standard Profile provides that via the "Basic Page" content type, but does it actually make sense for "Basic Page" to be one content type among Article, Product, Event, JobPost, etc.? Or is the concept of "Basic Page" somehow special, different from those other content types? And would Drupal be easier to understand if we leaned in more into that specialness?

Whether we display the default page type as a content type impacts also users building the site. I don't have any user research suggesting one way or another on this.

My thinking on what makes sense here was shaped more by what the majority of the players in the market are doing. Having a default page type which could be used for one-off content, and modeled content for creating display templates that display the same content different ways (i.e., multiple pages or lists) is a fairly standard approach that many proprietary CMSs targeting non-enterprise sites have adopted. In Drupal, this becomes even easier to explain once we land ✨ Allow disabling a route for a bundle and adding additional routes for view modes other than 'full' Postponed and ✨ Support adding additional routes for view modes other than 'full' Active because it makes Nodes the central place for modeled content, not only for pages.

A key decision we need to make eventually is if we allow adding fields to the default page type or not. Some more complex sites use custom fields even for their landing pages, not to change the display but as meta information (e.g., tagging to build navigation views or to show related pages). Initially it's fine to not allow custom fields because for a simple site, we can define what are the fields needed to meet most use cases.

We can get at least a sense on what are the required capabilities because shipping with this type of content type is really common. For example, Rocketship comes with a page content type, Ignite comes with a page content type, and Wingsuit Kickstarter comes with a landing page content type. At minimum, we'd need to support meta tags and be able to exclude pages from search.

I discussed with @bostonjillian and @mglaman earlier today to find out if there are open questions we'd like to validate. In regards to displaying pages separately, we agreed that we didn't have open questions to be researched at this point around this. Most of the open questions I have are more around what it is we allow users to do to customize the default page type vs what we don't allow them to customize. We don't have all the answers and we may need to refactor this later but based on my discussion with @mglaman, at least he wasn't too concerned about the refactoring at this point (even if in the worst case we'd need to build a best effort upgrade path). Based on that, I'd be fine for us to proceed on this issue. We need to revisit this anyway, because regardless of the approach, we'd need to test the solution with the rest of the product later.

We also discussed the use case where users need to go from the default pages to modeled content. We discussed how challenging it would be to do this outside of very specific simple use cases since the default page type doesn't come with the fields the target content type would be likely to have. This would make any migration from the default page type to modeled content only so useful. We thought that given how many challenges there are with moving from a landing page to a modeled content, this use case would be better solved by focusing on educating users early on how to think about content modeling and why they should care.

Marking for review, ADR in the MR.

I need to double check concerns from #10, #17, and #22 are in Consequences and have mitigation solutions, and that the following statement provides a to them if still problematic:

For 1.0.x we may remove the content entity type and opt for a locked content type that Experience Builder provides. This is acceptable, as we're in an early preview state with expected data loss between versions. Or we can create a migration from the content type type to the content type.

I think personally I'm a -1 on this idea being part of XB core. It sounds like a good contrib module that could be added on top of XB. The IS raises 6 points that we get for free with nodes and others have been raised in comments on this issue. This is extra code & tests to maintain and increases technical debt.

I think XB should be built with node in mind from the start, otherwise we're losing functionality that we currently have with Layout Builder out of the box. Without node support, I think real world adoption will be slower and developers will have less confidence in adding XB to new sites.

For example, we were early adoptors of CKEditor5 in new sites because it was a drop in replacement for CKEditor4 and because of that we were able to catch and fix issues ( https://www.drupal.org/project/drupal/issues/3339400 🐛 Incorrect use of FormattableMarkup in logger messages Fixed , https://www.drupal.org/project/drupal/issues/3280602 🐛 Exceptions for CKEditor 5 plugin definitions containing wildcard tags when PHP is built with libxml 2.9.14 Fixed ) in CKEditor5 before it was stable.

We couldn't be early adoptors of this before it supports node, since we would need to run both Layout Builder and XB side-by-side, which doesn't feel worth it.

I understand that this is being built with the idea of rapid iteration and it's been said that supporting nodes out of the box will be done before the 1.0 release, it just feels like we should be fixing the node related issues as we go rather than kicking the can down the road and saying we'll figure it out later.

I think XB should be built with node in mind from the start, otherwise we're losing functionality that we currently have with Layout Builder out of the box. Without node support, I think real world adoption will be slower and developers will have less confidence in adding XB to new sites.

We couldn't be early adoptors of this before it supports node, since we would need to run both Layout Builder and XB side-by-side, which doesn't feel worth it.

I understand that this is being built with the idea of rapid iteration and it's been said that supporting nodes out of the box will be done before the 1.0 release, it just feels like we should be fixing the node related issues as we go rather than kicking the can down the road and saying we'll figure it out later.

I personally don't think that the intent of the proposal is to kick the can down the road. We are actively working on making the node specific functionality to work. At the moment it looks like that we will have support for nodes without additional bundle fields before the end of the year.

I totally understand that Experience Builder will be only so useful until it can support structured content like nodes. I my mind, support for structured content is more than just being able to edit the field values within Experience Builder. Support for structured content includes also being able to build view modes using the field values in Experience Builder. Support for structured content is intended to be worked on early in 2025. This is to say that it's not something we're intending to leave last minute before the release.

This proposal allows us to start collecting feedback on a slice of Experience Builder before we get there, which should ultimately lead in a better product at the time of release. That said, this is not being done just for the short term gain. UX has identified that the basic page concept is somewhat distinct from the structured content and that at least in some UIs, that should be prioritized over other types of content. Here's an example of one screen for this:

I posted #2 and #4 ~3 weeks ago.

A lot has happened since, and an ADR is present in this MR (kudos for that! 👏). I just reviewed the ADR before having read all comments here. Doing that now. But having reviewed just the ADR, I already spotted a number of significant things critical to clarify prior to merging this.

1. The issue summary talks about /admin/content vs /admin/content/landing-pages. I agree with that. The ADR does not say that, and says instead that we'd need to list both in the same view, and hence have to somehow make the Views module support multiple base tables. IOW: the issue summary and ADR contradict each other.

   I strongly disagree with @johnwebdev in #10. Unstructured content/freeform pages/landing pages are conceptually wildly different from structured content. I could easily have a 1,000 events or product nodes, but probably only have 10 landing pages. It makes no sense to me to mix those. I think this is a leftover from the typical Node-centric thinking we've been doing: "Content created in Drupal that has a nice URL" is typically a Node.
   File and Media content entities have their own listing too, as do contrib content entity types such as https://drupal.org/project/commerce's Product also have their own listing, and they also have nice URLs. We don't expect those to be listed alongside Nodes either? So why do we expect this to happen for this new content entity type?

   Agreed with @mglaman in #11 too.

2. @pameeela in #17: Could you please list those "knock on effects"? 🙏
3. @pameeela in #17:
   

   But will this result in a weird UX where there is this section that just never gets used? Many site users will have admin permissions, so hiding it that way doesn't always work.

   Are you referring to the hypothetical case of a site that has zero "landing pages"?

4. @lauriii in #19: We don't yet know what view mode support in XB will look like/how that will work. For now, we don't have any real answer for this other than the requirement. We cannot answer this until we know what that UX should (roughly) look like. (For content type templates it's somewhat clearer: a different XB component tree configured per view mode per content type. But … what about the component tree in the individual entity? The absolutely critical thing to answer there is my comment at Assigned to: lauriii #3455629-29: [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model → , which has been waiting for an answer since July 17. Unfortunately that issue only a stretch goal for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active , which we already know we will not be able to achieve.
5. @effulgentsia in #22:
   

   Can't we prevent that with a config import validator?

   No. Config overrides etc.

   Not to mention contrib/custom modules altering base/bundle fields in a way that they assume the "regular node form" will be visible, which is the critical UX piece this is aiming to avoid.

6. @effulgentsia in #22:
   

   […] would actually make Drupal easier to understand to new Drupal users (content creators and site builders) […]

   I disagree this would make Drupal easier to understand.

   Because a list of "modeled and unmodeled nodes" would result in a very confusing UX: clicking one link in the list vs the other would reveal

   • either consistent/standardized look and feel ("modeled": all "article" nodes, all "blog" nodes …) thanks to 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active
   • or a unique look and feel for each "unmodeled" node

   I am arguing that "unmodeled" nodes deserve their own admin listing, because they're a distinct concept.

   Or is the concept of "Basic Page" somehow special, different from those other content types? And would Drupal be easier to understand if we leaned in more into that specialness?
   …
   […] whether creating a new entity type for un-modeled pages would help us both refine our understanding of that difference, and optimize various Drupal UIs accordingly.

   💯💯💯💯💯 THIS! This is what I'm arguing for in this (long) comment and in my comments on the merge request 🤓😄

   The user interview @lauriii cites in #28 also leans that way.

7. @effulgentsia in #22:
   

   what happens when someone starts by creating some un-modeled pages, but then discovers that those pages could benefit from a content model. There are contrib modules,

   Easy: ✨ Allow copy pasting components with CTRL+C and CTRL+V Active , but for entire component trees. Precisely because there is nothing structured, it's trivial to go from FreeformPage to Node!

8. @lauriii in #28:
   

   Some more complex sites use custom fields even for their landing pages, not to change the display but as meta information (e.g., tagging to build navigation views or to show related pages).

   Contrib/custom modules will be able to alter the base field definitions of the new content entity type. They can put in the necessary work to keep the XB-canvas-centric UX as fluid and welcoming as it is, in contrast with the Node form UX.

9. @danielveza in #30:
   

   I think XB should be built with node in mind from the start, otherwise we're losing functionality that we currently have with Layout Builder out of the box.

   Agreed.

   This issue is essentially about pushing the "simple, one-off, unstructured, freeform, unmodeled landing page" subset of what XB must provide to the next level.

   What I think @danielveza is getting at is that while that is nice on its own, XB will only succeed if it also supports the "structured/modeled content" use case thoroughly, completely, convincingly. This is why Assigned to: lauriii 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active is so critical, and it's unfortunately only a stretch goal for 0.2. (I personally disagree with that, but I don't get to choose the priorities.)

   I think @danielveza's comment can be rephrased as "this is nice, but we really should be focusing on structured content first, because that is the hard part", and I agree.

   But I also agree with @lauriii that we can, could and should make the simpler subset (unmodeled/freeform/… landing pages) have the most awesome UX possible, and this issue enables faster iteration on that subset. IOW: is something I totally stand by — despite my reservations expressed above.

@lauriii's last paragraph in #31 IMHO should be leading the direction of this ADR. That also means that we should be able to omit the "Views mixed base table" problem from the ADR, among others.

Easy: #3462633: Allow copy pasting components with CTRL+C and CTRL+V, but for entire component trees. Precisely because there is nothing structured, it's trivial to go from FreeformPage to Node!

I agree with the part about it being easy to create a new node and copy content from the freeform page into the new node. But then how do you update links and entity references from other nodes/pages/blocks/etc. that were targeting the old freeform page to now target the new node? My suggestion for that is that links will be the easier problem to solve (whether via Redirect module or FreeformPage::toUrl() or something else) and we don't need to solve for it now so long as we're reasonably confident that it's solvable in principle. But that updating entity references throughout the site from targeting a freeform page to targeting a node is a harder problem to solve, and therefore we should instead simply disallow entity references to freeform pages to begin with, at least until we come up with an approach for how to update them or a product decision/UX that somehow avoids the need to update them.

#33

I'd argue it's convenient having them in the same list. Doesn't really matter it's unstructured or structured, it's still just Content. Just search or apply an filter if you need to be more granular in what you're looking for. This is great for small to medium sites IMO :)

I'd also argue being able to structure your content overview best fitting your IA is even better :) e.g. I can put Products or Events on a separate list because it might make sense for filtering or so.

Contributed modules integrate with nodes currently and could cause unexpected side effects with Experience Builder
Any business logic specified fields provided by Experience Builder may be reused on other content types or possibly modified, leading to unexpected side effects

I'd argue this is a great reason why to do it! It's early development and you get to find these issues early. Doesn't mean you need to adress them early.

While these are acceptable for a full release of Experience Builder, we are still in early development and need iterate rapidly. Experience Builder needs to make direct and opinionated architecture decisions early on. Integrating with an existing system could have unknown side effects. These concerns add additional variables that add complexity to the development of Experience Builder.

I don't really think this is a problem. You don't need to focus on solving those problems right away, but it's good to acknowledge them. If you expect people being able to go into production during early development it probably makes sense to have it separated early :)
And you don't need to act on all of these complexities right away either way.
Personally I think it's a great idea to try integrate it directly, because it would also allow time for existing integrations/systems to fix said issues from their end as well.

Side note: I'm not the one doing the full development on this, so I respect your decision either way, but I guess the beauty of open source is being able to express your opinions and thoughts and try help in the ways you can :)

Side note: I'm not the one doing the full development on this, so I respect your decision either way, but I guess the beauty of open source is being able to express your opinions and thoughts and try help in the ways you can :)

I appreciate it, because it forces us to reconsider all positions.

I'd argue this is a great reason why to do it! It's early development and you get to find these issues early. Doesn't mean you need to adress them early.

Honestly it is super draining. Especially when earlier evaluators who aren't technical find bugs. Now you're toiling on those bugs and edge cases. Or constantly documenting them, but no one reads documentation. We _could_ do in code workarounds to try and stop it (prevent X module install, etc.) But now we're doing even more code work.

Also, as we integrate this new page, whatever we do will make it work with any entity type. We're just not exposing that directly. Maybe we hardcode some items in the XB JavaScript to target "page" and it's field. But then it's a low effort ticket to populate this into drupalSettings so it's truly dynamic. Heck, maybe this exists. I haven't dove into the code entirely. I'm just starting, with this as my jump in point.

I don't really think this is a problem. You don't need to focus on solving those problems right away, but it's good to acknowledge them.

See above. We don't need to solve, but we will be inundated by support requests.

If you expect people being able to go into production during early development it probably makes sense to have it separated early :)

This is exactly it. A curated experience to try and evaluate the Experience Builder. Maybe not into production, but as part of the Drupal CMS demo or other semi-production evaluations.

Personally I think it's a great idea to try integrate it directly, because it would also allow time for existing integrations/systems to fix said issues from their end as well.

I'm jaded from my experience with Drupal major version upgrades and time with the Commerce ecosystem, but folks don't do this. It'll end up being up to the XB team to solve those problems.

#33 knock on effects are things like not being able to easily list them alongside nodes, losing all contrib stuff that applies to nodes (which I acknowledge may actually be a benefit), not being able to convert to using fields/view modes later.

Re: the UX yes I meant that if you chose not to use the non-node page it would be a bit weird since the proposed UI separates them quite prominently.

FWIW I've stayed out of the ongoing discussion because I mostly agree with what @effulgentsia (and others) have said and overall it seems like this decision is being made wisely.

@effulgentsia in #34: I didn't think links/entity references through! 🙈

• I agree that for links it's very much solveable. A possible solution the old FreeformPage content entity continues to exist, but is flagged as superseded, and knows which entity supersedes it, hence ::toUrl() would point to it — I bet you had something similar in mind? 😊
• For entity references it sure is trickier. Agreed with your proposal: 👍 — but I'd go further: I think it NEVER makes sense to reference a FreeformPage content entity, precisely because it is unstructured/unmodeled content, and only structured/modeled content can actually have a reference to another entity! So the only use case I see for "referencing" FreeformPage content entities is menus, in which case we're referencing them by the URL/path alias … and then there is no problem!

@johnwebdev in #35:

RE: same list. I respectfully disagree. See @lauriii's last paragraph in #31. He is able to back this up using user testing! Plus, XB is his product vision.

(Whenever there's something subjective, especially opinions likely rooted in past Drupal experiences, I try to silence my own opinion and defer to @lauriii. He did the product research, he is involved in the user testing, he knows what he's doing 😊 There's plenty of decisions to be made beyond those subjective bits!)

RE: — no, we can't. We can't test every contrib/custom module. We know that EVERY module in existence that integrates with node would need to be adjusted. It's simply far safer/more reliable to avoid all those problems. EDIT: See @mglaman's second paragraph + last 3 paragraphs in #36 I 💯% support.

I guess the beauty of open source is being able to express your opinions and thoughts and try help in the ways you can :)

💯 😄

There's plenty of things where I don't agree with @lauriii or the designs, but I also acknowledge A) the need to keep moving forward, B) my myopic POV compared to the much broader view that @lauriii and the designers have! (Hence my "Whenever …" remark above.)

@pameeela in #37:

overall it seems like this decision is being made wisely.

😊 Hear hear!

@mglaman WDYT about my 3 suggestions on the MR? I asked a few more clarifying questions too. I think we're on the same page, and we can get the number of unresolved MR threads down by quite a few 😊

My initial reaction to this was just a big -1, because we already have nodes and surely this would just confuse users. Also, the requirement of DER would mean that if XB is in core, DER would also become a core module, and I'm not sure it's ready for that. But, after reading the great discussions here I am now leaning the other way - I think there is definitely some value in separating standalone "landing pages" from modelled content - as long as we do this with some tight guardrails to ensure good UX. There's already been the discussion that we don't allow fields on this new entity type, but I also think we explicitly shouldn't allow bundles of this new entity type unless we have a specific use case that requires it.

The IS also suggests permissions to opt out of this. Instead I think that this should not be rolled into the main XB module and should become a standalone submodule. Then sites can have either this module, or node.module, or both installed, as they see fit - but I don't see a reason that we should force this to be available if someone doesn't want it.

I had more comments based on the IS, such as renaming the entity type ID, but it seems that's already been addressed in the MR - so tagging for an IS update.

Assigning to handle loose threads.

I'm going to just delete most of the issue summary and point to the ADR. The issue summary was drafted before the ADR was created. I don't want to have to keep updating two sources.

Instead I think that this should not be rolled into the main XB module and should become a standalone submodule. Then sites can have either this module, or node.module, or both installed, as they see fit - but I don't see a reason that we should force this to be available if someone doesn't want it.

I will update For 1.0.x we may remove the content entity type... to be about moving the entity type into a submodule.

It looks like feedback on MR has been addressed.

@mglaman The feedback has been getting more to the specifics so it's fine if you want to start work on this.

@longwave in #39:

but I also think we explicitly shouldn't allow bundles of this new entity type unless we have a specific use case that requires it.

💯 — can't believe I hadn't thought yet of making that super explicit! But that's definitely how I've been reading this issue/ADR 😊

Instead I think that this should not be rolled into the main XB module and should become a standalone submodule. Then sites can have either this module, or node.module, or both installed, as they see fit - but I don't see a reason that we should force this to be available if someone doesn't want it.

+1

I do wish that we had a method for using UUIDs for linking instead of entity type + ID

1. 🐛 Cannot use UUID as entity ID Needs work (CR: https://www.drupal.org/node/3458398 → ) just landed! 😄
2. Funny you ask that, because I worked on that over a decade ago: ✨ Make it possible to link to an entity by UUID Active .

@mglaman in #40:

I'm going to just delete most of the issue summary and point to the ADR. The issue summary was drafted before the ADR was created. I don't want to have to keep updating two sources.

Hear hear! 👏

I'm +1 to this proposal, will do a final pass for formatting (using backticks for example) tomorrow.

🚀 This will make ✨ Save page data form values in application state with support for undo/redo Active much cleaner to implement, because we can simply display all (base) fields from this new entity type instead of dealing with nodes before we figure out 📌 [later phase] [RESEARCH] How to identify all meta fields for an arbitrary content entity? Active .

Per #45 — thanks for identifying those connections, @balintbrews 🙏😊👍

1. I did 3 commits fixing nits.
2. ⚠️ 10 other suggestions should be reviewed and merged by @mglaman 🙏 — I don't think any of them are contentious, but they're not entirely nitpicky, so I'd rather have him explicitly apply them 😊
3. 🚨 One critical piece of information is missing: https://git.drupalcode.org/project/experience_builder/-/merge_requests/3...

Applied suggestions, thanks @wim leers. I want to clarify how in depth we should provide a suggested solution for point 3 on.

Just some thoughts on nomenclature...

"Landing page" is marketing speak. They shouldn't be the name of a content type.
"Basic page" should be reserved for simple/"basic" pages, e.g. privacy policy.

I'd suggest going with "Custom page" because this has connotations of being a one off page, rather than a type of fieldable/structured content. If we could add such a content type to Drupal CMS out of the box that should allow new users to see the difference in building a custom page (all-you-can-eat-XB) and a basic page (title, body, image).

@dunx All of that has been discussed in-depth already. I think you might've (understandbly) skipped the prior discussion on this issue. Unfortunately, the issue summary isn't perfectly up-to-date.

@mglaman I desperately want to wrap this issue up and merge this MR, but there are indeed still 2 remaining MR threads where I think clarification is needed:

• one for Entity(View|Form)Display's role in this new content entity type — I have hunches of your intent/thinking, but am not at all certain 😅
• one for how contrib modules can create such a content entity and expectations WRT updating, deleting and linking — this one I feel better about, and I left a suggestion for you to review! 😊

I misunderstood how this uses EntityViewDisplays, and @mglaman kindly pointed it out, and deduced what my concrete concern was! 🎉

So, pushed a commit that codifies the guarantee that that concern will never be violated, and left a suggestion for @mglaman to hopefully agree with: https://git.drupalcode.org/project/experience_builder/-/merge_requests/3....

This was the very last bit. Thanks for your patience. I believe this is now solid! 👍

🤩 Looks GREAT!

Once cspell and phpcs are resolved, ship it! 🚀

Thanks for your patience and attention to detail! 👏🙏

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