Drupal News

I'd like to set a variable in my node.html.twig template:

{% set title = label %} {{ content }}

The content consists of one field visible only, which has it's own template:

file-link.html.twig

How can I access the title variable of the node template in the file template? I am not sure if importing or extending is the right way since that might cause infinite recursion?

Edit

The file template looks like this (from the bootstrap theme):

{% spaceless %} {% set classes = [ icon_only ? 'icon-only', not icon_only ? 'icon-' ~ icon_position|clean_class ] %} <span{{ attributes.addClass(classes) }}> {% if icon_only %} <span class="file-icon">{{ icon }}</span> <span class="sr-only"> <span class="file-link">{{ link }}</span> <span class="file-size">{{ file_size }}</span> </span> {% else %} {% if icon_position == 'after' %} <span class="file-link">{{ link }}</span><span class="file-size">{{ file_size }}</span><span class="file-icon">{{ icon }}</span> {% else %} <span class="file-icon">{{ icon }}</span><span class="file-link">{{ link }}</span><span class="file-size">{{ file_size }}</span> {% endif %} {% endif %} </span> {% endspaceless %}

Within that template I'd like to print the title of the respective node:

<span class="file-link">{{ link }}</span> <span class="file-node-title">{{ title }}</span> {# << #} <span class="file-size">{{ file_size }}</span>

I'm using the views_rss module in Drupal 6. Whenever I build out a View using this plugin, the following header is sent in a template_preprocess function:

drupal_set_header('Content-Type: application/rss+xml; charset=utf-8');

This seems to be ignored, as the page is ultimately sent with a text/html header. It seems that my header is getting appended, but text/html is either sent first or last (whichever is ultimately interpreted by the browser) and thus has no effect.

How can I force a non-text/html header for a page output in Drupal 6?

I'm looking to redirect users after they login.

The site is multilingual, using English and French.

I've tried using the Login Destination module and using Rules, but it has no options for accessing the language the user has chosen.

On the user edit page, the user can select 'English' or 'French' as their language.

I'm looking, ideally, for a simple rule condition to add, or some PHP.

None of the answers I've found so far have mentioned multilingual sites.

Thanks.

How can I address the challenge of automatic logouts when accessing different subdomains due to cross-domain cookies issues?

How to reproduce: Log in to the a.example.com and then access the b.example.com the cookies_session will be automatically removed.

My Drupal 9 services.yaml below:

parameters: session.storage.options: gc_probability: 1 gc_divisor: 100 gc_maxlifetime: 200000 cookie_lifetime: 2000000 sid_length: 48 sid_bits_per_character: 6 cookie_samesite: Lax cookie_secure: true cookie_domain: '.example.com'

Thanks.

I have the following .htaccess lines that only allows to visit index.php and disallows access to install.php, update.php and all other PHP files.

<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{REQUEST_URI} \.php$ [NC] RewriteCond %{REQUEST_URI} !/index\.php$ [NC] RewriteRule ^ - [F] </IfModule>

I need something like this because I have a watchdog full of page not found clutter like adminer.php, pma/index.php, /wp-login.php, /phpmyadmin/index.php, and endless other variations.

This code seems to work fine. For URLs ending with .php, it returns an Apache Forbidden page instead of the whole website. There are no records of page not found in the watchdog. Which is exactly what I need.

Is it a good idea to place this code in the .htaccess file on Drupal 10 websites? Are there any better ways to solve this problem?

I am using ubercart. I am facing two issues while creating an order from backend.

1.) How to add coupon codes on add order admin page ? i need to add orders manually from backend but not able to apply coupon codes for discounts, there is only a feature to "add a line item" but not for coupon. I think there should be a textbox to fill coupon code and apply button to apply it.

2.) If coupon is applied to manually created order then tax calculation should be done after coupon price deducted from subtotal.

I am building a site using Drupal 7, in which users can upload content in a form, also images. The images will be uploaded and stored with the Media module version 7.x-2.x-dev.

I want to allow users to upload any image up to 10 MB of size.

But, I don't want to have many pictures as big as 10 MB on my server. I prefer to save the image only after it has been resized to 800x600 to have more space on my server.

How can I achieve this with the Media module?

In addition, what is the difference between the field type "file" to "image" when rendering images with the Media module?

There is an option to chose "Field Type: File" and "Widget Type: Media Browser", and then chose rendered file, and then image on the Media settings (here is a great guide to the Media module). Another option is to chose "Field Type: image" and "Widget Type: Media Browser".

Imagine a world where installing Drupal instantly launches you into a creative experience, allowing you to build and style pages right out of the box, without any need for additional modules or configuration.

The introduction of Drupal's Layout Builder in 2018 was an important milestone toward this vision, but it was just the first step. Layout Builder provides site builders with a powerful drag-and-drop interface for creating and arranging content within customizable layouts.

Despite its success, there is a clear and pressing need to improve the existing Layout Builder. The numerous community-developed modules enhancing Layout Builder highlight the need for a more comprehensive solution.

