Matt Glaman: Retrofit's next milestone: Drupal 7 theme support

It has been a little over a month since I announced Retrofit. The project provides a compatibility layer to allow legacy Drupal 7 code to run within a Drupal 10 code base. Since Retrofit was first released, I was able to add support for theme functions and PHPTemplate template files so that existing hook_theme declarations work with minimal modifications. Since then, I have been trying to decide on the next milestone for the project. What compatibility support can Retrofit provide to unlock the most benefit to organizations upgrading from Drupal 7? Themes!

LN Webworks: Drupal SEO: Everything You Need to Know

Image removed.

If you have an inner hunger for success as an entrepreneur, Search Engine Optimization is indispensable. It is the key to improving your site’s visibility and attracting swarms of organic traffic. Besides, a high SEO ranking gives you an edge over your competitors and enhances your brand reputation. Although there is a plethora of SEO tools available in the market, Drupal SEO is a preferred choice of a majority of organizations. 

In case you are struggling with choosing the right SEO tool for your website, this blog will help you get acquainted with the benefits of Drupal SEO and facilitate easy decision-making. 

DrupalEasy: Smart Trim module - past, present, and future

Image removed.The Drupal Smart Trim module is used by more than 65,000 sites, including over ⅔ on modern Drupal (8+) sites. It has proven to be a valuable tool to improve Drupal's core functionality to trim long text fields in an intelligent manner.

Late in 2022, we released a major update (2.0.0) to the module. Among other improvements, we delivered Drupal 10 compatibility and much improved automated tests. Since then, a 2.1.0 release (completed during the DrupalCon Pittsburgh community contribution day) has brought even more automated tests and functionality.

During DrupalCon Pittsburgh, Mark Casias (markie) and I discussed the future of the Smart Trim module and agreed on a few conceptual ideas that will guide our decisions about the module for the foreseeable future. We decided to share these ideas as a mission statement for the module:

Smart Trim is designed to be a focused, lightweight improvement over Drupal core's current formatter trimming capabilities. The maintainers' focus is stability and ease-of-use. Customizations to the module are encouraged with template overrides and Smart Trim hook implementations.

In short, we don't necessarily want to add more dials and levers to Smart Trim formatter's configuration; rather we are going to focus on stability and ease-of-use while at the same time ensuring that those who want to do more with Smart Trim have the necessary tools at their disposal.

To this end, one of the most significant additions to the 2.1.0 version of the module is that of a smart-trim.html.twig template file. This will allow Drupal developers to have complete control over the output of the module; reducing the need for Smart Trim formatter configuration options. In fact, the current version of the module includes a deprecated configuration setting in the UI that we plan on removing in a future release (other configuration settings that we consider edge cases will also be deprecated in the future.) 

Image removed.

Other improvements to the module over the past few months include:

Another decision that Mark and I made regarding the future of the module is that all commits must have test coverage. This makes a huge difference in the stability and quality of releases.

Most significantly, it cannot be overstated how much community effort, with time contributed by more than a few individuals, has resulted in the progress over the past few months. Among them, I'd like to mention Julian Pustkuchen (Anybody) and James Shields (lostcarpark) for the ongoing efforts. James is a recent graduate of DrupalEasy's Professional Module Development course and has been putting his new skills to use in this and other community projects.

The future of the Smart Trim module is bright. Changes implemented since the 2.1.0 release include:

Our current focus in the short term is on fixing bugs and continued improvements of our automated tests. We are excited about the direction the module is going and look forward to our next release.

Golems GABB: Building a Decentralized Application with Drupal and IPFS

Building a Decentralized Application with Drupal and IPFS Editor Tue, 07/18/2023 - 13:40

The solution of decentralization is becoming increasingly popular in the technology industry. Decentralized applications (DApps) promote user collaboration without a centralized management system. They are growing in popularity due to their enhanced security and user-friendliness. This article will delve into developing a decentralized application using Drupal and the InterPlanetary File System (IPFS). We'll discuss these technological innovations and their benefits and provide a comprehensive guide to creating dApps using the popular open-source management system.

Specbee: Component-based theming with Drupal’s Single Directory Component

