DRUPALDEALS.COM

PreviousNext: Adding real-time processing to QueueWorker plugins

Projects no longer need to rely on unpredictable processing time frames. The SM project can intercept legacy Drupal @QueueWorker items and insert them into the Symfony Messenger message bus, effectively giving existing core and contrib queue workers jobs real-time processing capabilities.

by daniel.phin / 7 February 2024

This post is part 5 in a series about Symfony Messenger.

QueueWorker plugins

@QueueWorker plugin implementations require no modifications, including the method of dispatch, data payload, or the processItem . The data payload must of course be serialisable. Fortunately, most QueueWorker plugins already comply since their data is serialised and stored to the queue table. As always, avoid adding complex objects like Drupal entities to payloads.

Runners

With queue interception, the sm command can be solely relied upon. Legacy runners such as Drupal web cron, request termination cron (automated_cron.module), and Drush queue:run will be rendered inoperable since they will no longer have anything to process. Consider decommissioning legacy runners when deploying queue interception.

Setup

Queue interception is a part of the primary SM module. Adding a single line in settings.php is the only action required to to enabling this feature:

$settings['queue_default'] = \Drupal\sm\QueueInterceptor\SmLegacyQueueFactory::class;

SM module will need to be fully installed before this line is added. Consider wrapping the line in a class_exists(SmLegacyQueueFactory::class) to enable in a single deployment.

Existing per-queue backends

Setup may be more complex if projects are utilising per-queue backends or anything other than the default database backend for queues, such as Redis. In that case, carefully evaluate whether to convert all or specific queues to use Symfony Messenger.

Whether per-queue backends are utilised can be determined by looking for queue_service_ or queue_reliable_service_ prefixed items in settings.php.

Routing

@QueueWorker jobs are converted to \Drupal\sm\QueueInterceptor\SmLegacyDrupalQueueItem messages in the backend. Knowing this class name allows you to configure transport routing. If routing for this message is not explicitly configured, it will naturally fall back to the default transport, or execute synchronously if there is no routing configuration.

Running the jobs

As usual, when a transport is configured, all you need to do is run sm messenger:consume to execute the tasks. The worker will either listen or poll for messages, and execute them in a very short amount of time after they are dispatched, in a dedicated thread. More information on the worker can be found in post 3 of this series.

The next post covers how Drupal emails can be dispatched to messages, so the web thread can execute faster.

Tagged

Symfony, Symfony Messenger

Drupal Core News: DrupalCI and all patch testing will be turned off on July 1, 2024

To continue automated testing, projects must convert to GitLab CI and contributors must switch from patches to merge requests by July 1, 2024.

As of July 2023, contributed projects are fully equipped to adopt GitLab CI. In October 2023 we announced that Gitlab CI testing of Drupal core was already five times faster than the legacy DrupalCI system. In our December 2023 maintainer email we announced that our legacy DrupalCI will be retired as soon as July 2024. Now we are announcing further details.

What's happening?

Some DrupalCI features are already turned off

Projects without DrupalCI testing configured cannot add it anymore. Direct access to log output and artifacts on DrupalCI is no longer available. Results are still summarized on the Automated Testing tab of those project's pages.

With the exception of Drupal 7, it is not possible to run tests on patches against Drupal core anymore. Even for Drupal 7, patches need to be sent for testing manually.

Changing DrupalCI schedules ends on April 30, 2024

After April 30, 2024, DrupalCI schedules can not be added or changed, except to remove DrupalCI testing. Tests will keep running with existing configured schedules until removed.

DrupalCI and all patch testing will be turned off on July 1, 2024

No DrupalCI tests will be executed after this date. It will also no longer be possible to run tests on any patches on Drupal.org on any project. Existing test results will be kept for six months.

All results from DrupalCI tests will be removed on January 1, 2025

This is the end of DrupalCI data retention. No testing results will be available beyond January 1, 2025.

What to do about it?

Most projects can start GitLab CI testing with a provided template .gitlab-ci.yml

Using GitLab CI for testing may seem intimidating at first but the Drupal Association engineering team and a number of community volunteers have spent a lot of time to make it as easy as possible for you to adopt GitLab CI for testing.

There is a preconfigured .gitlab-ci.yml template that will set up everything you need to test your project. This template has several useful features, including a variables file that will be automatically updated by the Drupal Association, to make sure you’re always testing against the currently supported versions of Drupal.

Most project maintainers won’t have to make any changes to the template, just commit the template to your project and your testing should work right away!