That is why at DrupalCon Lille last year, I was excited to announce the "Next Generation Page Builder" initiative, aimed at improving and expanding the Layout Builder to provide a truly intuitive, out-of-the-box page-building experience.

Since announcing the 'Next Generation Page Builder', led by Lauri Eskola (Acquia), a Drupal Core Committer, we've done extensive research and planning.

Inspired by user feedback, we decided to make two changes. First, we decided to broaden our focus: not only will we improve the page-building features of Layout Builder, we will also integrate basic theming capabilities, enabling users to style their pages effortlessly without having to edit Twig files. Second, reflecting on this wider scope, we renamed the initiative from 'Next Generation Page Builder' to 'Experience Builder'.

In recent months, we explored several options for how to create such an Experience Builder, including accelerating development of the Layout Builder, switching to Gutenberg, adopting Paragraphs, or using the newly open-sourced Plasmic.

After thorough analysis and discussions with key stakeholders, including Automattic's Gutenberg team, the Drupal Core Committers decided the best approach is to expand the Layout Builder while also incorporating the best elements of Paragraphs.

Looking to the future, I hope the Experience Builder becomes the preferred Drupal tool for layout design, page building, and basic theming. Our main goal is to create a tool that site builders love, with an amazing out-of-the-box experience. By integrating key features from Paragraphs, we also aim to create a unified solution that reduces fragmentation, accelerates innovation, and ensures Drupal remains at the forefront of site building.

Our future success hinges on expanding Drupal's usability to a wider audience. Our CMS capabilities are often better than our competitors', but aren't always as user friendly. In the Drupal 7 era, Drupal was the OG (Original Great) of low-code but today we are being outpaced by competitors in terms of ease of use. Without user experience improvements, we'll lose ground. The Experience Builder initiative is all about introducing more people to the power of Drupal.

I feel strongly that a unified Experience Builder is one of the most important initiatives we can undertake right now.

Developing an Experience Builder is a big task that will require substantial effort, extensive collaboration, and significant expertise in user experience and design. As Drupal Core Committers, we are driven by a sense of urgency to advance this initiative. We are committed to moving quickly and iterating rapidly, but to succeed, we also need your support. There will be many opportunities for the community to collaborate and contribute to this initiative.

For more information, please check Lauri's latest blog post on the topic. Additionally, I will discuss this further in my upcoming DrupalCon Portland keynote in a few weeks.

At DrupalCon Lille 2023, Dries announced a new strategic initiative to build a Next Generation Page Builder. The goal of the initiative was to improve and expand Layout Builder to provide a truly intuitive out-of-the-box page building experience.

We have started defining what experience would look like by identifying user journeys from beginning to end, from customizing Drupal to match a brand and content strategy to creating and editing pages. We have identified that to provide the desired experience, we need to define a standardized way for builders and creators to transform designs into optimized digital experiences. To realize the Ambitious Site Builder vision announced by Dries in 2022, we are providing visual, browser-based tools that require minimal technical expertise. This will make it easier for users without prior knowledge about Drupal or coding to implement a digital experience with Drupal. Our working name for this is Experience Builder to highlight that the module seamlessly integrates a page builder and a theme builder.

With the Experience Builder, site builders can create fully customized pages and themes using no-code/low-code tools in the browser. It provides site builders, developers, and content creators a single platform to collaborate. Content creators are empowered to create and update content without having to reach out to a developer. Site builders can balance brand consistency and creative freedom by selecting which visual editor controls to expose to the content creator. As a result, anyone in your organization can easily build and update sites, accelerating time to market while remaining brand compliant.

To keep the out-of-the-box experience simple for non-technical users, Drupal will continue to optimize the experience for site builders without the need of building custom, code-based headless front ends. We are actively exploring ways for Drupal to enable JavaScript developers to work with Drupal without the need of managing a large custom code base. Meanwhile, we will still deliver capabilities that enable headless use cases and retain much of the work that has been done to enable headless use cases so far.

How should we build the Experience Builder?

The Drupal core committer team has decided to expand on our existing solutions. Incorporating the best features of Paragraphs into an expanded Layout Builder will provide a solution that can significantly surpass the existing options explored. We are still evaluating if there are smaller components that exist in other open source projects that could be utilized by the Experience Builder.

What options did we consider?

We researched the existing Drupal based page building solutions, as well as other open source projects to decide how we should realize the Experience Builder. We evaluated Paragraphs, Layout Builder, and Gutenberg using six criteria: expertise required to realize our vision, effort required to realize our vision, effort required to migrate existing sites, future-proofness of the solutions, how well it matches with our persona, and ability for market differentiation.

Gutenberg was the primary option that we considered adopting from outside the Drupal ecosystem. With the help of the Pitchburgh fund, I had couple long days of working sessions with a group of Gutenberg maintainers, as well as the team behind Drupal Gutenberg. We learned that there are many parallels between the problems the different teams are aiming to solve. However, Gutenberg is primarily built for the content creators, which is at odds with our promise to build a platform for the Ambitious Site Builders. Gutenberg would provide us a fast way to enable content creators, but would slow us down delivering on our vision for site builders.

