While pursuing higher education is known for its challenges, have you ever considered the intricacies of managing a higher education institution? The massive volume of files, student records, databases, and other elements can quickly spiral into disarray.
Today we are talking about Inclusive Hiring Practices, Disability Employment Awareness Month, and tips to improve your hiring practices with our guest Donna Bungard. We’ll also cover Organigrams as our module of the week.
For show notes visit: www.talkingDrupal.com/418
TopicsNational Disability Employment Awareness Month Snow shovel cartoon Curb-cut effect
Race after technology Center for accessible technology Apple assistive tech
GuestsDonna Bungard - @dbungard
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Jen Lampton - jenlampton.com - jenlampton
MOTW CorrespondentMartin Anderson-Clutz - @mandclu Organigrams
The internet is full of noise—by noise, I mean distraction. Many silly videos eat our time, making us idle and less productive. I confess, I, too, fall prey to it. One such day, while scrolling through YouTube shorts, this video came to my screen, wherein a person is seen cutting open a tree trunk, and lots of catfish fall through the openings.
How the fish climbed the tree and hid inside the trunk is not very genius to share. It was right after a flood, and when the flood water rose, those catfish could find a good hideout inside the tree through some crevice made by a woodpecker. But as the water receded, they couldn't get themselves out. As we know, catfish can survive with little water, and fortunately, the hollow tree was holding enough water for them to stay until the apocalypse came!
There is this saying often attributed to Albert Einstein, who supposedly remarked,
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing it is stupid."
Like many other bogus quotes around education and personal genius, we can be sure that Einstein might never have said so. But then, there won't be any memes!
The two things I said have no direct connection with each other. The first one might be a staged video by content creators. The second one can at least be used as an allegory, even though the attribution is way off. But could a fish end up in a tree? Is climbing a tree an attribute of a fish?
Of course, I am not discounting Climbing Gouramies and Mudskippers. There would always be anomalies. And there are urban legends! We are neither.
The Drop Times is a news portal that celebrates everything good happening around Drupal. We aspire to be the voice of Drupal, reaching out to the wider world outside the Drupal Community. We are not an inward-looking medium but an outreach programme to promote the product and the community.
Communities function based on consensus among various stakeholders. They would have diverse political and cultural leanings, often contradictory. The presence of a mechanism that allows people to fall in line around a common minimum program sets apart a functioning community from those that don’t. It is like a school of fish, a flock of birds, or a swarm of bees that act as a single organism larger than the constituent units.
We align with the values that the Drupal community upholds. At the same time, we would like to limit ourselves to our primary mandate of celebrating Drupal both within and outside the community. We are also not geared towards anything other than this. We rest assured that the Drupal community is a mature FOSS community with formal mechanisms in place to address the different issues it runs into.
We are here to weave the community's good narratives and showcase them to the outside world. Let us continue to focus on that, like the fish in the water, unlike the fish inside a tree trunk trying to figure out how we ended up there or how to get out of there.
Yesterday, TheDropTimes (TDT) published an interview with Pierina Wetto, Marketing Manager at Last Call Media. Pierina also manages the Promote Drupal initiative, where she is committed to producing content and marketing efforts to promote Drupal outside of the community. Alethia Rose Braganza, former sub-editor at TDT, spoke to Pierina over a Zoom call in August.
Another major story we ran was this report on the "Non-profit Drupal" Community. In a conversation with Alka Elizabeth, sub-editor at TDT, Johanna Bates, co-organiser of the community, underscored the enduring preference of non-profits for Drupal, a testament to their commitment to open-source software.
We also brought you two stories on two modules that got some recent shine and glory.
The WordPress Migrate module from Mike Ryan serves as a vital tool for seamlessly migrating WordPress blog exports (in WXR format) into the Drupal ecosystem. The module integrated into Drupal 8's core is now compatible with Drupal 9 and 10.
The Visual Layout Suite (VLSuite) project, a content editing experience built upon Drupal Core’s Layout builder, released its latest release candidate version, 1.1.0-rc4, on September 21, 2023.
As usual, we echoed several blog posts from other companies, among which I am reintroducing a selected few in this newsletter.
Evolving Web published an article by Sebastián González Díaz wherein he lists 5 Useful Modules to Enhance CKEditor 5 in Drupal 10.
Matt Wetmore, Senior Director of Web Operations at Acquia, shared A Beginner's Guide to Installing the Simple XML Sitemap Module in Drupal. In the wake of Drupal 9's EOL, Acquia has published a guide for a smooth transition to Drupal 10.
Salsa Digital has published Kristen Pol’s self-help guide on Drupal website security. Divided into six parts, "Drupal Security — A Drupal Self-Help Guide to Ensuring your Website’s Security" covers the significance of security for online experiences, Drupal’s capabilities and initiatives, and, most crucially, the top 10 strategies for enhancing Drupal security. She has also listed the top 10 tips for Drupal website performance. John Cloys is helping us with directions to improve Drupal website accessibility through his three-part practical guide.
Ivan Zugec has shared insights on harnessing the power of Bootstrap 5 with Radix in Drupal. The video tutorial was published on WebWash's YouTube channel.
For those waiting to migrate their D7 sites to D10, Pantheon and ImageX have put together some guidelines to Boost Performance & SEO.
To build public sector websites effectively with LocalGov Drupal, read about Nomensa's webinar and watch the video. WebCurl has written about LGD Microsites that transform the digital landscape for UK Councils.
Head to Arocom's blog about Algolia, a robust search and discovery API that smoothly integrates with Drupal.
Dropsolid has published a blog post by Jasper Debaere about Connecting Drupal Content to Mautic Email Marketing.
Raghad Eid writes in Vardot about How Drupal's Atomic Design Enhances Web Accessibility and Empower Inclusive Education.
Droptica has published three informative ebooks available for free download.
Avi Schwab Sparks Drupal Community Dialogue on governance and transparency through his blog post.
Elsner Technologies lists 15 leading Drupal modules in 2023, authored by Tarun Bansal.
QTA Tech is talking about "Demystifying Decoupled Drupal with NextJS."
DrupalCon NA, scheduled from May 6-9, 2024, in Portland, Oregon, has opened its doors for session submissions. AIR FRANCE, KLM, and code-shared flights offer an exclusive discount of up to 15% for those attending DrupalCon Europe from October 17 to 20, 2023, in Lille, France.
Thanks to Ricardo Sanz Ante, the Behat workshop from DrupalCon Spain is now available on Metadrop's website.
Third and Grove has published Maximizing Drupal's Authoring Experience: A Path to Digital Success by Tara Arnold.
Alphons Jaimon of QED42 explores the application of Retrieval Augmented Generation (RAG) to enhance the capabilities of search engines.
Xandermar LLC LLC offers a pragmatic guide for Drupal 10 users on seamlessly consuming APIs with credentials. The method relies on Drupal's built-in Guzzle HTTP client library, ensuring a straightforward process for developers.
Acquia has launched Acquia Exchange—an integration hub designed to elevate the flexibility and extensibility of its Digital Experience Platform (DXP).
The list is overwhelming, and there is no dearth of stories to share. But there comes some point when we need to put a hard stop. Let there be even more stories in the coming weeks. Let us celebrate Drupal.
Sincerely,
Sebin Abraham Jacob
Editor-in-Chief, The Drop Times.
With Composer and several useful modules, your Drupal 9 site can be upgraded to Drupal 10 as quickly as possible. Here is a step-by-step guide on how to do this and save you time.
Almost everything in the world from our bodies to structures requires proper and timely maintenance to preserve its strength and exhibit effective functioning. Even business websites are no exception. Regular Drupal site maintenance is an integral requirement to keep your business website performing at an optimal level. Outdated software often lacks cutting-edge security tools, new features, and functionalities and exhibits a compromised speed.
Besides, not matching strides with the latest updates can lead to a competitive disadvantage. That said, the stakes of relying on an outdated CMS version are quite high. This blog shines a light on actionable tips for effective and proactive Drupal site maintenance.
Welcome to the Pitchburgh Diaries, a fortnightly update on our progress as we work on our plan for a decoupled Layout Builder using React.
by lee.rowlands / 29 September 2023Let's start with a quick overview of what we've been working on:
You may also be wondering what this is all about!
In case you missed it, at DrupalCon Pittsburgh we successfully pitched to build a decoupled version of Layout Builder powered by React. In addition to that initiative, our team has been working on bringing editorial improvements to Layout Builder in core. My colleagues Daniel Veza, Adam Bramley and Mohit Aghera have been working on this during our internal contribution time and company-wide innovation days.
As part of this, we've been collaborating with key contributors including the subsystem maintainer Tim Plunkett and Drupal core's product manager Lauri Eskola.
Lauri has been doing user research into Layout Builder pain points and trying to frame the long-term direction for Drupal's page building experience.
Lauri was able to take us through some wireframes he's been working on in this space and these aligned well with our plans for a decoupled layout builder.
I encourage you to review these and provide feedback in the core ideas queue issue.
So, now you know the background, let's get into a summary of what we achieved in the first two sprints.
One of the deliverables for our bid is to create a persistence layer in Drupal to allow retrieving and updating the layouts from the decoupled editor.
With JSON:API in core, this felt like a natural starting point. We spent time reviewing the current patch to add JSON:API support to layout builder. There are some issues with this patch as follows:
The JSON:API specification states that relationships must be present as a top-level field in a resource object. This is so related content is addressable.
With layout builder data there are a number of related resources as follows:
The current patch just emits the section and component data as is and does not provide a way for these relationships to be surfaced at root of a resource object under a relationships key.
So if we were to take a step back and think about how we would provide Layout Builder data and comply with the JSON:API specification – how would it look?
Going back to the data model we would need to allow addressing sections and components.
This would allow us to have a 'sections' field in the top-level resource as a relationship.
However, at present sections in Layout Builder data do not have identifiers. There is an open issue to add this but that's only part of the issue. The larger issue is that if we needed to fetch a section resource, we have no way of retrieving it by ID. This is because Layout Builder data is stored in a blob inside a SectionList field on the entity to which the layout is attached. To achieve that we'd then need to maintain some sort of 'component index' table. This would allow us to retrieve the layout entity based on a section ID. We would probably have to vary each section resource based on the layout plugin, just like we do for nodes by node-type. For example, we'd have a section--onecol and a section--two-col resource.
So let's say we had that. The next issue we have is we need to be able to address components. These do already have a UUID, but again that information is only stored in the field blob. That means we'd need to extend our 'component index' idea to also support looking up a component.
Then from there, we need to be able to distinguish between fields/properties on a per-component basis. For example, an inline block component has a reference to a block content entity via a relationship. Other components (block plugins) don't. We would therefore need to vary resource types by block plugin ID. As a result, we might have component--inline-block and component--field-block--node--field-media.
With all those pieces in place, we should be able to achieve addressable resources for all of the related data in Layout Builder. However, the query to retrieve all the information we need would be quite involved, as it would need to traverse from node to section to component to block content or media.
All of this is only thinking about retrieval. We also need to be able to persist changes, particularly to block content for inline blocks. When a layout is updated we would need to write changes to the block content, then to each component, then to each section and finally to the entity the layout applies to. Each of these would be a separate HTTP request. What happens if one of those requests fails? How would we recover from that state? JSON:API has already thought of this issue and has an atomic extension in the specification.
However, there is no existing implementation of this extension for Drupal, so we'd also need to write that.
Considering all this work and the limited size of the budget for this project, we decided that JSON:API isn't a good fit at this time. We intend to open a meta and child issues for each of the discreet pieces of work that would be required to build a JSON:API compliant endpoint for Layout Builder.
As we decided not to use JSON:API, we were able to design an API specifically tailored to the work we're doing. But we need to make sure to document it. Open API is the best way to do this as we can auto-generate rich documentation with tools such as Swagger UI.
We have finalised the API specification in the Decoupled LB API module on Drupal. Oh, and did I mention that Gitlab automatically turns this into interactive documentation with Swagger UI. 😮😍
We have started work on implementing this and have working versions of the following operations including test coverage:
Part of this involved some key decisions around how block plugins in Drupal will interact with React. More on that later.
There is some overlap in the work we're doing with the Gutenberg project, another Pitchburgh grant winner. As a result, we've been catching up with that team to ensure we aren't duplicating effort.
One such issue we identified was that both projects will need a shared way to load React from Drupal. At present, the Gutenberg module includes a transpiled version of React and React DOM and is loading these from a libraries definition.
As we will also need to do similar and we don't want to end up with two versions of React loaded from Drupal, we identified that we'd need a common shared module to do this.
We approached the maintainers of the Drupal 7 React module and asked if we could be added as maintainers to use this namespace for that purpose. The maintainer David Corbacho was happy to oblige. Thanks, David!
Our next step was to get a local development setup that allows Front-end developers to contribute to the project without needing to setup Drupal. This includes tooling that front-end developers expect including:
To keep track of the layout state, we chose Redux to support global state management. One of the features present in Lauri's wireframes is Undo and Redo support. Keeping track of state with Redux means this will be simple to implement when the time comes. Using redux also allows us to separate state manipulation from the UI and this means we can easily write unit-tests without needing to simulate interaction.
A key tenet of the layout editing experience is the ability to drag and drop blocks (components). Currently Drupal core supports moving blocks, but not moving sections. There is an active issue to add support for re-ordering sections. One of our goals is to support that functionality from the onset.
Drag and Drop in React is not unique to this project so we did an evaluation of existing React drag and drop libraries. The two we focussed on were react-dnd and react-beautiful-dnd.
After reviewing both packages we decided to go with react-beautiful-dnd. It features keyboard control, auto-scrolling of drop containers and screen-reader support. It was written by Atlassian (creators of Jira, Confluence etc). The only item of possible concern here was that it is no longer under active development. It is however still doing releases for security issues etc. We rejected react-dnd because of its lack of built-in support for keyboard control, screen reader and scrolling. There is also an active security report in its issue queue that has not yet been responded to.
If we get into issues with the 'no further development' status of react-beautiful-dnd, there is a sympathetic fork, however, it hopefully won't come to that. Another plus in the react-beautiful-dnd column is that it was used by puck, an existing React-powered layout editor. We evaluated that as part of this project and it provides some great inspiration, but doesn't fit with Drupal's data model or the longer-term goals for in-place editing seen in Lauri's wireframes.
After selecting this we set about building a prototype using it to validate the API and have dragging blocks and sections working.
Screenshot of dragging and dropping videos, click to view videoOne of the driving factors behind the design of the layout builder in React is it must map back to existing concepts in Drupal. We're building a layout editor, but Drupal will still need to be able to render the layout in the front end once the layout is saved.
To manage this we've designed an API for React components that is familiar to concepts in Drupal. We have built proof of concepts of Block plugins, Layout plugins and Formatter plugins.
We've built a hook system to support retrieving entity view display information client-side.
To validate all of this we built an InlineBlock React component that maps to the InlineBlock plugin in Drupal core. The video above showing blocks being dragged around makes use of these components. Each component returned from the API includes a plugin ID and in the proof of concept these map to a React component.
In the example, you see the InlineBlock component taking the values from the API, reading entity view mode information and using that to hand off rendering to formatter plugins. Similarly, the API returns sections using their Drupal plugin ID. These are mapped to React components so a one-column component handles the one column seen in the example and a two-column one handles the two-column component.
This ensures that each component is in control of its markup, just like in Drupal with Twig. Regions are handled by a Region component that abstracts away the drag-and-drop functionality. Each Layout plugin just needs to emit the region and even has control over the markup. In the example, the right column of the two-column layout uses an aside element.
Here's how that looks in code:
import React from "react";
import { LayoutPluginProps } from "../../state/types.ts";
import Region from "../LayoutEditor/Region.tsx";
export const Preview: React.FC = ({
section,
sectionProps,
regions,
}) => {
return (
);
};
export const id = "layout_twocol_section";For those of you familiar with a layout twig template in Drupal, this will look pretty familiar. You are given some section props to output on the outer container, just like the attributes you get in twig. You are given a map of region data and you can place the Region component where you need it, the only requirement is that you pass along the ID in the regionId prop. This isn't that different from the region_attributes variable in twig.
All of this is booted from a single LayoutEditor component that takes a registry of block, layout and formatter plugins. As work progresses this will expand to include widgets too.
Each of these registries is a map where the keys are the plugin IDs and the values are a promise that will load the component. In our local development setup, we're using Vite's glob support to automatically load all plugins in a given folder. Our thinking is in the Drupal space we will use an alter hook to add additional properties to plugin definitions and then use drupalSettings to emit a mapping of plugin IDs to file paths. We will be able to use the built-in import function with the file paths to provide the promises.
So for example, a hook block alter will add a property to each block plugin for the file path of that equivalent React component. This will allow modules and themes to alter that definition and swap out a component provided by default with their own implementation in React that is specific to their project. We will collate all of these when booting the LayoutEditor in Drupal and pass that via drupalSettings into the entry point. We will do something similar for the other plugins.
All of this also relies on allowing block plugins in Drupal to have control over the data that is sent in the API. For instance, in the inline-block example, it needs to be able to pass along the block content entity's field values for rendering/editing sake.
The current API handles this using Drupal's existing serializer. The decoupled LB API module adds a normalizer for SectionListInterface objects (how layouts are modelled in Drupal). This loops over each component and normalizes an instance of the relevant block plugin. The default block plugin normalizer just extracts the block configuration. However, due to how Drupal's serializer works, any module can add a new normalizer that targets a more specific class than BlockPluginInterface and give it a higher priority, then modify how the data is sent.
To support working with inline blocks, we've added a normalizer for the InlineBlock plugin that intersects the block content fields with that of the configured view mode and passes those along. In the example above you can see we're rendering the body field of the block. This will also provide us with the implementation point for dealing with persisting updates. We will be able to mutate these properties in the layout as edits occur and send them back to Drupal. The normalizer will be able to denormalize the incoming values and put them back in the format Drupal expects so that saving the layout works the same as it does now.
We've made significant progress in the first two sprints. Our high-level goals for next sprints are:
Thanks to my colleagues at PreviousNext who've been a great sounding board in validating some of these design decisions, in particular Daniel Veza who has helped to workshop many of these ideas.