Set up GitLab CI for your drupal.org project today.

Contributors must use merge requests on all projects to get automated testing after July 1, 2024

GitLab CI, like almost all modern CI systems, is designed to test merge requests. If you have ever contributed to a project on GitHub, you pretty much already know how it works. The advantage of Drupal.org merge requests is that they are collaborative by default, so you and fellow contributors can work in the same fork.

Read the best practices for contributing through merge requests.

Factorial.io: A weekend dedicated to Drupal CMS

For years, the last weekend in January has been a special one for the worldwide community behind the CMS system Drupal: The Global Contribution Weekend. Factorial has been a major contributor to the Drupal community for many years, so we hosted our own hybrid Global Contribution Weekend event.

DrupalEasy: Why you should care about using settings.local.php

Teaching folks why a settings.local.php file is an important part of setting up a personal development environment is so important to us here at DrupalEasy that it is a foundational part of both of our long-form Drupal training courses.

While preparing for an upcoming podcast mini-series I've been invited to participate in with the Talking Drupal folks, I'll be mentoring someone who is looking to re-enter the Drupal development scene after missing out on Drupal's transition from its pre-Symfony days. One of the tasks I have outlined for this person is to set up a settings.local.php file. When I went to find a good resource for the "why" and the "how", I came up empty. I couldn't find a single, up-to-date resource that conveyed what I feel is important.

So, that's what this blog post is all about.

Why use settings.local.php?

Using a settings.local.php is all about configuring your local development environment for a project to be as useful to you, the developer, as possible. Default settings in this file do things like force all errors to the screen and disabling some of the (but not all) Drupal caches.

This file also pulls in the sites/development.services.yml file which contains some useful service class parameters and overrides - again, things that are useful for local development.

Setting up a settings.local.php literally takes less than two minutes, and when I see a Drupal developer struggling to figure out a white-screen-of-death error on their local environment, I can't help but 🙄

In addition to adding Drupal's core-dev dependencies and the Devel module, enabling the settings.local.php file is literally one of the first things I do when setting up a new site.

How do I enable the settings.local.php?

I'm so glad you asked.

Step 1

Copy sites/example.settings.local.php to sites/default/settings.local.php. Use a user interface (like the MacOS Finder) or the command line - it doesn't matter.

cp web/sites/example.settings.local.php web/sites/default/settings.local.php

Step 2

Uncomment the conditional include for settings.local.php in your sites/default/settings.php file - it looks like this:

#  if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
#   include $app_root . '/' . $site_path . '/settings.local.php';
# }

Uncommented, it looks like this:

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
 include $app_root . '/' . $site_path . '/settings.local.php';
}

Step 3

There is no step 3. This blog post is complete.

Specbee: Style Made Simple with Acquia Site Studio’s Style Guide Manager

Ever wished you could tweak your web page’s header font or switch up your CTA color, but skipped it to save your developer from the hassle? With Acquia Site Studio’s Style Guide Manager, you don’t have to! Non-technical content marketers now have the power to make styling tweaks to their Drupal site theme via an intuitive interface. Are you interested in learning more? Come on in! What is Site Studio Style Guide Manager Previously Acquia Cohesion, Site Studio is a composable, low-code digital experience tool by Acquia that enables users to build and assemble pages with less to no code. Check out our previously written article about how to build component-based websites on Drupal using Site Studio. Style Guide Manager is an optional module that you can enable within Site Studio. It centralizes the design elements like colors, typography, and components in one place, making it easier to maintain a cohesive look and feel throughout your site. It provides a set of style guides that are theme-specific. You can create style guide(s) to manage Site Studio styles within your Drupal theme settings. You can even override your theme styles using the Style guides. Advantages: Change the appearance of your Drupal website based on the active theme. Apply global styles and change the appearance with a simple-to-use interface. Create design systems for multi-brand and multi-sites. Style guide manager has two interfaces: Style guide builder Style guide Style Guide Builder The Style Guide Builder is a tool within Acquia Site Studio that allows you to actively create and manage the Style Guide. It streamlines the process of updating and maintaining the design standards. Changes made here are automatically applied throughout the site. Style guide The output of a Style Guide Builder - a set of design guidelines, is the Style Guide. The Style Guide is a collection of design rules, standards, and components that define the visual appearance of your website. Creating a Style Guide First, make sure you have installed Acquia Site Studio. Navigate to /admin/cohesion/style_guides Click on Add Style guide Add the Title Click the + button below the Style Guide form to add the form fields. Add the fields such as Font picker, Color picker, etc. with the combination of form layout fields such as Group accordion, and Tabs as per your requirement. Give a meaningful name for the Field Label so it will generate a meaningful token. This is how your Style Guide creation page will look like: You can also see the preview below of your Style Guide form builder and how it looks on the theme settings. Click on Save and Continue Managing your Styles Now that you have successfully created a Style Guide, let's see where and how you can manage your styles. Navigate to your theme appearance settings (here mine is: /admin/appearance/settings/techx) Add your values such as fonts, colors, etc., and save the configuration. This is how your style guide will look like after successfully saving the configuration. Now, you need to use the Style Guide tokens in the styles to see your styles on the front end as per the Style Guide values. Tokens are predefined variables or placeholders representing design elements such as colors, typography, spacing, and other visual properties. This is not just restricted to styles, you can use these tokens throughout your Site Studio like templates, or components as per your requirements. For example: Make sure you enable the token variable mode and then add your tokens. Implementing the Style Guide With Site Studio’s Style Guide Manager, you can create multiple style guides as per your requirements. You can see all of them in your theme settings as shown below This is what my front end looks like. You can change the values in the Style Guide per your requirements and verify the page/site accordingly. Final Thoughts Site Guide Manager is a very useful tool for non-technical users like content editors and marketers to see all the styles in one place with an easy-to-use user interface and modify them according to their choice. All of this without depending on a developer. Are you looking to build highly engaging, omnichannel, and result-driven solutions with Acquia and Drupal? We are Acquia partners and we know what it takes to get you there. Talk to us today to find out more.