From the Drupal-based solutions, Paragraphs has the largest user base. Site builders attribute this to its relative simplicity and flexibility to implement nearly any kind of design system. However, Paragraphs focuses solely on component composition and content composition, and therefore doesn't enable non-technical builders to control the display of structured data, or the page as a whole.

Layout Builder originally focused on providing site builders with a way to display structured data from entities using more complex layouts. For this reason, the out-of-the-box experience hasn't been optimized for content creation. As a result, some sites using Paragraphs also choose to use Layout Builder as a tool for builders to customize the page layout, leading to a less integrated UX.

All of the solutions we evaluated came with trade-offs. The core committer team decided to prioritize how well the solution would match with our Ambitious Site Builder persona and having an ability for market differentiation. Based on our research, evolving Layout Builder, and enhancing it with capabilities that exist in Paragraphs today best meets these criteria. This approach requires a lot of expertise and effort to realize our vision, in particular UX design, but makes it easier to migrate existing sites and integrate with other Drupal APIs and use cases.

Next steps

We have identified three lanes of work to implement the Experience Builder:

1. Creating a revamped user experience that is optimized for creating pages using components, as well as defining the layout for structured data.
2. Implementing a new mechanism for defining components, alongside blocks. Components can be defined through the UI as no-code components, or as code components. The experience for creating code components will be similar to Single Directory Components.
3. Implementing a browser-based theme builder that enables site builders to implement themes custom to brand without leaving the browser.

Expected timeline and call for help

The core committer team is convinced that a unified Experience Builder is one of the most important initiatives we can undertake. We are committed to moving quickly and iterating rapidly, but we need your support to succeed. We know that with the help of the community, we are able to develop a proof of concept and demo of the new user experience later this year. The first release as a contributed module is targeted for the first half of 2025.

If you are willing to help fund this project, you can reach out to Lauri or Dries. If you are willing to help with the implementation itself, we are planning to set up a recurring meeting. Join the #layouts channel on Drupal Slack for updates and opportunities to contribute!

Imagine a world where installing Drupal instantly offers a creative experience that allows you to build and style pages right out of the box, without any need for additional modules or configuration.

The introduction of Drupal's Layout Builder in 2018 was an important milestone toward this vision, but it was just the first step. Layout Builder provides site builders with a powerful drag-and-drop interface for creating and arranging content within customizable layouts.

Despite its success, there is a clear and pressing need to improve the existing Layout Builder. The numerous community-developed modules enhancing Layout Builder highlight the need for a more comprehensive solution.

That is why at DrupalCon Lille last year, I was excited to announce the "Next Generation Page Builder" initiative, aimed at improving and expanding the Layout Builder to provide a truly intuitive, out-of-the-box page-building experience.

Since announcing the 'Next Generation Page Builder', led by Lauri Eskola (Acquia), a Drupal Core Committer, we've done extensive research and planning.

Inspired by user feedback, we decided to make two changes. First, we decided to broaden our focus: not only will we improve the page-building features of Layout Builder, we will also integrate basic theming capabilities, enabling users to style their pages effortlessly without having to edit Twig files. Second, reflecting on this wider scope, we renamed the initiative from 'Next Generation Page Builder' to 'Experience Builder'.

In recent months, we explored several options for how to create such an Experience Builder, including accelerating development of the Layout Builder, switching to Gutenberg, adopting Paragraphs, or using the newly open-sourced Plasmic.

After thorough analysis and discussions with key stakeholders, including Automattic's Gutenberg team, the Drupal Core Committers decided the best approach is to expand the Layout Builder while also incorporating the best elements of Paragraphs.

Looking to the future, I hope the Experience Builder becomes the preferred Drupal tool for layout design, page building, and basic theming. Our main goal is to create a tool that site builders love, with an amazing out-of-the-box experience. By integrating key features from Paragraphs, we also aim to create a unified solution that reduces fragmentation, accelerates innovation, and ensures Drupal remains at the forefront of site building.

Our future success hinges on expanding Drupal's usability to a wider audience. Our CMS capabilities are often better than our competitors', but aren't always as user friendly. In the Drupal 7 era, Drupal was the OG (Original Great) of low-code but today we are being outpaced by competitors in terms of ease of use. Without user experience improvements, we'll lose ground. The Experience Builder initiative is all about introducing more people to the power of Drupal.

I feel strongly that a unified Experience Builder is one of the most important initiatives we can undertake right now.

Developing an Experience Builder is a big task that will require substantial effort, extensive collaboration, and significant expertise in user experience and design. As Drupal Core Committers, we are driven by a sense of urgency to advance this initiative. We are committed to moving quickly and iterating rapidly, but to succeed, we also need your support. There will be many opportunities for the community to collaborate and contribute to this initiative.

For more information, please check Lauri's latest blog post on the topic. Additionally, I will discuss this further in my upcoming DrupalCon Portland keynote in a few weeks.