Drupal theming has been an area long untouched by a radical update. Sure there are tons of contributed modules available for making the workflow a little easier but the out-of-the-box approach for creating a custom theme has remained more or less the same. There has been chatter about having some sort of component-based theming mechanism inside Drupal core itself for a long time. Enter Single Directory Components (SDC), which has been in discussion for quite some time through a contributed module handled by prominent Drupal contributors - Mateu Aguiló Bosch, Mike Herchel, Lauri Eskola, and Dave Reid. But now it has entered the core of Drupal (currently as an experimental feature) in version 10.1.  This component-based approach of theming a Drupal application isn’t new but it finally has made it to the core. It gives a whole new frontier for front-end devs to organize their code in a way that is more maintainable with a minimal learning curve. Within SDC, all files necessary to render the component (Twig, CSS, JS, etc.) are grouped together in a single directory. SDC has the potential to revolutionize front-end development in Drupal by empowering developers to leverage the latest front-end techniques, solidifying Drupal’s position as a robust and forward-looking CMS. Drupal's current theming approach The simplest way to work on a Drupal theme has been to add the markup to the html.twig files inside the template folders. For styling and behavior, we create CSS and JS files according to an entity's need and place them inside the CSS and JS folders respectively. This includes theming header menu, footer menu, blocks, regions, individual content types and their different view modes, different views, etc.  These files are then declared in the libraries.yml file where dependencies (if any) can also be mentioned. This way they can be loaded on demand or be made globally available. Apart from this, any preprocessing logic goes into the .theme files, we have the breakpoints.yml to help with responsive designs and of course, .info.yml file without which all the effort is a waste. While this seems to be a lot of work to be done before we actually do some useful frontend work, there have been some boilerplate code generators like drush theme generate, which intend to generate the folder structure of a theme in an interactive way and create a standard drupal folder structure. Even though the above structure works well enough for starting a project and can pose no issue for a small project, it can become a bottleneck for enterprise websites where a more sophisticated design system needs to be integrated. Things start getting cluttered very rapidly. We see a lot of CSS and JS files just filled up to the brim in their folders.  Developers struggle to find the code they can reuse or extend. Issues like code duplication, code spread across the files, specificity hell, and CSS conflicts crop up. This often leads to more efforts spent on later development where it is expected that initial development would have helped later. Our approach to theming in Specbee At Specbee, we have standardized how we create our themes using an NPM tool called Drupal Theme Init developed by us from scratch which is open-sourced. Being a Yeoman generator, it can easily be installed with NPM/Yarn which then interactively helps in the generation of a custom theme. The idea of the Drupal Theme init is to have a consistent approach to how theme files are scaffolded following Drupal practices and to help out developers to start working on the theme without the hassle of setting the files every time they start a new project.  The basic idea of the structure is to compartmentalize SASS into components using the BEM convention. Each CSS files associated with an entity like block, view, content type, etc have its own CSS generated and is attached to that entity either through the twig template or preprocessing. The same goes for the JS files. The extensive use of libraries.yml helps us to limit the amount of CSS and JS we render on the page. The advantage of setting up the theme this way is we have a system in place for component-based theming without depending on any external libraries or plugins. It helps us to segregate the CSS/JS libraries based on the components to be loaded on the page, which helps with the performance. However, there are still limitations to this approach especially when the project grows in size. The segregation of components into atomic levels becomes a bit of a burden as it requires us to maintain the libraries.yml file with required dependencies. Also, there is no easy way we can do a proper integration of a design system with the current structure easily as we will have to define each component path and its dependency by ourselves in the design system too, to load the components in it. What is Component-based theming While the vanilla approach seems fairly basic, there have been huge amounts of advancements done in recent times through contributed modules to have better approaches. One of the popular approaches is imagining the UI as a collection of reusable and consistent units called components. In most cases, this follows Atomic Design where each component is segregated into smaller building blocks. Modules like UI Patterns, Components! or component libraries like PatternLab, Fractal, and Storybook have brought innovative ways which have made the development of themes more streamlined and robust. Component-based theming has a certain edge over traditional theming: One of the biggest bottlenecks is the backend dependency, where frontend work can't start without the Backend work. This creates a lag. Using a component-based approach, the front-end can work independently and without much deep knowledge of Drupal things. Components can be created just from the available design with the required placeholders. The values for these placeholders can be filled later when the backend work is completed It creates a workflow where we just don’t change the markup in the templates folder and style it as per the requirement. Rather we have smaller structures styled separately and then create a collection of these smaller units into bigger components that can be used by the Drupal templates.  This helps in maintaining the code related to each component in isolation and creates lesser chances of side effects.  It confirms UX consistency across the application. Helps in the reduction of efforts spent on setting up the feature as changes made in one place reflect across the areas where it is used. How to do component-based theming in Drupal One of the prominent ways of following component-based development is using PatternLab which was introduced quite a while back. It initially came in with a Drupal edition which is archived now and replaced by a node-based package. The setting up of the PatternLab requires a Components module to be installed which will help in getting the markup from Twig files outside the templates folder for Drupal. This is followed by installing the patternlab package via npm which gives options to generate twig or mustache-based templates (obviously twig for us). Once this is done we have a ready reckoner style guide, some boilerplate code that helps in the creation of the style guide, and a patterns folder where in we create the components according to the requirements. These components are then included in the html.twig files present inside the templates folder. While all these steps are fine to perform, there are instances where this is a bit difficult to set up and has a bit of a learning curve to it. The biggest drawback that comes with Patternlab is that all the CSS is aggregated into a single file which then gets dumped into all the pages (which is sometimes also the case with the JS included with it). While this doesn’t matter initially as the basic idea is the reusability of the component, once the project grows this starts affecting the page performance. How to do component-based theming with SDC With the initial version of SDC going into the core as an experimental module, there has been a lot of excitement around it. SDC has been touted as the biggest change to Drupal theming since the introduction of Twig. SDC again is not a complete solution for the Frontend Development team but a component-driven approach to theming with an out-of-the-box basic structure. This can still be extended with a number of modules for a certain kind of workflow. The basic idea is everything related to a component stays inside a single directory. This includes the Component Twig file, JS, CSS, other assets, and a single schema YAML file declaring the properties of the component. Some immediate benefits of using SDC: All the code related to a component is in a single directory (as the name suggests!).  The libraries for the component are auto-generated which leads to lesser trauma of not declaring the it in libraries.yml file. Although we still might need to add the dependencies to the component.yml file, this is being done in a single place rather than jumping to the libraries.yml file. There is a far smaller learning curve to implement SDC. If you know the basic of Drupal theming, all you need to do is enable this module and start writing the components. The power of twig (include/extend/embed) is still available which helps in the reusability of code. As the components are YML plugins, which can be easily discovered by Drupal and can be easily swapped by a component having the same API structure. The components can also be rendered through render arrays!  Provides a good mechanism to integrate external libraries to facilitate a Design system. As the components are organized, the result of that is a consistent look and feel of the end product. The code becomes more testable as we have units (read components) that can be tested independently Because we define the schema within a component’s YAML definition, modules can automatically create forms to populate data. Though it is currently included as an experimental feature in the core, setting up SDC is quite easy. Assuming there is a Drupal 10.1.x installation: 1. Enable the experimental SDC core module.   2. Create or use a custom theme to add SDC. For our purpose we created a custom theme called Ice Cream with Olivero as base theme. 3. For our purpose, let's use the basic page which comes out of the box. I have repurposed it by adding a custom Title field and making some adjustments to the display which then looks like this:   4. The template twig file consists of basic code:   5. Create a folder called components inside your custom theme. This is similar to how we have a templates folder for Drupal templates.   6. For now, the basic idea is to style the title and description, which will be reusable in nature. Let's create a component called simple-article. There will be simple-article.component.yml file and simple-article.twig which we will require. Apart from that, we will also add simple-article.css for styling.   7. Let's create the simple-article.twig file. We will have a basic markup for that.   8. Add the simple-article.component.yml file with the schema mentioned in https://www.drupal.org/node/3352951. The idea is to define what will be the inputs to the twig file. It will look something like this for us:   9. Let’s add some basic styling to the component in simple-article.css.   10. Clear the cache. 11. Abracadabra! The component is now ready to use. But it still needs to be used. Without that, the component sits idle in the components folder. 12. Include this component in the required template file (this is the html.twig file under the templates folder in the custom theme) with format [theme_name:component-name]. Notice the include statement where we are adding the twig variables to be used in the component.   13. The component now gets rendered with our new markup and better styling.   14. Notice the markup. If twig debug is enabled, we get some special icons too with our SDC component rendered.   And that’s it! References https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components/about-single-directory-components https://www.drupal.org/project/sdc https://herchel.com/articles/creating-your-first-single-directory-component-within-drupal Final Thoughts With the way SDC has been built, there is going to be high-intensity development around it. One of the popular tracks is that modules will automatically detect components and insert their respective forms into Layout Builder, CKEditor, Paragraphs, Blocks, Fields, etc! In addition, SDC right now plays nice with Storybook through a contributed module called CL Server (which has been maintained by SDC project maintainers). Already there are other modules like CL Devel, CL Generator, and even UI Patterns that are getting built around SDC. This will also help us to upgrade our own theme generator (Drupal Theme Init)  which we discussed earlier to give an option of using SDC along with a Design System in place, preferably Storybook. This will help anyone to kickstart SDC implementation instantly paving the way for better theme development. If you would like to read more such interesting content on Drupal, subscribe to our weekly newsletter today!

