Suchi Garg at DrupalSouth 2024 Suchi’s workshop at DrupalSouth 2024 on Day 2 prepared first-time contributors for the code sprint. The session focused on the dynamics of mentored contribution and explored the benefits and types of contribution, tooling and documentation, and more. View the presentation description on the DrupalSouth websiteMing Quah at DrupalSouth 2024 Ming’s DrupalSouth 2024 presentation was on Day 2 of the event. The session gave attendees an overview of the NIST domains and showed what Drupal developers and DevOps specialists should do to comply with the NIST CSF. The framework was analysed in the context of seven key layers for Drupal security. View the presentation description on DrupalSouth websiteAcross its 50-year history, the Sydney Opera House has welcomed musicians, dancers, actors, playwrights, filmmakers, contemporary artists, and thinkers who have both challenged and defined the cultural scene. As a result, the Sydney Opera House draws millions of visitors from around the world each year.
Not only is the Sydney Opera House of incredible cultural importance, it's also an architectural masterpiece. Its unique design makes it one of the most iconic buildings in the world, and has earned it a place as a UNESCO World Heritage Site.
Last year, the Sydney Opera House chose to migrate its website to Drupal. Today, it is running Drupal 10. The decision by such a prestigious institution to relaunch their website on Drupal highlights Drupal's flexibility, security, and ability to manage complex websites.
A couple of weeks ago, during my visit to Australia, I met with the Drupal team at the Sydney Opera House. I was particularly impressed by the team's dedication to using Open Source to expand cultural access and their enthusiasm for collaborating with other arts and cultural organizations. Their focus on innovation, inclusivity, and collaboration perfectly aligns with the core values of Open Source and the Open Web. Drupal is such a great solution for them!
Sending Drupal 10 website Emails through Googles SMTPTo ensure your Drupal 10 website can send emails, like password reset links, you must configure the SMTP Module, especially after Google’s policy change on September 30, 2024, which prohibits the use of less secure apps. This guide will show you how to set up the SMTP Module in Drupal 10 for sending password reset emails and other form submissions via Gmail.
Before you begin, ensure you have the necessary tools. You will need Composer and Drush installed on your computer. Additionally, you must have access to a Gmail account and its password, which will be used to send the emails. Follow these steps to configure SMTP in Drupal 10, ensuring your site’s email functionality is uninterrupted by Google’s security updates.
Note: The instructions below are for a standard Gmail and have not been tested on a Google Workspace email address.
How to Configure the SMTP Module in Drupal 10 with Gmail, Since Google Removed Less Secure Apps was originally published in Drupal Atlanta on Medium, where people are continuing the conversation by highlighting and responding to this story.
Steve Worley at DrupalSouth 2024 — Day 1 Steve’s session on Day 1 at DrupalSouth 2024 looked at the benefits of a static Drupal website and different static options, including QuantCDN . From security and performance to scalability and greenness, the session explored the many big wins of static Drupal. View the presentation description on the DrupalSouth websiteDrush, the brilliant command-line tool for Drupal, is capable of giving you its output in several ways. Its global --format parameter can be set to a type that you can use in useful ways. Most recently, I found this incredibly useful when I had made some configuration changes through Drupal's admin pages, and needed to then script those changes to automatically apply to hundreds of sites on a platform we manage.
I simply asked Drush for the value of the configuration I had set, formatted as the PHP code to set those values. Then I could drop that into our PHP automatic update script. Here are two examples - one getting just a single property of a block placement, and another for the whole settings object for a module.
# Get the visibility conditions of my block.
drush config:get block.block.myblock visibility --format=var_export
# Get the whole settings singleton for my module.
drush config:get mymodule.settings --format=var_exportThe var_export format provides the output using PHP's traditional array syntax, instead of the default YAML (which matches the format of config export files). Here's an example of the output for another type of configuration, an action:
array (
'uuid' => 'faaaea7f-d377-4b9c-bbfb-bd1b9c562050',
'langcode' => 'en',
'status' => true,
'dependencies' =>
array (
'module' =>
array (
0 => 'mymodule',
),
),
'_core' =>
array (
'default_config_hash' => 'vvt7bzrXEwxrTfY--axzCfSRPzggH0o4hahUY9Kh0z0',
),
'id' => 'mymodule_foo_action',
'label' => 'An example action',
'type' => 'webform',
'plugin' => 'mymodule_foo_action',
'configuration' =>
array (
),
)Then I could just copy the output and paste it into a post-update hook. My IDE makes it easier to prettify the code to match Drupal's coding standards and switch to PHP's newer short array syntax. I also removed all the bits that I could leave to be dynamic; like the uuid, _core, and empty configuration properties in the action example above. I can then either use the entity storage for my type of entity to save the configuration, or just use the Configuration Factory service more directly:
$data = // (Paste & adapt the output from drush for this variable.)
// Example of using the config factory.
$config = \Drupal::configFactory()->getEditable('block.block.myblock');
// Using `setData()` will replace the entire config array. We could instead
// use `set()` for individual properties.
$config->setData($data)->save();
// Alternatively use the entity type storage and specific methods, when
// available. Create new entities with `$storage->create($settings)->save()`.
$storage = \Drupal::entityTypeManager()->getStorage('block');
$storage->load('myblock')->set('settings', $data['settings'])->save();We tend to automate Drupal core's configuration management on most of our projects - but not always. Even where we don't, there is usually some config that we exclude from the automated management - usually to allow clients to make changes in the admin UI without needing to access the codebase. So this is a handy trick to have available when you just need to script some changes outside of config management.
Under the hood, the consolidation/output-formatters library is what provides output formatters. If you run drush help version you can get a list of other standard formatters, which includes:
yaml
The key-value format usually used for configuration exports.
csv
Comma-separated values; ideal for simple lists
php
The format that PHP's internal serialize() method produces.
var_dump
Probably my new favourite; as produces coloured syntax highlighting in the terminal output! It is powered by Symfony's VarDumper component. I have found this particularly useful recently when debugging the output from a remote API endpoint, to help me visually parse clumps of output.
As a bonus, this can be useful for quickly loading up an entity to inspect its field values:
getStorage('taxonomy_term')->load(11)->toArray());" --format=var_dump`" data-entity-type="file" data-entity-uuid="9930f0b8-e138-4ae8-8432-1e42a2e7086b" src="https://www.computerminds.co.uk/sites/default/files/inline-images/drush-var-dumping.png" width="692" height="834" loading="lazy" />
My output from drush php-eval "return array_filter(\\Drupal::entityTypeManager()->getStorage('subscriber')->load(127)->toArray());" --format=var_dump
...which feels rather like a good case for a custom drush command, just taking an entity type and ID as arguments ;-)
What other handy uses of specifying an output format can you come up with? Let me know!