You will need to also deal with a cloud server. if you’re using Lando, I have some basic instructors in my BLT Lando plugin. usually, this involves the standard connector, http protocol, the link to the solr server locally, and the core name. go ahead and disable those for now!Ĭreate a new solr server and call it “local”Ĭonfigure this server based on your local configuration.
if you have the acquia_search_solr module enabled, you’ll see a pre-fab index and server. Go to the search api page in the admin console. If you’re hosting on Acquia you will also need/want acquia_connector and acquia_search_solr. As mentioned above, this is at minimum search_api and search_api_solr. Using composer to add all of the required modules. BLT provides this feature out of the box, if you’re not using BLT you will need to replicate it somehow Local settings (PHP) file that is specific to your local environment(s). The first thing I suggest is getting the basics sorted out. Each environment will still need its own set of credentials and its own url or core config so we can actually authenticate in and connect to the appropriate server for the environment. That’s a terrible idea! I’m saying on the Drupal side we should have a single set of server config. I also want to call out that I’m not suggesting that we have a single Solr server for all of our cloud environments. Worse, you’ll be managing duplicative config while you’re building out and updating your site. But to make these requirements a reality, we have to get a little clever because if we only rely on config split to do per environment config (which is a super legit starting point) you’re going to end up with a lot of duplicative config in your splits. This picture is quite important because we want to keep the absolute bare minimal amount of config possible. Seamlessly switches between environments (so that regardless of where you are, “it just works) Has a single set of views and features reliant on that index Has a single index that works on both servers Has a cloud server (single server config shared across all cloud environments) So… how do we handle this? The Ideal Setupīefore we get into solutioning, let’s talk about the ideal requirements. But, if we have two different servers, does that also mean we now need a different index? Does that mean we need a different view? Remember, your search view requires your index and that requires your server. Meaning, your codebase will have to maintain two different servers. But, we just talked about the fact that cloud solr config is different than local solr config. Your view will require the index config which will require the server config. Let’s make this a bit more complex and imagine that we build out a search view that relies on your search index. whatever your cloud-based solr solution is! Worse, if you have 4+ environments (local, dev, test, prod), you could actually have four different server configs! Keep in mind that your solr config will be different for a local vm vs. Index configuration (which defines your solr index)
Server configuration (which will define your solr server)
#DRUPAL 9 SERVER REQUIREMENTS CODE#
In our scenario here, Search API and Search API Solr will introduce a number of key config files to your code base. Remember, with Drupal config if you’re doing a “fully managed” configuration management strategy (which, a config split strategy is) every last bit of config has to be stored on disk. They get even more complex when those per-environment configs are for an integration! Much of this tutorial applies broadly to non-Acquia Drupal setups (but those pieces are specific to Acquia hosting).Īnytime you start dealing with per-environment configuration, things get a little dicey. Note: the Acquia pieces could certainly be substituted here for another hosting provider. I’ll do this by blending a number of techniques including:įor this tutorial, we’ll be using a number of Drupal modules and plugins including: In particular, we’ll dig into what is necessary to have cloud based Solr servers in the same code base as a locally managed VM Solr container. This article is all about the hurdles you’ll face in setting up Apache Solr for Drupal 9. It’s super easy! But if you want to use “good” search (and by that I mean something like Apache Solr or Elastic Search) that does a better job indexing, processing, and managing your content, you have a bit work to do. I mean, sure if you use the out of the box search that ships with Drupal core, no. In my experience search is one of the most challenging things to configure in Drupal.
0 kommentar(er)