PreviousNext: Automatic message scheduling and replacing hook_cron

Symfony Scheduler provides a viable replacement to hook_cron wherein messages can be scheduled for dispatch at a predefined interval. Messages are dispatched the moment they are scheduled, and there is no message duplication, making tasks more reliable and efficient.

by daniel.phin / 6 February 2024

This post is part 4 in a series about Symfony Messenger.

With this, the sm worker provided by the SM project, the Symfony Messenger integration with Drupal, can be solely relied on. Rather than legacy runners such as Drupal web cron, request termination cron (automated_cron.module), Drush cron, and Ultimate Cron.

Scheduler functionality is implemented by the Symfony Scheduler component. The Drupal integration is provided by the SM Scheduler module

Schedule provider

Create a message and message handler as usual, then create a Schedule Provider:

<?php

declare(strict_types = 1);

namespace Drupal\my_module\Messenger;

use Symfony\Component\Scheduler\Attribute\AsSchedule;
use Symfony\Component\Scheduler\RecurringMessage;
use Symfony\Component\Scheduler\Schedule;
use Symfony\Component\Scheduler\ScheduleProviderInterface;

#[AsSchedule('my_scheduler_name')]
final class MyScheduleProvider implements ScheduleProviderInterface {

  /**
   * {@inheritdoc}
   */
  public function getSchedule(): Schedule {
    return (new Schedule())->add(
      RecurringMessage::every('5 minutes', new MyMessage()),
    );
  }

}

A schedule provider is:

a class at the Messenger\ namespace
with a #[AsScheduler] class attribute
implementing \Symfony\Component\Scheduler\ScheduleProviderInterface
implements an getSchedule method. This method returns a message instance and the schedule frequency.

For dependency injection, schedule providers have autowiring enabled.

What would normally be the contents of a hook_cron hook would instead be added to the message handler. The message itself does not need to store any meaningful data.

Instead of intervals via RecurringMessage::every(...), crontab syntax can be used:

\Symfony\Component\Scheduler\RecurringMessage::cron('*/5 * * * *', new MyMessage());

Running the worker

Lastly, schedulers must be run via the consume command with a dedicated transport. The transport name is the schedule ID prefixed by scheduler_. For example, given the scheduler ID my_scheduler_name from above, the transport name will be scheduler_my_scheduler_name.

The command finally becomes: sm messenger:consume scheduler_my_scheduler_name .

Timing

Messages will be dispatched the moment their interval arrives. Normally intervals begin when the worker is initiated, however you can set a point in time to begin interval computation using the \Symfony\Component\Scheduler\RecurringMessage::every $from parameter.

The worker must be running at the time when a message is scheduled to be sent. The transport won't retroactively catch-up with messages not dispatched during the time it wasn't running.

The next post outlines how to intercept legacy Drupal @QueueWorker items and insert them into the message bus.

Tagged

Symfony, Symfony Messenger, Symfony Scheduler, Cron

