Last week I wrote about how to set up Drupal for core contributing using DDEV. This week I decided to write a bash script so I wouldn't have to remember what I did, it would "just work".
Here's what I've been working on for my Drupal contributions this week. Thanks to Code Enigma for sponsoring the time to work on these.
The third and final feature release of Drupal 10 ships with a new experimental Navigation user interface, stable Workspaces functionality, stable Single-Directory Components support, simplified menu editing, taxonomy moderation support, new recipe and access policy APIs, performance improvements and more.
The new Navigation module provides a redesigned collapsible, vertical navigation sidebar for the administrative user interface. Sub-menus open on a full height drawer that can accommodate deeper navigation levels. On smaller viewports, the toolbar is placed on top of the content, and opens with an overlay.
The Navigation module allows multiple types of customization, like adding new custom menus or changing the default Drupal logo provided. It also uses the Layout Builder module, so that site builders can easily add or reorder these menu blocks.
The Navigation module includes a new content creation and management menu, which allows quick access to content-related tasks to increase usability for content users.
The Workspaces module allows Drupal sites to have multiple work environments, enabling site owners to stage multiple content changes to be deployed to the live site all at once. It has long been available in Drupal core as an experimental module. Following the module's use in live projects, the remaining stable blocking issues have been resolved, so now it is available to all!
Workspaces are sets of content changes that are prepared and reviewed separately from the live site. This is a differentiating feature for Drupal that is important for many large organizations' websites. An organization might use Workspaces to ensure all relevant content goes live simultaneously for a new product launch, or with the outcomes of sporting or election events.
Single-Directory Components (SDCs) are Drupal core’s implementation of a user interface components system. Within SDC, all files necessary to render the user interface component are grouped together in a single directory. This includes Twig, YAML, and optional CSS and JavaScript. SDC support was added to Drupal core in 10.1 as an experimental module. The solution has been very well-received and is now part of the base system. No need to enable a module to use this feature.
Menu item editing is now simplified. Advanced options are displayed in a sidebar to help content editors focus on what is most important for the menu item. Taxonomy terms also now have both a dedicated user interface to edit earlier revisions and content moderation support.
Drupal recipes allow the automation of Drupal module installation and configuration. Drupal recipes are easy to share, and can be composed from other Drupal recipes. For example, Drupal 10.3 includes a Standard recipe providing the same functionality as the Standard install profile. It is a combination of 16 component recipes that can be reused in other recipes.
Recipes provide similar functionality to install profiles but are more flexible. With install profiles only one can be installed on a site. With recipes, multiple recipes can be applied after each other.
Install profiles/distributions Recipes Lock-in Not possible to uninstall (until Drupal 10.3) No lock-in Inheritance Cannot extend other profiles or distributions Can be based on other recipes Composability Cannot install multiple profiles or distributions Multiple recipes can be applied on the site and be the basis of another recipeThe recently announced Starshot Initiative will rely heavily on recipes to provide composable features.
The added APIs include Configuration Actions, Configuration Checkpoints and Default Content.
Additionally, it is now possible to install Drupal without an install profile, or to uninstall an install profile after Drupal is already set up.
The new Access Policy API supports the implementation of access management solutions that go beyond permissions and user roles. Other conditions and contexts may be taken into account, like whether the user used two-factor authentication, or whether they reached a rate limit of an activity. Drupal's existing permission- and role-based access control has been converted to the new API, and custom or contributed projects can add more access policies.
Drupal 10.3 is the final feature release of Drupal 10. Drupal 11 is scheduled to be released the week of July 29th. With that, Drupal 10 goes into long-term support. While more minor releases will be made available of Drupal 10, they will not contain new features, only functionality backported to support security and a smoother upgrade to Drupal 11. Drupal 10's future minor releases will be supported until mid- to late 2026, when Drupal 12 is released and Drupal 11 enters long-term support.
Cristina Chumillas (at Lullabot), Sally Young (also at Lullabot) and Théodore Biadala (at Très Bien Tech) were all promoted from provisional to full Drupal Core Frontend Framework Managers.
Alex Pott (at Acro Commerce and Thunder), Adam Globus-Hoenich (at Acquia) and Jim Birch (at Kanopi Studios) are the maintainers of the new Default Content and Recipes subsystems.
Andrei Mateescu (at Tag1 Consulting) is the maintainer of the newly stable Workspaces module.
Ivan Berdinsky (at Skilld) became a co-maintainer of the Umami demo.
Daniel Veza (at PreviousNext) is a new co-maintainer of Layout Builder.
Mateu Aguiló Bosch (at Lullabot) and Pierre Dureau are new co-maintainers of the Theme API, focusing on Single Directory Components.
If you are looking to make the leap from Drupal user to Drupal contributor, or you want to share resources with your team as part of their professional development, there are many opportunities to deepen your Drupal skill set and give back to the community. Check out the Drupal contributor guide, or join us at DrupalCon Barcelona and attend sessions, network, and enjoy mentorship for your first contributions.
If you've been a Drupal developer since before the time of modern Drupal (pre-Drupal 8,) then you probably remember the Theme Developer module. This module is/was used to figure out theme template usage and possible overrides in Drupal 7.
With modern Drupal, this same information is available directly in the HTML source code of a file when Twig development mode is enabled.
The Visual Debugger module by Marcos Hollanda combines the best of the present with the best of the past to surface template information directly in the user interface without having to dig into the page's HTML.
I will admit that before I installed the module, I was doubtful that I'd be interested in using it. Marcos had pinged me on Slack asking me to take a look at it, and I figured it would be a nice exercise for DrupalEasy Office Hours, which it was.
Much to my surprise though, I really like using it.
There's not much to say about how to use this module - it works just like you'd expect. Use Composer to get the code, enable the module, then enable Twig development mode and you're done. By default it will appear on each non-admin page of your site, with a handy activate/deactivate icon. There's really not too much to say about its usage 😀.
The module is in alpha status with several planned features not yet implemented. What is implemented so far appears to be solid and useful. The basic functionality that I expected is there. Click on any section of the page, and the module will display the template file that is used to render that section as well as a list of possible template file override names. This is the same information that Twig developer mode displays in HTML comments.
Marcos let me know that other planned features include theme hook suggestions and displaying caching information; (similar to the Cache review module, perhaps?)
There are other challenges to overcome as well, including how to handle selecting overlapping elements. I did make one very minor suggestion to relocate the module's configuration page which Marcos quickly implemented 🤘🏼.
I would definitely put this module in the category of a developer tool for folks who are either new to Drupal theme development or people who prefer a UI instead of scrolling through raw HTML.
I plan on following the progress of this module closely, in hopes that it will be suitable to use during the next semester of Drupal Career Online, where we have a theming lesson that could definitely benefit from this module.
Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.
React is one of the primary technologies in our technology stack. This article explores our React use cases, outlining their purpose, technical aspects and implementation examples.
Series Overview & ToC | Previous Article | Next Article - coming June 27th In the previous article we performed an automated migration via the administration interface with tools provided by Drupal core out of the box. This gave us the opportunity to familiarize ourselves with the different modules that assist with the task, settings that affect the migration, and the results when there are no customizations in place. Today we will leverage the Migrate Plus and Migrate Upgrade modules to generate migrations from the command line, which we can then pick from and customize. Automated migration using the Migrate Upgrade module Let’s start by listing the modules that we will use to run the automated migration from the command line: * Migrate: consists of the core API that can be used to import data from any source. * Migrate Drupal: allows connecting to a Drupal 6 or 7 site to import configuration and content. * Migrate Plus: provides extra source, process, and destination plugins; handles migrations as configuration entities; allows reusing of configuration via migration groups; and more. It is a dependency of Migrate Upgrade and a very useful module on its own. * Migrate Upgrade: provides a Drush...
Read more mauricio Thu, 06/20/2024 - 05:15Whether you are a veteran or just getting started with web development, working with web forms is not the sexiest thing but there is no avoiding them. Forms on a website are critical to the website's mission and the visitors using them. In this post I am going to show you how to properly style webforms and form elements so you can ensure they are consistent with your brand and provide a pleasant user experience.
I have recording video tutorials on some of the concepts covered in this post. Scroll to the bottom if you are the kind of person who learns better watching tutorials.
One thing about forms you can count on is that they are not consistent. In today's API era forms can be generated from any source and you don't always have control of their HTML. I personally work with Drupal a lot and even within it forms can originate from Views, Blocks, Nodes, Paragraphs, Modules, and more. I imagine this is the case with most Content Management Systems. So how do you address something where you can't always predict source or markup of forms?
Whether is Drupal or other system, it is best to let that system dictate the markup of forms. Try to bend a system to your needs can prove challenging and not worth the trouble. This is the approach I take and so far this has worked very well for me.
As a Front-End developer for many years, I love a good css class. They make my job a lot easier than not having a class. When it comes to form elements however, it is best to ignore classes and rely solely in attributes. What attributes you may be asking yourself? Let's take a look
The type attribute in form elements make it easy to style them in a global manner. Rather than styling form elements based on their css class or ID, the type attribute is the best approach. Each form field has a type attribute which makes it possible for browsers to render the element as expected. The type attribute can also play a factor in Javascript and form handling, but for now we are going to focus on styling.
Input fields: Input fields such as text fields, are probably the most common form elements in a form. But don't let its simplicity fool you because text fields come in many types; the most common being text. this is the type for a typical text box where you can type just about any kind of information. This sometimes leads to developers using it for anything including for data that should be in a different form type. Let's take a look at the various types a text field can be:
email, this provides you with a custom keyboard on mobile devices that make it easier to type a common url.As you can see from the examples above, text fields may seem simple but they come in all flavors. In most cases, the goal of form elements is to be styled the same across an entire site. So it is recommended you style these elements globally so no matter where they are used they automatically inherit the intended styles. So how do you style them globally? Let's take a look:
Here are a couple of examples of differnt input fields which we will style to ensure they all look similarly everywhere.
<input type="text" name="firstname">
<input type="password" name="password">
<input type="email" name="email">
input[type='text'],
input[type='password'],
input[type='email'],
input[type='tel'],
input[type='search'],
textarea {
background-color: #ffffff;
border: 1px solid #000000;
height: 40px;
padding: 10px;
width: 100%;
}
textarea {
height: initial;
}
By using the element's type attribute we can collectively style them with a single set of rules. As you may have noticed I included textarea as on of the elements because I want textareas boxes (multi-row textbox), to inherit all of the styles from text boxes with the exception of the height property; thus we override the height property while keeping all other styles the same as text boxes.
Buttons are elements you typically want to display with consistent styles across your entire website. This includes buttons you may create yourself and those provided by the content management system you may be working with. So similarly to input fields above, we can't always rely on IDs or classes to style them. However, similarly to the input fields above, we can rely on the type attribute to style the different type of buttons in our site. Different type of buttons? yes, there are different types. Let's tae a look.
<a class='button'>I want to look like a button</a>
<button>I'm an actual button</button>
<input type='submit' value='Yo tambien'>
<input type='reset' value='Me too'>
type=['reset']) should look slightly different because it's not a primary button, it's more of a secondary button..button,
button,
input[type='submit'],
input[type='reset'] {
background-color: rebeccapurple;
border-radius: 2px;
border: 2px solid rebeccapurple;
color: #ffffff;
cursor: pointer;
display: inline-block;
font-size: 18px;
line-height: 1;
padding: 20px 40px;
text-align: center;
text-decoration: none;
white-space: nowrap;
margin-bottom: 20px;
}
.button:hover,
.button:focus,
button:hover,
button:focus,
input[type='submit']:hover,
input[type='submit']:focus {
background-color: rgb(126, 63, 189); /* lighter purple */
color: #ffffff;
text-decoration: none;
}
input[type='reset'] {
background-color: #ffffff;
border-color: rebeccapurple;
color: rebeccapurple;
}
input[type='reset']:hover,
input[type='reset']:focus {
background-color: #ffffff;
border-color: #444444;
color: #444444;
}
Probably the hardest elements to style due to their dynamic nature, they have a hard time fitting in with the rest of HTML elements. Rather than link you to another blog post where you can copy and paste the necessary CSS to style these elements, I am walk you through the process of styling them.
Checkout the Codepen for these elements.
The typical markup for a checkbox or radio button looks like this:
<div class="checkbox__item">
<input type="checkbox" id="checkbox1" name="checkboxname" value="Item 2">
<label for="checkbox1">Item 2</label>
</div>
<div class="checkbox__item">
<input type="checkbox" id="checkbox2" name="checkboxname" value="Item 2">
<label for="checkbox2">Item 2</label>
</div>
<div class="radio__item">
<input type="radio" id="radio1" name="radioname" value="Item 2">
<label for="radio1">Item 1</label>
</div>
<div class="radio__item">
<input type="radio" id="radio2" name="radioname" value="Item 2">
<label for="radio2">Item 2</label>
</div>
Out of the box, you can not style the native checkbox nor radio button elements. To be able to apply custom styles we need to do it in a hacky way. This is my favorite way to style these elements.
/* visually hide the native checkbox and radio buttons. */
input[type='checkbox'],
input[type='radio'] {
position: absolute;
opacity: 0;
}
visibility-hidden or display: none are not viable options./* Add space to the left of the label for later use. */
label {
position: relative;
padding-left: 35px;
}
relative position on the label as we prepare to add pseudo elements in the next steps./* Draw a square box with border using a pseudo element (`::before`). */
input[type='checkbox'] + label::before {
border: 2px solid #e15b00;
content: '';
display: inline-block;
height: 24px;
left: 0;
position: absolute;
top: -2px;
width: 24px;
}
+ sign. The sibling element being the label element. If you look at the markup we wrote above, you will notice that the checkbox and the label are siblings. This is also true for the radio button and its label.::before pseudo element on the label, we are drawing a 24px square box.content:, even if it's value is empty as shown above.2px border on the box. This box is what will be presented as the actual checkbox for the user to interact with (check/uncheck).absolute position, we are positioning just to the left of the label. The position of the box is in relation to the label's position (hence relative position on the label)./* Draw checkmark using a ::after pseudo elment on the label */
input[type='checkbox'] + label::after {
border-bottom: 3px solid #fff;
border-left: 3px solid #fff;
content: '';
display: inline-block;
height: 10px;
left: 4px;
position: absolute;
top: 2px;
transform: rotate(-45deg);
width: 18px;
}
::after pseudo element on the label. This means we are drawing the checkmark symbol after the label element.3px. By rotating the box negative 45 degrees, this makes it look like a checkmark.absolute position on the checkmark so we can position it right in the middle of the box we drew before.Before proceeding with the styles, let's repeat the steps above but this time for the radio buttons. These styles are extremely similar with the exception of in stead of drawing a square box, we will be drawing a circle with an outline, and instead of a checkmark, we will be drawing a filled circle in the middle of the outlined circle.
/* Draw a circle and add borders to it */
input[type='radio'] + label::before {
border-radius: 50%;
border: 2px solid #e15b00;
content: '';
display: inline-block;
height: 24px;
left: 2px;
position: absolute;
top: -4px;
width: 24px;
}
/* Draw an inner circle */
input[type='radio'] + label::after {
background-color: #e15b00;
border-radius: 50%;
content: '';
display: inline-block;
height: 20px;
left: 6px;
position: absolute;
top: 0;
width: 20px;
}
radio and we are using border-radius to draw a perfect circle./* Hide checkmark and inner circle by default */
.radio input[type='radio'] + label::after,
.checkbox input[type='checkbox'] + label::after {
content: none;
}
content: to none. This will present the checkboxes and radio buttons unchecked./* Show checkmark and inner circle when input is checked */
input[type='radio']:checked + label::after,
input[type='checkbox']:checked + label::after {
content: '';
}
:checked pseudo class (input[type='radio']:checked, input[type='checkbox']:checked), we then show the checkmark or inner circle by setting the content: property's value to empty ('' i.e. removing none). The :checked pseudo class becomes available when the checkbox or radio buttons are click-checked and when that happens, then we show the checkmark or inner circle./* When box is checked, add background color. */
input[type='checkbox']:checked + label::before {
content: '';
background-color: #e15b00;
}
:checked pseudo class is present./* Add focus styles when elements are in focus */
input[type='radio']:focus + label::before,
input[type='checkbox']:focus + label::before {
outline: rgb(59, 153, 252) auto 5px;
}
:focus pseudo class, we are adding basic outline styles to show the "on focus" state of the inputs. We need to do this since we are not using the native input elements. If we were, the browser would automatically add these styles to our inputs.I have recorded tutorials on severalof these things. Check them out if you are the kind of person who learns better through video tutorials.
Images are an essential part of a website. They enhance the appeal of the site and make the user experience a more pleasant one. The challenge is finding the balance between enhancing the look of your website through the use of images and not jeopardizing performance. In this guide, we'll dig deep into how to find that balance by going over knowledge, techniques and practices that will provide you with a solid understanding of the best way to serve images to your visitors using the latest technologies and taking advantage of the advances of web browsers in recent years.
Hi, I hope you are ready to dig into responsive images. This is a seven-part guide that will cover everything you need to know about responsive images and how to manage them in a Drupal site. Although the excercises in this guide are Drupal-specific, the core principles of responsive images apply to any platform you use to build your sites.
Choosing Drupal as your CMS is a great place to start. Drupal has always been ahead of the game when it comes to managing images by providing features such as image compression, image styles, responsive images styles and media library to mention a few. All these features, and more, come out of the box in Drupal. In fact, most of what we will cover in this guide will be solely out of the box Drupal features. We may touch on third party or contrib techniques or tools but only to let you know what's available not as a hard requirement for managing images in Drupal.
It is important to become well-versed with the tools available in Drupal for managing images. Only then you will be able to make the most of those tools. Don't worry though, this guide will provide you with a lot of knowledge about all the pieces that take part in building a solid system for managing and serving responsive images.
Let's start by breaking down the topics this guide will cover:
<picture> HTML elementsrcset and sizes attributesA responsive image is one whose dimensions adjust to changes in screen resolutions. The concept of responsive images is one that developers and designers have been strugling with ever since Ethan Marcotte published his famous blog post, Responsive Web Design, back in 2010 followed by his book of the same title. The concept itself is pretty straight forward, serve the right image to any device type based on various factors such as screen resolution, internet speed, device orientation, viewport size, and others. The technique for achieving this concept is not as easy. I can honestly say that over 10 years after reponsive images were introduced, we are still trying to figure out the best way to render images that are responsive. Read more about responsive images.
So if the concept of responsive images is so simple, why don't we have one standard for effectively implementing it? Well, images are complicated. They bring with them all sorts of issues that can negatively impact a website if not properly handled. Some of these issues include: Resolution, file size or weight, file type, bandwidth demands, browser support, and more.
Some of these issues have been resolved by fast internet speeds available nowadays, better browser support for file tyes such as webp, as well as excellent image compression technologies. However, there are still some issues that will probably never go away and that's what makes this topic so complicated. One issue in particular is using poorly compressed images that are extremely big in file size. Unfortunately often times this is at the hands of people who lack the knowledge of creating images that are light in weight and properly compressed. So it's up to us, developers, to anticipate the problems and proactively address them.
If you are responsible for creating or working with images in an image editor such as Photoshop, Illustrator, GIMP, and others, you have great tools at your disposal to ensure your images are optimized and sized properly. You can play around with the image quality scale as you export your images and ensure they are not bigger than they need to be. There are many other tools that can help you with compression. One little tool I've been using for years is this little app called ImageOptim, which allows you to drop in your images in it and it compresses them saving you some file size and improving compression.
Depending on your requirements and environment, you could also look at using different file types for your images. One highly recommended image type is webp. With the ability to do lossless and lossy compression, webp provides significant improvements in file sizes while still maintaining your images high quality. The browser support for webp is excellent as it is supported by all major browsers, but do some research prior to start using it as there are some hosting platforms that do not support webp.
To give you an example of how good webp is, the image in the header of this blog post was originally exported from Photoshop as a .JPG, which resulted in a 317KB file size. This is not bad at all, but then I ran the image through the ImageOptim app and the file size was reduced to 120KB. That's a 62% file size reduction. Then I exported the same image from Photoshop but this time in .webp format and the file size became 93KB. That's 71% in file size reduction compared to the original JPG version.
By now it should be clear that the goal for serving images on any website is doing it by using the responsive images approach. The way you implement responsive images on your site may vary depending on your platform, available tools, and skillset. Regardless, the following CSS rule should always be available within your project base CSS styles and should apply to all images on your site:
img {
display: block;
max-width: 100%;
}
Easy right? That's it, we're done 😃
The CSS rule above will in fact make your images responsive (images will automatically adapt to the width of their containers/viewport). This rule should be added to your website's base styles so every image in your website becomes responsive by default. However, this should not be the extend of your responsive images solution. Although your images will be responsive with the CSS rule above, this does not address image compression nor optimization and this will result in performance issues if you are dealing with extremly large file sizes. Take a look at this example where the rule above is being used. Resize your browser to any width including super small to simulate a mobile device. Notice how the image automatically adapts to the width of the browser. Here's the problem though, the image in this example measures 5760x3840 pixels and it weights 6.7 MB. This means, even if your browser width is super narrow, and the image is resized to a very small visual size, you are still loading an image that is 6.7 MB in weight. No good 👎
In the next post of this series, we will begin the process of implementing a solution for handling responsive images the right way.
Navigate posts within this series