Chapter Three: Join Us At Decoupled Days 2023!

Decoupled Days is THE conference to attend if you’re at all interested in all things headless and decoupled. Now in its seventh year, this year’s conference will be held in person in Albuquerque, New Mexico, from August 16 to 17. Chapter Three is proud to be a Silver Sponsor of Decoupled Days 2023. We’re also excited to have the opportunity to discuss Next-Drupal and its reverberating impact on the Drupal community with this year’s attendees.

Talking Drupal: Talking Drupal #407 - Better Drupal Search

Today we are talking about How to improve Drupal Search with Sean Walsh.

For show notes visit: www.talkingDrupal.com/407

Topics
  • Drupal core search improvement
  • External search backends
    • Database
    • Solr
    • Elasticsearch
    • Opensearch
    • Algolia
    • SearchStax
  • Common Modules
    • Facets
    • Search API Autocomplete
    • Search API Exclude
  • Improve search for users
  • Segmented vs Unified search
  • A11y tips
  • Common pitfalls
Resources Hosts

Nic Laflin - www.nLighteneddevelopment.com @nicxvan John Picozzi - www.epam.com @johnpicozzi Sean T. Walsh - @seantwalsh

MOTW Correspondent

Martin Anderson-Clutz - @mandclu ECA Commerce Provides events to the ECA module from all of the commerce core and submodules.

The Drop Times: Embracing Positivity: Nourishing the Mind and Soul

Cultivating positivity becomes crucial for our well-being in a world that can sometimes feel overwhelming. Positivity uplifts our spirits, enhances resilience, and enables us to navigate life's challenges gracefully. Today, we delve into positivity's power and explore ways to consciously consume it to create a brighter and more fulfilling life.

Positivity is not just a fleeting emotion but a mindset that can transform our lives. Research has shown that adopting a positive outlook has numerous benefits, including reduced stress levels, improved mental health, enhanced creativity, and increased overall life satisfaction. Positivity fosters optimism, resilience, and a greater sense of well-being, allowing us to approach life's ups and downs with a healthier perspective.

Consciously choosing your social connections is vital in consuming positivity. Surround yourself with people who uplift and inspire you. Engage in meaningful conversations, support, and celebrate each other's achievements. You create a supportive network that encourages personal growth, resilience, and a positive outlook by fostering positive relationships.

Additionally, mindfulness practices can help us consume positivity in the present moment. Engage in activities that bring you joy and cultivate a sense of mindfulness, such as meditation, yoga, or spending time in nature. These practices help quiet the mind, reduce stress, and increase awareness of the present moment. We enhance our overall well-being by immersing ourselves in positive experiences and focusing on the present.

Just as Drupal empowers website owners to create engaging and dynamic online experiences, cultivating positivity empowers us to build fulfilling and meaningful lives. Surround yourself with positive influences, cultivate gratitude, nurture positive relationships, practice mindfulness, and be kind to yourself. By consciously consuming positivity, we create an environment that fosters growth, resilience, and a brighter outlook on life.

With that said, let us delve into the stories from the last week,

TDT organized an interview with Sibu Stephen. Click here to read Sibu's conversation with Thomas and gain insights from their discussion. Additionally, Home Business shared a blog post on unlocking the power of Drupal web development services, offering valuable information on building scalable websites that empower businesses.

Portland Drupal User Group's held its July Meetup on July 12, 2023. Click here to learn more about the meetup.

Kartik Kumar's article is a good start if you seek tips and strategies for building engaging web experiences using Drupal. Click here to discover his insights and take your web development skills to the next level. Stay updated with the latest trends in Drupal as LN Webworks delves into the reasons behind rapid upgrades and timely migrations. Explore their informative blog post and stay ahead of the curve.

Julia Kranzthor has joined the Drupal Association as Director of Philanthropy. Click here to learn more about her and the valuable contributions she brings to the Drupal community. Were you looking to transform your website? Discover the transformative power of Drupal with Specbee as they share insights on why your website deserves a makeover. Read their blog post for a sneak peek into the cool features and impressive results they've achieved.