Web Wash: Getting Started with Webform in Drupal (2024)

Webform is a Drupal module that allows you to create forms directly in Drupal without using a 3rd party service.

It can be used to create basic “Contact Us” and complex application forms with custom field logic and integration.

In this getting started guide you’ll learn how to:

Create a form
Add elements to form
Customize form with conditional logic
Embed the form
Send submissions to Google Sheets

This tutorial accompanies the video above.

DrupalEasy: DrupalEasy Podcast S16E4 - Kevin Quillen - Drupal 10 Development Cookbook

We talk with Kevin Quillen, author of Drupal 10 Development Cookbook, published in February, 2023 by Packt Publishing.

URLs mentioned

DrupalEasy News

Professional module development - 15 weeks, 90 hours, live, online course.
Drupal Career Online - 12 weeks, 77 hours, live online, beginner-focused course.

Audio transcript

We're using the machine-driven Amazon Transcribe service to provide an audio transcript of this episode.

Subscribe to our podcast on iTunes, Google Play, iHeart, Amazon, YouTube, or Spotify.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Credits

Podcast edited by Amelia Anello.

Talking Drupal: Talking Drupal #436 - Drupal & AI

Today we are talking about AI within Drupal, How AI can help, and Modules to use with guest Martin Anderson-Clutz. We’ll also cover Augmentor AI as our module of the week.

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

Topics

Terminology
IMF analysis
Prompt engineering
AI in Drupal
Best way to try modules
Best use of AI
Other ways of integrating

Resources

Augmentor AI
Open AI
Prompt Engineering: Get the Most From Your Drupal Site's AI Integration
Terminology
- NLP - work with text provided in a conversational format, understand the intended meaning, and provide a relevant response
- AI - A subset of CS that aims to develop systems that can mimic human response, or automating sophisticated behavior
- ML - subset of AI that aims to act without explicit guidance, by extrapolating from known data
- Deep learning - a subset of ML which uses artificial neural networks with representational learning to develop and leverage their own means of classification and other feature detection
- LLM - an AI algorithm that uses Deep Learning techniques to accomplish NLP tasks such as responding to unstructured user prompts. LLMs are trained on massive data sets, often gathered from the internet, but sometimes using more specialized data
- Typically the AI interfaces our listeners are already using are based on an LLM, but the nature and recency of the data they’ve been trained on can vary widely. Recently Mike Miles created Drupal Droid, a GPT model specifically trained for Drupal developers, and you can find a demo of that in our YouTube channel
Mike Miles Drupal Droid
AI module list
OpenAI Image
Search API Pinecone
TMGMT Translator OpenAI

Guests

Martin Anderson-Clutz - mandclu

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi

MOTW Correspondent

Martin Anderson-Clutz - mandclu Augmentor AI

Brief description:
- Have you ever wanted a highly configurable way to integrate multiple AI services with your Drupal site? There’s a module for that.
Brief history
- How old: created in Oct 2022 by murrayw of Morpht, though recent releases are by elonel
- Versions available: 1.1.2 which works with Drupal 9.5 and 10
Maintainership
- Actively maintained, most recent release was earlier this month
- Documentation available
- Number of open issues: 11, 3 of which are bugs
Usage stats:
- 82 sites
Module features and usage
- To use Augmentor AI, you need to define one or more “augmentor” configuration entities. An augmenter entity implements an augmentor type, which determines what AI service it can use, what configuration options it will have available, and so on.
- The augmentor will define one or more “messages” that provide structure to the prompt that will be passed to the AI model in order to generate a response. It can also be configured in a variety of ways, such as how much randomness to use, a maximum response length, and more.
- You can expose your augmentor(s) to content creators by adding a CKEditor button, or by adding fields to your site’s entity forms. For each field use can choose the widget to use, and how it should interact with any existing data in the field you want to target.
- For example, you could have it generate a summary from your body field and have it automatically populate the summary field. Or, you can have it suggest tags, but the specialized widget renders each suggestion as a clickable element that will add the tag to a core tag field.
- There are currently modules available to integrate Augmentor AI with ChatGPT, Google Cloud Vision, AWS AI, and more.

The Drop Times: Beyond Code: A Decadal Odyssey with Drupal

Explore the dynamic journey of Jorge Lopez-Lago, seasoned Solutions Architect at FFW, as he shares his diverse experiences and insights in an exclusive interview with The Drop Times, offering a glimpse into his evolution from a hands-on Drupal developer to a multifaceted leader and his unique approach to problem-solving and community engagement.

Subscribe to