🇩🇪Germany @breidert

This was fixed and can be reviewed on /documentation/image-credits

breidert → created an issue.

Here is a screen recording of the current status: https://www.drupal.org/files/issues/2025-01-14/screen-capture-drupal-cms... →

When testing you might want to delete the content that comes with individual recipes fiest:

#!/bin/bash

# Define the recipes to delete content from
recipes=("drupal_cms_blog" "drupal_cms_case_study" "drupal_cms_events" "drupal_cms_news" "drupal_cms_person" "drupal_cms_project")

# Find all directories matching the pattern recipes/*/content
for folder in recipes/*/content; do
  for recipe in "${recipes[@]}"; do
    if [[ "$folder" == *"$recipe"* ]]; then
      echo "Deleting folder: $folder"
      rm -rf "$folder"
      break
    fi
  done

breidert → created an issue.

I think we should close this issue and start a new one.

We have already started to work on demo content, it is getting quite nice: https://www.drupal.org/project/drupal_cms_demo_content →

From my perspective there are several aspects to the topic of content strategy.

1. Information Architecture / Data model - how we create content recipes
2. Demo content - presenting demo content
3. On-boarding new users - through demo content and explanations

I suggest closing this issue and start new ones.

This works correctly.

For blog and news items it is still showing.

For testing you can enable demo content, then you have content for all content types. When searching for 'drupalcon' you see news and blog items:

ddev composer require drupal/drupal_cms_demo_content
ddev drush recipe ../recipes/drupal_cms_demo_content
ddev drush recipe ../recipes/drupal_cms_search
ddev drush sapi-r
ddev drush sapi-i
ddev launch /search?text=drupalcon

I reviewed and it looks good.

For reviewing I went to https://www.1xinternet.de/en/drupal-cms-start-demo and started a full demo with demo content for a better search experience.

Initially the search is only in the sidebar, because the main menu is crowded. For testing the search with the desktop menu I disabled some menu entries.

All search UIs look nice.

Updated testing instructions

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Updated testing instructions

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Updated testing instructions

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Updated testing instructions

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Updated testing instructions

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Documentation for user management was provided.

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Documentation foverview was provided, but needs more work.

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

Documentation for content management was provided, but needs more work.

Testing locally:

1. Install Drupal CMS locally following the instructions in the README.md of the project
2. Require demo content recipe: ddev composer require drupal/drupal_cms_demo_content
3. Re-install with demo content: ddev drush si ../recipes/drupal_cms_demo_content

Tesing using Drupal CMS online demo:

1. Go to https://www.1xinternet.de/en/drupal-cms-start-demo
2. Request demo with demo content (default option)

breidert → created an issue.

breidert → created an issue.

breidert → created an issue.

Initial content was provided, FAQ content as of today.

breidert → created an issue.

lostcarpark → credited breidert → .

Demo users based on the ambitous user personas from the concept document were created.

Testing locally:

Get the latest code for Drupal CMS.

Fetch and install drupal_cms_demo_content → recipe: composer require drupal/drupal_cms_demo_content

Install site using recipe: drush si ../recipes/drupal_cms_demo_content

An initial startpage was created.

Testing locally:

Get the latest code for Drupal CMS.

Fetch and install drupal_cms_demo_content → recipe: composer require drupal/drupal_cms_demo_content

Install site using recipe: drush si ../recipes/drupal_cms_demo_content

breidert → created an issue.

breidert → created an issue.

The errors reported in 5. and 6. were fixed.

Testing locally:

Get the latest code for Drupal CMS.

Fetch and install drupal_cms_demo_content → recipe: composer require drupal/drupal_cms_demo_content

Install site using recipe: drush si ../recipes/drupal_cms_demo_content

Testing locally:

Get the latest code for Drupal CMS.

Fetch and install drupal_cms_demo_content → recipe: composer require drupal/drupal_cms_demo_content

Install site using recipe: drush si ../recipes/drupal_cms_demo_content

Testing locally:

Get the latest code for Drupal CMS.

Fetch and install drupal_cms_demo_content → recipe: composer require drupal/drupal_cms_demo_content

Install site using recipe: drush si ../recipes/drupal_cms_demo_content

Projects were created:

1. Strengthening Drupal: Advancing Security and Developer Tools with $300,000 STF Funding
2. Drupal Steward
3. Defend Iceland

breidert → created an issue.

Three news items were produced. The news items were taken from DO.

1. Nominate someone for the 2025 Aaron Winborn Award
2. See Your Design in Print - Enter the DrupalCon Atlanta T-Shirt Contest
3. Drupal CMS: Groundbreaking New Version of Drupal Detailed at DrupalCon Singapore 2024

No more work in this issue. The other content will be produced in separate issues.

Three case studies were created:
* Defend Iceland (presented in a keynot at DrupalCon Barcelona 2024)
* Drupal Steward
* Drupal secures funding from STF

I added photos for all projects and neutral descrioptions.

I am not sure if the approach is safe.

If you switch windows before the next save interval (e.g. 60s), then your form is not saved.

I think that you should first stop saving, if the document has been hidden longer than the interval. Then you are sure that the last change was saved.

phenaproxima → credited breidert → .

breidert → created an issue.

Here is the document for collaboration: https://docs.google.com/document/d/1TWnkxRddEOqWdBo8AGEibLeUUBs242wQmP8Y...

breidert → created an issue.

I can confirm it works. For testing I pulled the latest version of 1.x branch and ran ddev rebuild. After installation of News recipe I could create two news with the same tag.

breidert → created an issue.

breidert → created an issue.

breidert → created an issue.

Here is a demo environment with the content installed: https://0721093074197b5.qaack.1xinter.net/ (admin/admin). Feedback is appreciated.

I setup the recipe and created the following content:

Nodes:

1. Blog post: DrupalCon Lille 2023 Recap: A Celebration of Drupal's Journey, Community, and Future
2. Blog post: DrupalCon Barcelona 2024: A Transformative Milestone for Drupal
3. Event: Drupal Mountain Camp 2025 – Open Source on Top of the World
4. Event: Join Us at DrupalCamp Spain 2024!
5. Event: Join DrupalCamp Berlin 2024: November 8-9, 2024

Images:

1. DrupalCon-Lille-2023 - credit-Bram-Driesen.jpg
2. Group of women standing on a stage. DrupalCon-Lille-2023-Women-in-Drupal - credit-Bram-Driesen.jpg
3. Large group of people at DrupalCon Barcelona 2024 posting for a group photo. DrupalCon-Barcelona-2024 - credit-Bram-Driesen.jpg
4. Screenshot of website for DrupalCamp Berlin 2024. Screenshot_drupal_camp_berlin_2024.png
5. Empty stage ready for a presentation seen from a filled audience. DrupalCon-Lille-2023 - credit-DrupalCon-Europe.jpg
6. Screenshot of website for DrupalCamp Spain 2024. Screenshot_drupal_camp_spain_2024.png
7. Screenshot of website for Drupal Mountain Camp Switzerland 2025. Screenshot_drupal_mountain_camp_2025.png

Tags:

1. DrupalCon
2. DrupalCamp

Please test if everything works and is setup correctly.

breidert → created an issue.

Hej Tony,

I second the idea of having an internal taxonomy to classify media. This allows editors to organize their media as they want.

Regarding copyright (for me this is the same as creator, credit etc.) I would also recommend using a taxonomy. IMO the copyright field should not be mandatory but display in the frontend if it is set.

I don't think a caption field should be part of the media entity itself. I think the caption is more of a contextual thing and should be entered when the media item is added on a page.

We use above data model and conception in most of our projects.

Please also add styles for facets. Currently facets is not part of the search recipe due to uncertainty in data model and content strategy. But was already created and is working.

To install facets do the following steps:

1. Pull branch somewhere (for example in test folder):

mkdir test
cd test/
git clone git@git.drupal.org:issue/drupal_cms-3488715.git

2. Copy the recipe from the branch to the recipes folder in Drupal CMS:

cp -rp recipes/drupal_cms_search_filters/ ../../recipes/

3. Add core patch for config actions for views to composer.json of Drupal CMS: https://git.drupalcode.org/project/drupal_cms/-/merge_requests/266/diffs...

"#3305859: Add config actions for views": "https://www.drupal.org/files/issues/2024-11-15/3305859-views-config-actions_0.patch"

4. Require modules:

ddev composer require drupal/facets:^3.0
ddev composer require drupal/better_exposed_filters:^7.0

5. Delete code and re-install with composer

rm -rf web/core
rm -rf vendor
rm patches.lock.json
ddev composer install

After this, when you to to /search you should see the facets

Great work, thank you Mike. I only found some minor errors.

Steps to reproduce:

1. Install and enable recipes for review

git clone git@git.drupal.org:issue/drupal_cms-3489037.git
cd drupal_cms-3489037/
ddev start
ddev drush site:install --yes
ddev drush recipe ../recipes/drupal_cms_blog
ddev drush recipe ../recipes/drupal_cms_events
ddev drush recipe ../recipes/drupal_cms_search

2. Create example content

3. Test desktop and mobile resolution

Results

Desktop resolution

Autocomplete works well:

Search also works well, but I would recommend to decrease the space between search results (views rows):

I personally think the styling of the autocomplete looks nice in the header, but I feel it should styled differently on the search result page:

However, for some reason autocomplete in the header only works when you are logged in.

When you are not logged in there is an error:

The error is search-wide.js?snyum7:21 Uncaught TypeError: Cannot set properties of undefined (setting 'searchIsVisible'). The link to the code is: https://git.drupalcode.org/issue/drupal_cms-3489037/-/blob/search-wide-s...

Mobile resolution

For mobile I found a bug, when you type in the search menu, the autocomplete is not visible. I think this is a z-index problem.

On the search page autocomplete is accessible, but the alignment seems to be off:

The search itself works nicely on mobile resulution.

How to proceed

As I see it three things should be fixed to create a good experience for search:

1. Fix autocomplete for non-logged-in-users
2. Fix styling of autocomplete in header for mobile resulutions
3. Style autocomplete differently in the search area

I can live with the spacing of the search results not being updated.

The styles from the patches in #6 look nice. The styles I provided are only for reference. I tried to comment them as good as possible, so it is easy to understand what should be styled.

Looks good :-)

I tested it and it works fine. I made a small change to the description of the toggle, so users can easily find the search page.

breidert → created an issue.

breidert → created an issue.

breidert → created an issue. See original summary → .

Setting to fixed for closing.

Even though conceptionally 🌱 Specification document for Advanced search in Drupal CMS Needs review it was planned to develop a separate recipe for the search backend and a views based frontend, both were done in the same issue (search backend) 📌 Add recipe for search backend Active .

The search is missing styling. This will be handled in the subtheme of Olivero 📌 [Meta] Plan for Olivero subtheme Active and organised in separate issues.

Yeah, let's collaborate and make it available to all contributors to Drupal CMS.

I agree with the translation settings:

Translation settings:

• Entities Types such as Nodes, Taxonomy Terms, Media Types, will be translatable.
• Basic fields such as, Textfields, Textareas, will be translatable
• Entity reference fields such as reference fields to taxonomy terms or media types, will not be translatable.

This is how we at 1xINTERNET build translation, too.

Maybe your recipe could work in a generic way that works by field type. Then your recipe could be applied to arbitrary content types. I guess this could work, if we agreed on a field naming convention. Maybe this could also solve your consideration regarding SEO fields. If they followed a naming convention, they would automatically be configured correctly.

For our project we always keep English as the default language, as a matter of fact we prevent changing the default language to something other than English. This has saved us a lot of time, because it prevents configuration chaos, when you introduce configuration translation.

It sounds like language detection will be based on URL, which we do as well as a default. However, we always configure with language prefix also for the default language. So for a German / English page we would have /de for the German pages and /en for the English pages and not / for the English pages in the default language.

Regarding your question about TMGMT I would suggest to leave it out of scope. We use it in many projects because it is awesome, but it is not a common thing we installe. We only install it for large clients, that have advanced translation requirements. However, having this as a separate recipe that we can use would of course be nice :-)

However, I think Interface translation and Configuration translation should be in scope. Usually, when clients request multilingual pages, they expect the interface for editors also to be translatable. Also without Configuration translation you end up having views with labels in wrong languages for site visitors. I guess when your recipe enables Interface translation and Configuration translation it does not solve the problem, that the interface and the configuration has to be translated. And who is responsible for this. Do the recipe creators for a content type that ships a view have to provide translations for their configuration? I am not sure how to best approach this.

Nice work !

#7 I dont understand the comment. My suggestion aims at the general way how content is constructed. The fact that image is not a reference field was only to make the concept easy to understand.

Image fields should always be reference fields to media entities. The same should be the case for all other media files loke video, remote video, file, etc. I did not add this to the graphics above to keep them simple.

To improve usability and consistency, as well as driving broader adoption I suggest simplifying the data model.

Simplifying the model

All content types (nodes) could be structured around the following core fields (specific naming can be finalized later):

1. Title
2. Description
3. Image
4. Tags
5. Content

In this structure, Title, Description, Image, and Tags are standard fields, while Content would be a reference field for display components (such as block types) that visually construct each page.

A streamlined data model allows for broader adoption and flexibility, enabling users to build custom structures as needed.

When introducing new content types, additional fields should only be added to reflect essential differences.

For example:

1. A News Page type could include a Date field.
2. An Event Page might add both Date and Location fields.

Display Components

Display components refer to separate entities (e.g., block types) that manage their own data models and are independently installable, with rendering managed by tools like Single Directory Components (SDC).

Basic components might include:

1. Text
2. Image
3. Page reference

Additionally, components such as

1. Headline,
2. Slideshow,
3. Gallery, and
4. Views Reference

provide users the flexibility to select or create only the components required for their use cases.

Differentiating Content Types (e.g., Press Release vs. Blog Post)

Differentiation between content types, such as Press Release and Blog Posts, could be managed through Tags, with display components handling visual differences.

For instance, a Press Release might include:

1. Title
2. Date
3. Summary
4. Text
5. Quote
6. Media contact

Whereas a Blog Posts might feature:

1. Title
2. Date
3. Author
4. Reading time
5. TL;DR
6. Text
7. Related blog posts

Structuring Pages (e.g., Projects and Case Studies)

Pages like projects and case studies could remain simple, requiring no additional fields. Their structure can be customized through display components to align with the desired information architecture.

Editorial Experience

A flexible data model paired with specific content templates can streamline the editorial workflow. Editors could duplicate a pre-configured page, adjust content, add or remove display components, and then publish.

This approach operates independently of the data model and can integrate seamlessly with editorial workflows (e.g., through a workflow module).

Supporting Functionality (e.g., Recipes for SEO and Search)

The fields Title, Description, Image, and Tags offer robust support for dependent functionalities. SEO meta tags can be generated based on these fields, and advanced search capabilities can use them to ensure effective results across content types.

This would be great for the search recipe as well. We need to rely on certain fields that are available in all content types, so we can configure advanced search correctly.

We have planned to let drupal_cms_search_base recipe to depend on drupal_cms_content_type_base. If all content types are depend on drupal_cms_content_type_base search will work for all content types out-of-the-box.

This would be helpful for large menus when using groups.

I credited everyone, but could not find this user: https://www.drupal.org/u/samit-khulve →

I credited everyone who participated except the following users:

• https://www.drupal.org/u/dimitri-baudonck →

Community survey was done, the participants were credited, and the results were published and presented in DrupalCon Barcelona.

Credit survey participants

This work was finished. All results were incorporated and validated in the survey. The recipe will be created accordingly.

gábor hojtsy → credited breidert → .

tonypaulbarker → credited breidert → .

Regarding #16 (view mode, search_api_exclude)

Yes, the view mode Search index will be indexed, compare

Note: That the view modes Search index and Search result highlighting input must have sensible fields visible. Changing this configuration will not be part of the recipe. However, the recipe will activate the view modes.

We could add search_api_exclude, which we also use in many projects, but it is a bit of a hidden feature and un-experienced users can easily miss it. My feeling tells me, that we should leave it out for the moment. But it could be added easily.

Regarding facet for content type #18 🌱 Specification document for Advanced search in Drupal CMS Needs review

We can take it out or make it a seperate recipe any time. Let's create it and take it from there.

Regarding removing core search #27

Thank you :-)

Thank you for the valuable comments and especially for the questions and doubts provided in #7 and #8.

At the moment this is just a proposal, we will see how it works, once we have created the recipes, and then they might change.

For us it would be ok, if we agreed that this is what we want to have in Starshot. If it turns out that some things cannot be included, because they are not stable enough or are incomplete, then they will not be removed from the corresponding recipes.

Regarding the factet for content type: @pameeela - you are right, there are scenarios in which a content type for facet does not make sense. But given, that Starshot does not have a data model yet (for example with a taxonomy that exists on all content types), the bundle is the only facet source we could think of. We think providing a facet makes sense, so the target personas can review, change, or build their own facets based on the example.

Regarding the issues for facets and AJAX: @catch - this is true, with the current version it is only possible to create a good solution with AJAX if you make many modifications and use patches (we have suffered from this in many projects). However, new versions are being released and there are two branches. We are in contact with @borisson_, one of the maintainers, and we think that we can provide a version for Startshot that will work nicely. The worst that could happen, is that we dismiss facet functionality with views.

The specification and scope document needs review.

Please add your remarks and suggestions as comments in this issue.

You can also have comment access to the Google document, please request it in a comment.

The version as reviewed and now needs feedback

breidert → created an issue.

breidert → created an issue.

breidert → created an issue.

breidert → created an issue.

breidert → created an issue.

First version of document was created: https://docs.google.com/document/d/1GzrWO2gLUAIeWDHBGOuXnbOpAdM9q-WZGRnD...