Steven Jones
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: main
And 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.
DDEV
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.yaml
And 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/main
As 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!