Implement the first real-world site template

Removing examples because I didn't do any research on things like ethics or anything controversial on their business beyond reviewing site features to quickly evaluate our needs, so I don't want to endorse or recommend anyone.

Clarifying that we may or may not need integration with all (or any) of Mailchimp, Hubspot, or Zapier. I guess we'll find out as we go along.

Blog Post
Title, body, categories/tags, author, published date -- we can pretty much reuse drupal_cms_blog for this

Does this mean actually re-use drupal_cms_blog or copy it? My initial reaction is that it would be much better if it was added as a dependency rather than duplicated, so that that different site templates and recipes in general, have a consistent blog content type (unless there's a very specific reason to diverge). Any changes would only need to be made in one place, only one content type to theme etc. It's much easier to split things later if there's a good reason to than it is to consolidate them back into one thing if they've already proliferated.

Behavior tracking

This has GDPR and general privacy implications (and front end performance implications and etc.) and don't think it should be in scope. There is plenty to get right here without adding a load of compliance work on top of it. Eventually stuff like this can be pulled in from project browser or similar.

There is no mention of XB here, is the idea to try to build this on top of XB from the beginning, or to add that in later?

"Behavior tracking "

This has GDPR and general privacy implications (and front end performance implications and etc.) and don't think it should be in scope.

Yes, we're aware. This is under "Additional features", as something we won't handle as part of the MVP. We listed them here as features we'd like to have but we don't expect to invest time for now. I've updated the summary to clarify that, I hope it helps to not derail the important conversation here which is start building the first site template. Perks of showing work in progress as early as we can ;)

There is no mention of XB here, is the idea to try to build this on top of XB from the beginning, or to add that in later?

All XB from the beginning: we're planning on launching this in Vienna with Drupal CMS + XB together and this working (site templates + the new design system/theme). We're working on figure things out: getting the new design system working with XB, and publish all the code as soon as we can.

Does this mean actually re-use drupal_cms_blog or copy it?

This means reusing it as a dependency. I think it's a good practice to depend upon existing recipes as much as possible, and build on them.

I've updated the summary to clarify that, I hope it helps

Thanks, yes that does help :) it wasn't clear whether it was 'explicitly deferred' or 'stretch goal', but can stop worrying about it now.

Team Member: Name, role, bio, social links, photo
With listing page?
Demo content: 3 fake team members

This could theoretically be re-usable for other site templates like something NGO-ish or different kinds of brochure websites.

This is great info to start. When I think about the site template idea I start to consider the UX side beyond XB. Drupal has so many options to handle the list of features, yet it also becomes challenging to unify the editorial experience. Does the microcontent need to be authored somewhere before it can be added in XB? For some of these that seems to be a yes.

A few other questions, thoughts:

Microcontent
Testimonials, FAQ

• This is resusable content, create/edit in one place, placeable in XB, other?
• What entity type are we thinking? blocks might be clunky, there is micro-content which I have not tried
• Blocks come with other Drupal things that might be confusing for editors
• Nodes are really pages, again not a perfect fit
• an FAQ is just a Q and A single item? Is it some type of accordion?

Logo Grid

• is this a set number per row, is it animated, are there controls we need to consider?

Missing features that every site should ship with?
The features listed are specific to the SaaS template, but are we missing some features that site owners just expect to be present?

• Contact form (webform?)
• Carousel (what types of settings would be req.)

It seems like a great idea to start with recipes, can we list the ones we think are relevant and see how far that gets us?

• This is resusable content, create/edit in one place, placeable in XB, other?
• What entity type are we thinking? blocks might be clunky, there is micro-content which I have not tried
• Blocks come with other Drupal things that might be confusing for editors
• Nodes are really pages, again not a perfect fit
• an FAQ is just a Q and A single item? Is it some type of accordion?

After some discussion with @pameeela in Slack, I think nodes are actually a fine fit for these, in combination with www.drupal.org/project/entity_display_route, which is slated to be merged into core but hasn't quite made it over the finish line for 11.2.

One of the major advantages of having nodes for all this is, I think, that editors can find all of their content, including the "micro-content", at /admin/content. Rather than having to search for it in different places of the admin UI.

Beyond the need for a shim module to suppress the page display for these content types, I can't see much advantage offered by blocks (or something else) over nodes.

As for the missing features, those are are not in the defined (settled) scope, so they could maybe be added later, but won't be in the initial version of this template unless @pameeela or @ckrina asks for it. :)

Carousel (what types of settings would be req.)

This is a feature that will require proper discussions and will come with a lot of implementation opinions (who doesn't have an opinion on carousels here! :D ) so given the amount of more important things we need to solve I'd prefer to postpone the carousel/slider implementation until we start with the next site template.

100% agree on the carousel, but that also means we leave off of the design system for now.. again fine.

I don't think we can ship any template without some type of contact form. Do we want to look at webform or something simpler? I am all for watching scope very closely.

We already have a contact form as part of the drupal_cms_forms recipe, so the site template will simply reuse that as a dependency.

ah yes! okay drupal_cms_form recipe will do! We were already styling webforms! thx!

I've removed the microcontent heading from the IS. Although I can see a use case for having testimonials and FAQs being reusable, it adds a lot of complexity to the content model, and for me does not add much value. In other words, I think it's possible but not that common that a site may want to reuse these but I don't think it meets the 80% threshold and therefore does not feel like MVP.

The features listed are specific to the SaaS template, but are we missing some features that site owners just expect to be present?

Not sure whether it has been made explicitly clear but we assume that Drupal CMS will provide this basic functionality for all of the templates that we develop. There are definitely things missing from Drupal CMS itself on this front but we should aim to add them there rather than in each template so they are consistent across sites that use it.

After some discussion with @pameeela in Slack, I think nodes are actually a fine fit for these, in combination with www.drupal.org/project/entity_display_route, which is slated to be merged into core but hasn't quite made it over the finish line for 11.2.

entity_display_route doesn't have a full release, nor is it covered by the security team. Do we need to break out an issue for that? Looks like the core issue, ✨ Support adding additional routes for view modes other than 'full' Active is blocked by a path and pathauto issue.

#17 is talking about not having those items as microcontent, would that in turn mean that entity_display_route isn't necessary?

The module was just a sandbox, I shouldn't have linked to it initially. The intention is to get this into core in ✨ Allow disabling a route for a bundle and adding additional routes for view modes other than 'full' Postponed .

phenaproxima → closed merge request !549