As the title says: What are your default modules, to start a project with Drupal 10? And which core modules can or should be disabled?

I'm interested in the general (opinionated) ecosystem, but especially interested in simple, non-bloated modules for privacy (GDPR compliance), security, accessibility and performance.

Some context:

I'm learning Drupal for a few months now and I tested many core and contrib modules. Searching online is a bit annoying, because many tutorials point to outdated v7 modules. Using the search function on drupal.org revealed, that only 8.000 modules are compatible with v10. Looking at the usage stats doesn't say anything about the quality or if core modules provide the same functionality by now. So I normally check the issue section first, than I have a look at the source code and than I give a module a first try. Some opinions and recommendations hopefully speed that process up.

My use cases (for now):

  • simple portfolio sites (a few pages, image galleries, contact form, eventually product pages)
  • blog (a few pages, focus on articles)
  • small/medium sized sites with a few post types (e. g.: page, article, product, member)
  • forms (contact, registration, newsletter subscription)

To get started - my personal list:

My disabled core modules:

  • automated_cron - it took a while until I noticed why my test site loaded soooo slow
  • big_pipe - I don't understand it - probably useful for sites with many registered users, but not if 99.9% of the requests are from anonymous users
  • contact - disabled because of hard coded routes to /contact and /contact/{name} - might become a must-have again in combination with contact_block, field_validation and a few other modules - needs more tests

Comments

ressa’s picture

I also disable Automated Cron and Contact. In three recent Drupal 10 projects, I have used these modules in two or all three of them:

I recommend the PhotoSwipe module for Lightbox-style galleries, see Comparison of Lightbox-type modules.

For newsletters, Simplenews is great. I use Postmark with Drupal Symfony Mailer to send (see Send mail with Postmark).

raffaelj’s picture

I didn't look through the whole list yet, but devel and webprofiler are definitely game changers.

ressa’s picture

Yes, they are incredible. If you haven't already, also check out how Devel can generate dummy content:

devel-generate:                                                                                                                       
  devel-generate:content (genc)  Create content
  devel-generate:media (genmd)   Create media items
  devel-generate:menus (genm)    Create menus
  devel-generate:terms (gent)    Create terms in specified vocabulary
  devel-generate:users (genu)    Create users
  devel-generate:vocabs (genv)   Create vocabularies

Simply running drush and going through the list of commands can be very inspiring.

drush topic is another great way to explore Drush.

bendqh1’s picture

First I think that Drupal 10 requires much less modules than Drupal 7 for example.

For my personal one-person Drupal 10 projects, just two modules are normally enough, Context and Webform.

Some people may need some XML sitemap module but I prefer manual crawling requests in Google Search Console over relying on a sitemap but if you have more than 100 webpages yeah in many cases a sitemap is nice and can help.

Some people may need some meta tags module but in many cases I think a good <H1> tag and a good opener passage and a good URL alias are enough. I think metatags are to some extent a thing of the past with all the artificial intelligence anlysis of webpages from search engines nowadays.

raffaelj’s picture

Can you eleborate on use cases for the context module? I read the project description multiple times and I don't get it. It looks like the visibility rules of blocks. Is it maybe obsolete in current Drupal versions?


Some people may need some XML sitemap module but I prefer manual crawling requests in Google Search Console over relying on a sitemap but if you have more than 100 webpages yeah in many cases a sitemap is nice and can help.

Sure, it depends on the size of your site. But it's also useful for automated and manual tests. I have a script that runs a lighthouse test on all pages listed in the sitemap so I can fix errors on localhost before publishing. But I'm actually rethinking how useful a XML sitemap is. To match WCAG AA and AAA, a site map should be provided. To avoid duplication, a HTML sitemap might be the better choice.

Some people may need some meta tags module but in many cases I think a good <H1> tag and a good opener passage and a good URL alias are enough. I think metatags are to some extent a thing of the past with all the artificial intelligence anlysis of webpages from search engines nowadays.

I agree on using semantic markup and text written for humans instead of duplicating content in <meta> tags. But I strongly disagree on the "AI" part. Google and Bing are eating themselve by subsidizing expensive and energy hungry chat bots, that are heavily used for polluting the internet with SEO spam and misinformation. Providing machine readable markup and meta tags helps curating the web with alternative software.

bendqh1’s picture

I personally use Context to hide certain regions (such as the sidebar region) in certain content types (such as the homepage content type).

Another possible reasonable use, if I am not mistaken, is setting another theme for a specific user-role, so for example if you are the admin, you could use another theme, different than the default theme for generally all users, but I once had a case where I had set a theme which had an error and I had to sovle the error to come back to use the site regularly myself (all that time, the site kept working regularly for all other users) so one should be careful with setting a theme for a user-role with Context.

raffaelj’s picture

Thanks. This sounds interesting. For hiding regions or blocks based on conditions I would have used twig templates of preprocess functions. Good to know, that there are other options.

jaypan’s picture

raffaelj’s picture

The link to Advanced CSS/JS Aggregation is broken. You wrote dgo.ti instead of dgo.to.

Also it looks like advagg is mostly obsolete (and partially incompatible) since Drupal 10.1.0 - see: #3308099: Document which parts of the module are still relevant after aggregation changes in 10.1.0

mc2yit’s picture

I like Schema.org MetaTag-Module for rich snippets in the Google SERPs: