Today we are talking about Drupal Architecture, Common Site Building questions, and How we solve things with Drupal with guest Alexander Varwijk. We’ll also cover Drupal 10.3 as our module of the week.
For show notes visit: www.talkingDrupal.com/457
TopicsAlexander Varwijk - alexandervarwijk.com Kingdutch
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Baddý Sonja Breidert - 1xINTERNET baddysonja
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Dries Buytaert once predicted that AI bots would provide factual information and communicate with emotions and personality, offering more human-like interactions than websites.
Artificial intelligence technologies have recently begun to be actively used in various fields, including web development. But what exactly? Implementing AI into your Drupal-based website opens up vast opportunities to improve your business's efficiency, significantly improve your customers' service quality, and much more. In this article, you will learn how to achieve success by using AI and Machine Learning in Drupal.
Artificial Intelligence (AI) has quickly become a cornerstone of technological innovation. But why is it needed, and how exactly is it changing our lives? To start, imagine a world where machines can predict what you want before you even ask for it. That's the promise of AI, and it's no longer a distant dream.
AI is reshaping industries by automating routine tasks, providing insights through data analysis, and enhancing user experiences with personalization. For instance, in healthcare, AI algorithms can analyze medical records to predict patient outcomes and suggest treatments, drastically improving care quality. In finance, AI-driven systems can detect fraudulent activities in real-time, safeguarding our money and financial data.
Moreover, AI impacts our daily lives more subtly. Think of how Netflix suggests shows you love or how Alexa can answer your questions and control your smart home. These AI-driven features are making life easier and more enjoyable.
Now, let’s introduce AI to Drupal, a powerful content management system (CMS) known for its flexibility and robust features. Integrating AI with Drupal opens new possibilities for web development, making websites smarter and more user-friendly. AI can analyze users' likes and tailor website content to their interests. This means two people visiting the same site might see different content based on their preferences, making their experience more engaging.
Customer support is another area where AI shines. AI chatbots on Drupal sites can answer questions instantly, providing support without making users wait. These chatbots learn from each interaction and improve over time.
AI can also help predict what users will do next. By analyzing user data, AI provides insights into trends and behaviours, helping site administrators make better decisions about content and marketing strategies.
AI is excitingly changing technology, making our lives easier and more efficient. When combined with Drupal, AI takes website development to the next level. From personalizing content and improving search to automating tasks and enhancing customer support, AI makes Drupal sites smarter and more responsive. As AI continues to evolve, it will bring even more improvements, making online experiences better for everyone.
Now, let's delve into the latest Drupal-related news stories and articles covered by The Drop Times:
Check out the article by Alka Elizabeth and Kazima Abbas, sub-editors at The Drop Times, on Drupal Developer Day Burgas. They share insights from the organizers Valery Lourie, Maria Totova-Cholakova, and Hristo Chonov, representing Drupal Bulgaria, as well as speakers Frederik Wouters and Klaus Purer. This year’s event gathered community members to discuss innovative sessions and projects, showcasing how this event is contributing to the future of Drupal.
Additionally, explore the transformative vision behind Drupal Starshot through the insights of Gábor Hojtsy and Pamela Barone with Alka Elizabeth. This ambitious initiative addresses Drupal's past criticisms by enhancing user experience and accessibility with innovative UI improvements and pre-packaged feature sets. Delve into the potential and challenges of Starshot and understand how the leadership team is steering Drupal towards a more user-friendly future.
In his article at The Drop Times, Jay Callicott explores the significance of understanding exponential growth, the transformative power of AI in development, and the critical role of prompt engineering. By harnessing AI tools like the DrupalAI modules, developers can innovate with unprecedented speed and efficiency, navigating the accelerating pace of change in the digital landscape.
Daniel Cothran and Nia Kathoni have introduced a new Drupal module, Views CSV Source, designed to streamline the process of displaying CSV data within Drupal sites. Released on March 5, 2024, and updated on June 25, 2024, this module addresses a common need among Drupal users: the ability to easily display spreadsheet data on a web page without the labour-intensive process of populating a database table. Read more about it here.
Hector Ignacio Iribarne has announced the upcoming Broward Drupal Meetup, scheduled for Wednesday, July 10, 2024, from 7:00 PM to 9:00 PM ET. Organized by Ofer Shaal, Jay Epstein, and Hector Iribarne, this user group meeting will take place online via Zoom. The meetup will focus on discussing Drupal Starshot.
The upcoming Network of European Drupal Associations (NEDA) meeting is scheduled for July 16, 2024, from 2:30 to 4:00 PM (Central European Time—Brussels). This virtual gathering aims to connect members of the Drupal community and local Drupal associations across Europe and beyond. The primary focus is sharing experiences, exploring ways to support each other with knowledge and resources, and discussing common challenges and solutions local associations face.
Don't miss Drupaladas #4 event, "PHPStan in your Projects," scheduled for June 28, 2024, at 12:30 p.m. CEST. This virtual meetup, hosted by Jose Luis Bellido Rojas, will be conducted through a Slack huddle in the #drupal-es channel and features a detailed exploration of PHPStan integration in Drupal projects, led by Alvaro J. Hurtado Villegas.
Drupal Camp Asheville 2024, scheduled for July 12-14, 2024, is just around the corner, with only two and a half weeks left until the event kicks off. As attendees arrive, organizers have arranged a special Thursday night baseball game on the evening of July 11 at the historic McCormick Field.
DrupalJam, held on June 12, 2024, at Fabrique Utrecht, brought together the Drupal community for a day of insightful talks and networking. For those who missed this anniversary edition, the event's highlights are now available on the DrupalJam YouTube channel. The channel has uploaded Dries Buytaert's keynote speech and various insightful sessions for viewers to enjoy. It also features an after-movie capturing the event's atmosphere and memorable moments.
Looking ahead, Drupal Gutenberg v4.0, set for release in August 2024, will feature a major UI refactor specifically tailored for Drupal, moving away from WordPress components. It will introduce single-field editing and make the editor entity agnostic, allowing for editing various content types. The update will also integrate with the Drupal Starshot initiative, enhancing the overall Drupal editing experience.
CKEditor recently announced the release of five new plugins for Drupal users, coinciding with the launch of Drupal 10.3. These updates include the CKEditor 5 Plugin Pack 1.1.0 and CKEditor 5 Premium Features 1.2.9, featuring essential technical fixes and new functionalities to enhance content creation.
We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.
To get timely updates, follow us on LinkedIn, Twitter and Facebook. Also, join us on Drupal Slack at #thedroptimes.
Thank you,
Sincerely,
Kazima Abbas
Sub-editor, The Drop Times
One great way to extend your catalog of components is by creating components variations. Variations, in the context of component-driven development, refers to displaying your content in different ways. Variations of a component reduce the need of building new components as well as duplicate code.
In Storybook, variations are known as Stories. In this post I will be using variations and stories interchangeably.
The image below shows how different card stories or variations, can display the same content in many ways.
Fig. 1: Example of multiple variations of a Card component.
Sometimes when building a new component, we can't anticipage how the website will evolve with time and therefore we build components the best way possible at the time of building them. As time goes by and requirements change, we realize that we could have done things differently had we known about the requirements changes. Variations of a component give you a chance to alter how something was built without having to change your entire environment of content architecture.
Some time ago I wrote about principles for building components. Rather than repeating myself, take a quick look at the article and comeback when you are done. You will find those principles not only apply to building new components, but also to building variations of components.
In Storybook, all variations of a component are referred to as "Stories", hence the name Storybook. A story captures the rendered state of a UI component. Developers write multiple stories per component that describe all the “interesting” states/variations a component can support. Here's a visual that describes the official naming and hierarchy Storybook uses.
Fig. 2: Storybook's official naming convention and hierarchy.
First off, I am going with the assumption that you already know how Storybook stories are created and that you have a Storybook instance running. If that's not the case, follow these instructions to get your Storybook environment up and running. You will need NodeJS 20+ and NVM installed on your system to follow along.
Next, let's look at the Card variations we will be creating in this post.
Fig. 3: Example of the different card variations we will build in this post.
The image above shows the Card stories or variations we will build. From top-left to right:
In the interest of time, I have a repo that already includes the base of the Card component so you can focus only on building the variations.
Clone the repo which already contains a project to work with and the Card component.
If you already have a working Storybook environment, copy the components directory (src/components), from the newly cloned repo, into your project.
Switch to the variations branch by running git checkout variations
Run the project as instructed in the README in the repo
In this tutorial, we will use two methods for creating variations in Storybook:
card.stories.jsx to change fields values or hide/show fields, depending on the story requirements.*.yml files to assist with the same fields updates above.We will be using the first method above for all stories except the Card horizontal. The original Card component was built with Twig, but for the variations we will be working exclusively in card.stories.jsx. The current version of the card story looks like this:
import parse from 'html-react-parser';
import card from './card.twig';
import data from './card.yml';
import './card.css';
const component = {
title: 'Molecules/Card',
render: (args) => parse(card(args)),
};
export const Card = {
name: 'Card stacked',
args: { ...data },
};
export default component;
Let me explain the snippet above as this is the foundation for all the variations we will be creating.
First we do a series of imports to collect all the pieces needed to build components and stories:
Next, we set a new configuration object called component, which will serve as the default instance of the card component. This is an arbitrary name and can be anything that makes sense to you.
Inside the component object we have two properties: title and render.
Next, we create our first story by defining a new configuration object called Card, in which we pass a name (Card stacked), for the story and the data variable as args.
Finally, we export the component object as default, which is a React requirement.
If Storybook is running, you should see the new variation which will display the Card stacked. If you need to run Storybook for the first time, in your command line navigate to the storybook directory and run these commands:
IMPORTANT: You need NodeJS 20+ and NVM installed in your system.nvm install
npm install
npm run build
npm run storybook
If all goes well, Storybook should be running showing the Card stacked story under the Molecules folder.
Fig. 4: Example of the Card stacked from which other variations will originate.
card.stories.jsx, and directly after the closing of the Card object (around line 17), add the following object to create a new story:export const CardLightCta = {
...Card,
name: 'Card light CTA',
args: {
...data,
cta: {
modifier: 'button--light',
text: 'Try it now',
url: 'https://mariohernandez.io',
}
},
};
Let's go over the snippet above:
...Card), as a spread operator, so the new story inherits all attributes from the original card....data object as a spread operator to individually update the fields that need updating.cta object and provide each of its properties with the appropriate values:
button--light. This is a predefined modifier class which will turn the CTA white.
Fig. 5: Example of a Card component with a light CTA.
This next story or variation is the small version of the card. The difference between this card and the original one is that this one has no CTA, and its size is ...well, small 🙂
Same as before, add the following snippet to card.stories.jsx directly after the closing of the card with light CTA story:
export const CardSmall = {
...Card,
name: 'Card small',
args: {
...data,
modifier: 'card--small',
cta: '',
},
};
This story is very similar to the previous one from the updates needed point of view. As you can see, the only thing we are doing is passing card--small as a modifier class to the entire component, and since we don't need a button or CTA, we are defining the cta object but its value is empty which will suppress it from printing on the page. If you notice in card.twig, we use a conditional that checks if the cta object exists, otherwise don't print any of the markup starting with the footer tag.
Fig. 6: Example of a small card.
card.stories.jsx, directly after the closing of the previous story, add the following snippet:export const CardNoImage = {
...Card,
name: 'Card no image',
args: {
...data,
modifier: 'card--no-image',
image: '',
},
};
Even more similar to the previous story, this variation only varies from the original story as follows:
card--no-image.image object but leave its value empty.
Fig. 6: Example of a card without image.
The final variation is the Card horizontal. For all previous variations we have done all the changes inside card.stories.jsx, but for this one, we will resource to using an alternative *.yml file. Why you may ask, well, this variation requires a bit more changes and making all those changes inside the stories.jsx file may look a little too busy and not as easy to read the code. That's pretty much the only reason for me to use this method, to keep the code in my stories clean and more readable.
You may have noticed in the project you cloned; inside the card directory we have a file called card-horizontal.yml. This file is almost identical to the original card.yml as far as the fields in it. The only difference is that some of the fields have unique content or no content at all. Let's look at the file before starting.
---
modifier: 'card--horizontal'
image: <img src="/card-square.jpg" alt="Palm trees near city buildings" />
title:
level: 2
modifier: 'card__title'
text: 'Step outside to the outdoors'
url: 'https://mariohernandez.io'
teaser: 'With spring in full bloom, the weather could not be better to take a walk outside and enjoy the beauty of nature.'
cta: ''
card--horizontal. This class will allow us to change the layout of the card to be in horizontal direction.Maybe I exaggerated when I said that this variation has too many changes, but my point is that in cases when your stories do require a lot of changes, using a different yml file may help you keep your stories.jsx file a lot neater and cleaner.
card.stories.jsx somewhere around line 5 (after the last import in the file), add the following import:import dataHorizontal from './card-horizontal.yml';
card.stories.jsx add the following object directly after the closing of the last story:export const CardHorizontal = {
...Card,
name: 'Card horizontal',
args: {
...dataHorizontal,
},
};
card-horizontal.yml and assigned the object name of dataHorizontal. By doing this, any changes we make inside card-horizontal.yml will be reflected in Storybook....dataHorizontal), rather than ...data.card-horizontal.yml, the .jsx file is simply consuming its data to achieve the desired variations.
Fig. 6: Example of a card in horizontal layout.
Now that we have covered both methods for creating variations, know that neither method is better than the other. The decision to use one over the other boils down to personal preferences and sometimes which makes the most sense to simplify the process.
At the end of this process, your card.stories.jsx should look like this:
import parse from 'html-react-parser';
import card from './card.twig';
import data from './card.yml';
import dataHorizontal from './card-horizontal.yml';
import './card.css';
const component = {
title: 'Molecules/Card',
render: (args) => parse(card(args)),
};
export const Card = {
name: 'Card stacked',
args: { ...data },
};
export const CardLightCta = {
...Card,
name: 'Card light CTA',
args: {
...data,
cta: {
modifier: 'button--light',
text: 'Try it now',
url: 'https://mariohernandez.io',
}
},
};
export const CardSmall = {
...Card,
name: 'Card small',
args: {
...data,
modifier: 'card--small',
cta: '',
},
};
export const CardNoImage = {
...Card,
name: 'Card no image',
args: {
...data,
modifier: 'card--no-image',
image: '',
},
};
export const CardHorizontal = {
...Card,
name: 'Card horizontal',
args: {
...dataHorizontal,
},
};
export default component;
This only touches the surface of creating stories, but it is refreshing to know that no matter how complex your components may be, when it comes to having Storybook parse them, the React code in your stories is very minimum. Certainly, there are exceptions, but as I complete the migration of our large Drupal project with many components, some of which are pretty large and complex, we still were surprised how little React code was required of us to write because all the heavy lifting is being done by Storybook, with its contrib extensions, as well as Twig itself.
One of the skills everyone needs to have is asking for help. Whether that’s in our work, our education, or our personal lives, we all need help from time to time. We are focused on work here, but this same basic rules apply in all aspects of our lives.
The right time to ask for help is, like so many things, a balancing act. Struggling through a complex issue can be a great way to learn something new. But often we can short cut that learning by simply asking the right questions at the right time.
On the flip side, if we ask too early not only do we risk missing a chance to build deep understanding, we also risk frustrating colleagues by asking them to do our job.
One short cut for when you need to ask for help is if another team member asks if you have already asked. Generally, I want to have called for support before my PM suggests it. By then they are frustrated that I haven’t already solved whatever the issue is solo.
Given my current role and skill set, I’m often the person who gets called when a project goes sideways. That means I see a lot of places where someone didn’t call for help until they were in crisis. While that’s going to happen to us all from time to time, it’s better to call for help when the problem is small. If you want until the project starts burning down around you, it’s way too late.
You might need help if:
As I said before, asking for help is a balance: you can wait too long, or you can ask too soon. The real trick is hitting the sweet spot.
There are several things you should always do before taking another person’s time.
For me, the hardest part is knowing who to ask.
As a consultant I try to avoid asking questions in places clients may see it. Our clients pay for us to be experts, they do not want to see us asking questions in public – particularly if the question has a simple answer.
As a Salesforce MVP, one of my favorite perks is the MVP Slack channel, where we ask each other questions that run the full range of complexity. While access to a community that hard to access, and that advanced, is a privilege there are other ways to find similar groups like your local user group.
I love having a good internal network of people to ask for help. Most of the places I have worked at as a consultant have had some kind of information place to ask questions and help each other out. If you work in a consultancy find or create such a back channel.
If concerns about being seen by clients isn’t relevant to you, check out this list of 7 Salesforce Communities to Join recommended by Salesforce Ben.
The final thing to know about asking for help, is that it’s important to offer help as well. A good question can be valuable to someone else who has the same issue in the future. A good answer is helpful to both the person who asked the question and the person who looks again in the future.
But offering answers, even if not perfect answers, is a great way to learn and encourage others to seek help. Any time I post a question on Stack Exchange, I try to hunt around for one or two to answer as well. That both allows me to pay it forward, it also helps encourage the tone that people can be experts in one thing while still needing help in another.
Smart people need help, and should be comfortable asking for it.
The post Knowing When to Ask for Help appeared first on Spinning Code.