If you plan to use AI extensively in your web environment, consider amazee.io's AI application hosting, a secure and scalable solution for hosting complex and sophisticated AI models.

Lastly, be captivated by the possibilities of Drupal as an open-source solution with the captivating radio commercial by the Dutch Drupal Association. Click here to listen to their engaging advertisement, showcasing Drupal's potential for businesses.

That's all from the past week; keep exploring, learning, and embracing the positive energy within the Drupal community and beyond!

Kazima Abbas

Sub Editor, The Drop Times

DrupalEasy: Solving a local "502 Bad Gateway" Drupal issue

Image removed.I learned a valuable lesson last week.

First, some context. One of DrupalEasy's clients is a large international industry association that is currently running a large Drupal 9 site with about a dozen custom modules and well over 150 contributed modules. We were brought onto the project a couple of years ago to do some custom module development, but until recently weren't all that involved in the overall site maintenance and development.

As part of a recent task we've been working on, I stumbled on an issue that was occurring only on my local, and not in a way that was super-consistent (or so it seemed.)

The issue manifested itself only on some publicly-facing pages (never on an admin UI page) as a 502 Bad Gateway error. Never as a PHP error, and never displaying any additional information to help me debug.

Initial debugging effort

Another developer and I were both using the same version of DDEV on our local environments, with similar points of the code base checked-out (and similar databases.) But, I was the only one seeing the 502 Bad Gateway issue.

I first spent more hours than I care to admit trying to chase down the cause using Drupal-y debugging techniques, including a few hours in Xdebug. One potential clue that looked promising was that if I changed the front-end theme to Olivero, the issue went away. This led me down a rabbit-hole of thinking it had to do with a theme preprocess function or an issue with one of the blocks configured to appear in the main theme. Neither of these theories panned out after several hours of effort.

*Give yourself a gold medal if you've already figured this one out at this point.🥇

Change of focus

I then turned my attention toward trying to figure out why I was having the issue but my co-developer on the project wasn't, despite the fact that we appeared to have identical setups. We compared DDEV config settings, Git check-out points, and databases. Toward the end of one of our Zoom debugging sessions, we realized that he wasn't using the default settings.local.php file while I was - finally, another clue! We didn't have time to investigate this difference immediately, but it did turn out to be the clue that I needed to solve the riddle.

Based on a tip/reminder from someone else I had mentioned the issue to, I decided to check the DDEV logs via ddev logs, where I saw more than a few instances of this:

upstream sent too big header while reading response header from upstream

That was all I needed to see.

*Give yourself a silver medal if you've figured it out now. 🥈

The cause

As part of our Professional Module Development workshop, we spend a couple of weeks talking about Drupal caching. One of the things we cover is the ability to output Drupal cacheability metadata to the response header of each page. This is useful to see all the cache tags and contexts that are used on any given page. This debugging data is output to the response header of the page when the following service parameter is set:

http.response.debug_cacheability_headers: true

*Give yourself a bronze medal if you've figured it out now. 🥉

The solution

If the page is complex enough, then it is possible for the number of cache tags and contexts to be so large that it maxes out the allowed size of a response header. Could a large site with more than 150 enabled contributed modules fall into this category? Absolutely.

Still, why was my local site hitting this issue and my co-developer's site not? Because I always use a settings.local.php for all of my local sites. It is part of my standard workflow. Since the default Drupal core-provided example.settings.local.php file includes the development.services.yml file, and the http.response.debug_cacheability_headers parameter is set to true by default in development.services.yml, the mystery was solved.

A quick test (flipping it to false on my local) confirmed it.

Lessons learned

  • When a 502 Bad Gateway happens, check the web server logs before the Drupal/PHP logs.
    When only one developer can produce an error, focus on local development environment configuration before Drupal debugging.

The pixel art image used in this blog post was generated by the DALL-E project of OpenAI
 

Zyxware Technologies: Agility and Efficiency: No Code Tools in Drupal Web Development

In the ever-evolving realm of Drupal web development, adaptability and swift implementation of feature requests from business owners are paramount for successful digital ventures. When faced with the challenge of meeting the dynamic demands of the operations team and ever-changing business requirements, relying solely on native implementations can lead to prolonged deployment times and missed opportunities. Learn how we have leveraged no-code, low-code solutions and Drupal to quickly deploy a feature that made a media portal's lead management process efficient.