Choose our modules and themes

[phenaproxima]

Drupal Suite, as I understand it, is Drupal core + a well-chosen collection of modules and themes, configured for maximum out-of-the-box usefulness via recipes.

This issue is to brainstorm which modules and themes we feel should make that cut, and why.

I'll start:

• Pathauto is a no-brainer and I've already added it to main, along with configuration that sets sensible defaults for the Page and Article content types that come with the Standard recipe. We'll need test coverage in main that content authors can access Pathauto's controls (i.e., we need to be sure they can manually enter a path, if desired, rather than allowing Pathauto to generate it).
• Metatag seems like a very useful one too. Every content type should at least expose a description meta tag to authors. This will also need test coverage so we know that content authors can access the meta tag fields and change them.
• Redirect also seems like a no-brainer. Creating redirects is a very common task and should be included OOTB, even if we don't need to supply any additional configuration for it. (I've already added this to main.)

[phenaproxima]

Here's another one - how about SecKit? I'm not super familiar with it, but does it actually provide useful hardening that would benefit at least 90% of sites out there? If so, I think that should definitely be in Drupal Suite's arsenal.

[goba]

I'd rather approach this a bit differently :)

1. I would look at top modules Drupal agency's customers use as a source.
2. I would look at existing Drupal demos like 1x's Try Drupal, which is a nice cohesive setup.
3. I think the long and short term goal is to be able to produce an Umami-like (or 1x's Try Drupal-like) demo on top of this, which should help guide what kind of stuff we need.
4. Talk to people working on selling Drupal about what they include in a demo now. Some companies may have an official demo environment with sample content and they may be happy to not need to maintain it / get winds in their sail of producing it.

[phenaproxima]

I took a poke around 1x's Try Drupal, and I have some more modules in my mental shopping cart:

• Autosave Form
• Scheduler
• XML Sitemap
• Coffee (admin search - added to main in f0474d0d317ec5aa22326b6da45fc778ca2b749e because this is incredibly useful when first presented with Drupal's complex administrative hierarchy).
• Webform
• Field Group
• Gin (theme - this is really sexy and has things like iOS-style toggle buttons, which seem like a no-brainer for a modern look and feel)
• Some sort of actually good previewer
• Search that transparently encompasses multiple entity types - this means Search API.

I couldn't discern much else; the demo seems pretty locked down. You don't have full admin access. Which honestly might be okay for our purposes - maybe Drupal Suite should have some kind of "normal admin" role which is not user 1, but has a curated selection of administrative tasks.

I notice that the content forms are heavily structured and based on what looks like Paragraphs. The fields seem to be divided up in terms of what they will show, and where they will show it, rather than by any underlying data structuring concerns. That seems like a good design principle for Drupal Suite - thinking in terms of what the final display is like, and which knobs need to be twiddled to fine-tune that, rather than thinking primarily in terms of the data modeling. "Preview", "Header", and "Content" are configured as separate sections, with the latter two basically done as paragraphs (I think).

I personally don't believe in Paragraphs due to its performance problems, but I think a similar thing could be done using Field Group and some special sauce to make grouped fields act like cohesive "sections".

Key among the offerings, I think, are the variety of useful paragraph types. Stuff like "Accordion", "Gallery", "Two Columns", "Slideshow", "Image", "Remote Video", etc. You could add these to content anywhere that was powered by Paragraphs. I think that offering useful components like this will be absolutely critical for Drupal Suite to be truly useful.

[phenaproxima]

Adding https://www.drupal.org/project/responsive_preview to the bucket. Super cool, super useful. We need some good preview modules.

[phenaproxima]

I think Focal Point should be here. Subjectively, it's a very popular and intuitive solution for cropping.

[phenaproxima]

https://www.drupal.org/project/workbench_email is a worthy one too. I think this is pretty standard functionality - when you change a moderation state, you may want to let someone know.

[phenaproxima]

How about Moderation Sidebar and Moderation Dashboard? Both great tools for managing moderated content - which, as of this writing, applies to all content types shipped with Drupal Suite.

[phenaproxima]

I've added Admin Toolbar in f70653d1d9df62b14ff8f6add8e76b5d4a6cf69c. This is used by 250K sites and makes the toolbar a lot more useful. It's a no-brainer.

[mandclu-acquia]

A couple of notes here:

• The Navigation project is meant to be the next-gen admin toolbar, and is also currently baked into the Gin admin theme as an experimental feature. I'm not sure either route will be mature in time to replace Admin Toolbar, but something to keep an eye on
• Open Y is a popular distribution, albeit for a specialized use case (used by a variety of YMCA orgs). I played around with it a couple of years back and was impressed in the way it handled being able to drop in demo content and then (IIRC) remove it later. Open Y might also be a good reference for best practices since it is very actively maintained
• One other module to potentially consider is Smart Date, which provides a more intuitive widget and better date formatting than the core date fields
• The Event - Condition - Action or ECA module can provide similar functionality to Workbench Email but is much more flexible, and can also be used for various other use cases. It can also work with the Easy Email module to send HTML-formatted emails
• The Gin admin theme also has companion modules that should be considered if the theme were to be included: Gin Toolbar, Gin Login, etc
• Linkit provides a much better way to manage links in a WYSIWYG
• On the topic of previews, Same Page Preview is worth a look
• For sites NOT using paragraphs, the Storage module can provide a easy way to support more complicated content structures without creating a bunch of content types for information that isn't meant to be accessed directly. It also works very nicely with Inline Entity Form
• The use of modern image formats like SVG is increasingly common, so something like SVG Image Field would also make it easy for site owners to follow best practices

[phenaproxima]

The Navigation project is meant to be the next-gen admin toolbar, and is also currently baked into the Gin admin theme as an experimental feature. I'm not sure either route will be mature in time to replace Admin Toolbar, but something to keep an eye on

Wow, I didn't even know about Navigation. Super sexy! I have swapped out Admin Toolbar in favor of Navigation (in 4cac8c5b566f2440b4efd877aa02e277b7b283a8). Full steam ahead!

[phenaproxima]

Tried Linkit and I 😍 it. That is vastly superior to core's OOTB linking in WYSIWYG editors, so I added it by default in b6e23d8d6b375426a477c2ffb9a4741a72540c39. (Note that this necessitated some custom support code, which we might be able to move to the main recipe system, but it will take some refactoring.)

[mandclu-acquia]

One other quick note, Smart Date's configuration kits are now available as recipes: https://www.drupal.org/project/smart_date_starter_kit/releases/3.0.0-beta1 https://www.drupal.org/project/smart_date_calendar_kit/releases/3.0.0-beta1

[phenaproxima]

How about Entity Usage? It's used on 40K sites and as a (lapsed) media system maintainer, I often hear the question "how do I know where media is being used?" An entity usage system would be useful for content editors on larger sites, and is a great candidate for core inclusion.

[phenaproxima]

I added Scheduler in ba0a34bcb8c8a36449db4122ac30a9ea6d4378e8, and enabled it for Page and Article. I think that the ability to schedule content is a no-brainer, and as far as I know, Scheduler is the most popular module for that.

[phenaproxima]

Project Browser and Automatic Updates should definitely be here. The ability to install extensions using Project Browser is critical, and Automatic Updates provides the underlying support code (Package Manager). The ability to actually do automatic updates is less critical, but the module is stable, so I don't see any reason not to include it. Starshot can also take advantage of the newly-stable Automatic Updates Extensions sub-module. (cc @tedbow)

[phenaproxima]

Also, a thought - what about the Contact Storage module? Contact forms' emails might be lost if there's an email outage, so perhaps it's worth having a redundant database backup by default?

I also think we will DEFINITELY need some kind of CAPTCHA or anti-spam module(s). Any suggestions on that front?

And speaking of the ability to send emails -- the SMTP module might be a reasonable addition. Some hosts now will not have sendmail available or installed, so we can't necessarily rely on Drupal's ability to send email directly from the server it's running on. The SMTP module provides the plumbing to use an external SMTP service, like SendGrid. To me that's crucial.

[tedbow]

@phenaproxima Project Browser needs a new release to be compatible with Automatic Updates. There hasn't been a release since September 2023. I tested out the 1.0.x version though and it worked though. I asked in Slack if they could make another release.

[phenaproxima]

I added Focal Point in 95403088895b17960736e0bdc1ec0089e9c6eb15, and made the Image media type use it in the media library by default. There aren't currently any image styles using it, but that can come later. Being able to set the focal point is a really intuitive style of cropping, and Focal Point has the usage numbers to back that up.

[phenaproxima]

Smart Date was added in 233f71b71b1763faba632fda2492894d745b58e2, and Webform was added (replacing core's Contact) in f71d364a8e6b2658ee6807983b30754ab09439b0. Gin is now the default admin theme, as of 28fa2db1dbcbf3420c56f64a0d4a3055d2608481.

[phenaproxima]

After consulting with @mandclu-acquia on Slack, I added Simple Sitemap and enabled it for all content types in 5eeac927b8cc3b88d837c55b354183da788dd193.

[phenaproxima]

I added Media Entity Download (although not integrated with LinkIt, which I ran into trouble with due to upstream bugs) and Media File Delete in fbddd7b798f0d46904565f1753e4f2e648576fd9. To me, these seem like table stakes modules for file-based media types.

[pameeela]

Couple of other media helper modules: https://www.drupal.org/project/media_library_edit https://www.drupal.org/project/media_entity_file_replace

And some others to consider: https://www.drupal.org/project/chosen https://www.drupal.org/project/entity_clone (most CMSes include clone functionality OOTB) https://www.drupal.org/project/easy_breadcrumb https://www.drupal.org/project/views_bulk_operations https://www.drupal.org/project/views_bulk_edit

[pameeela]

https://www.drupal.org/project/menu_block

[larowlan]

I was pretty sure menu_block functionality made it into D8 a long time ago - what does it still provide?

Replicate module is a competitor to Entity clone that is worth a look, several core maintainers involved in it.

[pameeela]

Oh nice, didn't know about Replicate! Re: menu_block, fair question, I just looked through a few projects for what modules we were commonly adding. Per the module page:

And this Menu Block module provides additional configuration so you can choose to expand all menu links with children or to root the menu tree to a specific menu item.

Maybe not essential!

[phenaproxima]

+1 on adding a clone feature. That's absolutely something that's table stakes for a CMS.

When it comes to the choice of Replicate vs. Entity Clone, I'm inclined to go with whichever one has more installs. But if Replicate has core maintainers behind it, that factors in too -- especially if there's any plan for it to go into core at some point.

My feeling is that Entity Clone is the one to choose. I think that the very Drupal-ey "you can clone any entity!" pitch of Replicate is overkill -- I assume that the overwhelming majority of CMS users are going to want to clone content only (maybe also content types), and it won't even occur to them to clone things like media or taxonomy terms (the value of cloning those things is dubious anyway). Replicate also says it is developer-focused, which isn't really the target audience for Drupal CMS. A simple clone feature in the UI is what I'm aiming for.

I'll give both a try tomorrow and see which one feels better to me.

[phenaproxima]

About Media Entity File Replace -- the project page has this to say:

The Media Entity Download module solves the same core issue in a different way. Instead of worrying about what the actual filename/path are on the site, documents are expected to be accessed via a special vanity URL based on the ID of the document (which never changes, even if replacing the source file). The downside to this approach is that the document is that Drupal is bootstrapped for every request for a public document, consuming valuable resources.

Media Entity Download is already in Drupal CMS as of today (fbddd7b798f0d46904565f1753e4f2e648576fd9). If it solves the same problem, then adding Media Entity File Replace -- which is incompatible with revisions, according to its page -- is redundant. The fact that Drupal has to bootstrap is, IMHO, an acceptable trade-off for the consistency it provides.

[pameeela]

Just had a quick look at Replicate and UX-wise, they are pretty similar. Entity Clone enables selecting which child entities to clone but you can (and should!) disable this, which simplifies the process.

Here's a comparison of the functionality in the UI:

No strong preference from me, I only suggested EC because it's what I've used before.

[pameeela]

If it solves the same problem, then adding Media Entity File Replace -- which is incompatible with revisions, according to its page -- is redundant.

Agreed, it's definitely redundant with the combo of Media File Delete and Media Entity Download (this one is new to me!).

[phenaproxima]

I added CAPTCHA in bc1788761bc1b82e776c6d719b614c05ee38bf6a. I'd like to add it to the contact form provided by Webform, but Webform's API is frankly scary and it's not clear how I can easily write a config action to, like, add an element.

[pameeela]

I'm quite anti-captcha for a few reasons, strongly recommend https://www.drupal.org/project/antibot instead. Much easier to set up and we've found it works as well as captcha and without the annoyance.

[phenaproxima]

That looks like a good choice too; the points I can see in CAPTCHA's favor, compared to Antibot, are:

• It's got a lot more installs.
• Antibot says that it's based on waiting for a user to interact with the page by mouse movement, key press, or touchscreen swipe. This feels like something that could easily be defeated by a bot that uses, say, Chromedriver to do some kind of randomized human-ish movement on the page before filling out and submitting the form. So how foolproof is it?

That said, Antibot also says you have to specify which forms to use it on. That's probably not the greatest choice for, say, Webform...but I can definitely see the usefulness of this for all other administrative forms, like the /user/login page. Maybe both modules would be good additions to Drupal CMS.

Thoughts? Maybe worth opening a different issue to discuss?

[thejimbirch]

As far as cloning goes, I would like to add another module for consideration.

https://www.drupal.org/project/quick_node_clone Very simple functionality and UI.

I haven't use Replicate, but it is a lot simpler than the Uber powerful Entity Clone, and has the most uses.

[goba]

1x Internet's https://www.drupal.org/project/content_templates is also based on Quick Node Clone.

[phenaproxima]

I'm going to try it out today, but based on what I'm seeing, I'm leaning towards Quick Node Clone. This has the proper scope, IMHO, and a respectable number of installs, and a relatively recent release.

[phenaproxima]

Added Quick Node Clone in 7776e093d625c61ff0e1324e4a1aedefff7b53f1. I think the small scope and straightforward functionality is exactly what most folks will be looking for in a CMS.

[phenaproxima]

Gave it a quick try, and I agree with @thejimbirch that Diff is essential if you're dealing with revisions (and all of Drupal CMS's content types are revisionable). So I added it in d694bbde09854f2c38672b8d9b908cedb0d946f1.

[pameeela]

+1 to Quick Node Clone, I think for this use case, we definitely want the simplest working version of the functionality.

[pameeela]

BEF has come up in a few of our discussions as a module that provides a really useful feature set without adding much risk/complexity. https://www.drupal.org/project/better_exposed_filters

And if we add that I would also suggest https://www.drupal.org/project/selective_better_exposed_filters which we use a lot (and probably would use more if it didn't require installation separately!).

[phenaproxima]

Thanks for all the great discussion and suggestions in this thread, everybody!

I think it's grown to be pretty long, and there are plenty of good ideas that I've already adopted, and other ideas that I think bear further discussion and consideration. I'm going to close out this issue; let's suggest/discuss/adopt additional modules in separate issues.

[gitressa]

Search that transparently encompasses multiple entity types - this means Search API.

This would be awesome, and give Drupal a much better search solution out of the box. I just saw @catch56 adding a comment in Search Initiative: Reduce bus factor of Search ecosystem and improving core search by adding base components of Search API to Drupal Core and I hope it can happen, one way or the other.

Maybe adding Search API needs its own dedicated issue here in the Starshot issue queue?