With the launch of Drupal CMS will be a new trial experience, making it easier than ever for non-technical evaluators to try Drupal, without needing to set up a local environment or any special tools.
I spoke with Matt Glaman, who was leading the Live Preview track in the initial development stage.
Matt has done a lot of amazing work to allow a webserver running Drupal to run directly in the web browser on your computer. How does this work? Matt took PHP, along with a webserver and database engine, and compiled them into WebAssembly, which is a language that runs in the browser, a bit like…
It’s a great blessing to work alongside outstanding women and an enormous joy to see their efforts and contributions recognized.
Anonymous (not verified)
Thu, 12/05/2024 - 07:00
Tags
Website management
Content Management
Drupal Planet
Artificial Intelligence
Today, another automation using the Drupal #AI module -- automatically tag your articles.
With the AI module, its AI Automators submodule, and a provider configured, you can add an automation to any field. With a Tag field on your content, you can edit the field definition and "Enable AI Automator". Give it a reasonable prompt, and it will tag your content for you.
Like most of the AI integrations, the great thing is you can easily edit the tags later if you want to highlight something specific, or if it comes up with something inappropriate.
We use platform.sh to host many of our client Drupal sites, and many of those sites use Solr.
Platform.sh has great documentation for setting up Solr to work with Drupal, and it essentially boils down to something like this in a services.yaml file:
solr94:
type: solr:9.4
disk: 1024
configuration:
cores:
main:
conf_dir: !archive "solr_9.x_config/"
endpoints:
main:
core: mainAnd then a directory of Solr config.
Platform.sh then gives you a nice PHP library that can wire up your configuration into Drupal's settings.php like this:
$platformsh->registerFormatter('drupal-solr', function($solr) {
// Default the solr core name to `collection1` for pre-Solr-6.x instances.
return [
'core' => substr($solr['path'], 5) ? : 'collection1',
'path' => '',
'host' => $solr['host'],
'port' => $solr['port'],
];
});
// The Solr relationship name (from .platform.app.yaml)
$relationship_name = 'solrsearch';
// The machine name of the server in your Drupal configuration.
$solr_server_name = 'solr_server';
if ($platformsh->hasRelationship($relationship_name)) {
// Set the connector configuration to the appropriate value, as defined by the formatter above.
$config['search_api.server.' . $solr_server_name]['backend_config']['connector_config'] = $platformsh->formattedCredentials($relationship_name, 'drupal-solr');
}All nice and simple, and works really well in platform.sh etc.
We wanted our DDEV based development environments to match the platform.sh approach as closely as possible, specifically we really didn't want to have two versions of the Solr config, and we didn't want to have one process for DDEV and another for platform.sh.
We are targeting Solr 9, so we are able to use the fantastic ddev/ddev-solr add-on that does the hard work of getting a Solr container running etc.
The add-on has the option of sending the Solr config (which Drupal can generate) to the Solr server, but then that config isn't the same as the config used by platform.sh. So we wanted to use the option where we make a core from existing set of config on disk. To do this we need a couple of things:
First, we make a 'placeholder' configset by creating a file at .ddev/solr/configsets/main/README.md with the following contents:
This directory will get mounted over the top of by the config from the .platform/solr_9.x_config directory at the root of this repository. See: docker-compose.cm-ddev-match-platform.yamlAnd then we need a file .ddev/docker-compose.cm-ddev-match-platform.yaml with the following contents:
services:
solr:
volumes:
# We sneakily mount our platform.sh config into the place that ddev-solr wants it.
- ../.platform/solr_9.x_config:/mnt/ddev_config/solr/configsets/mainAs the comment in the file says, this means that the same config is both used by platform.sh and the DDEV solr server for the main core.
Finally, we add a bit of a settings.php config for developers running DDEV:
// Hardcode the settings for the Solr config to match our ddev config.
// The machine name of the server in your Drupal configuration: 'solr_server'.
$config['search_api.server.solr_server']['backend_config']['connector'] = 'basic_auth';
$config['search_api.server.solr_server']['backend_config']['connector_config']['host'] = 'solr';
$config['search_api.server.solr_server']['backend_config']['connector_config']['username'] = 'solr';
$config['search_api.server.solr_server']['backend_config']['connector_config']['password'] = 'SolrRocks';
$config['search_api.server.solr_server']['backend_config']['connector_config']['core'] = 'main';And that's it! So simple, thanks DDEV!
As you’ve most likely heard already, Drupal 7's End of Life is fast approaching. Drupal 7 security support is ending one month from today on 5 January 2025 – fourteen years to the day that Drupal 7 was originally released! If you are still running Drupal 7 beyond this date, your website will be vulnerable to security risks and may face compatibility issues.
With only one month left until Drupal 7 security support ends, now is the time to wrap up any final preparations to get your site ready in time for the end of life. While migrating from Drupal 7 may seem daunting, the Drupal Association is here to assure you that the process can be smooth from start to finish with sources like our Drupal 7 migration resource page.
Hopefully, you have started your plan for life after Drupal 7, but if you are looking for direction, here are some paths you can take:
If you plan on keeping your site running on Drupal 7, check out our Drupal 7 Extended Security Support Program, if you haven’t already.
Our D7 extended security support partners are ready to provide you with the support that you need!
On top of engaging an extended support partner, the Drupal Association has also created a list of certified migration partners for sites of all sizes. These partners can help you with your content strategy, audit your existing site, and help you through every step of the migration process to upgrade your site to modern Drupal.
Many folks have already migrated from Drupal 7, and you can find their stories on our case studies page.
If migrating to a newer version or using extended support isn't feasible right now, it’s essential to notify your users of your security strategy. Make sure to inform your customers, managers, CISO, or other stakeholders about your plans for handling support and managing potential vulnerabilities. This transparency is important for maintaining trust and compliance!
In the early days of Drupal, it was a popular blogging platform. Nowadays, while it is rare to use Drupal for a pure blog site, it is still quite common for Drupal sites to include a blog. There even used to be a dedicated blog module in Drupal, but it was largely superseded by Drupal’s core functionality.
The ‘Blog’ recipe for Drupal Starshot is designed to facilitate the creation and management of blog posts on a website. It will create the ‘Blog’ content type, equipped with the necessary fields and features that enable content creators to produce rich, informative, and engaging blog entries…