Test the default install https://github.com/wfcouncil/localgov_solr_search

[finnlewis]

The LocalGov Drupal Solr Search working group have met to discuss bringing in the work from https://github.com/wfcouncil/localgov_solr_search

The first thing we want to do is test installing the module out of the box, to see what we have.

Guessing that @andybroomfield and @ekes would be good people to start this.

[ekes]

There's a branch of localgov_project with the lando and solr config and composer installed to pull this for anyone that wants to test: https://github.com/localgovdrupal/localgov_project/tree/feature/2.x/24-wf-solr-search

[andybroomfield]

Have managed to get this module working on localgov drupal default install with demo content. Note: Config changes have to be deployed to get this to work, and before attempting to index otherwise whilst the indexing will appear successfull, the search page will return bad request errors.

Once deployed, the solr indexing works and basic search at /site-search will return results with auto complete. Since search results template insn't set yet (except for news content types) the results seem to be the full display.

This does raise the issue of how search results should be themed, and if news search view should use a different display mode for its search results than the main site search, which I guess would be common to the main search module.

I'm also getting a missing template error for some searches.

Twig\Error\LoaderError: Template "modules/contrib/localgov_search/templates/field--body--localgov-site-search-result.html.twig" is not defined. in Twig\Loader\ChainLoader->getCacheKey() (line 105 of themes/contrib/localgov_base/templates/content/node.html.twig). for the search 'parking'

I've managed to get this working with Solr 7, not finding any solr conflicts yet once solr 7 config sets are exported. I think we are going to have to ship with some configsets anyway as I did encouter stemming issues (parking picking up parks) when previously using solr search.

[andybroomfield]

Disabling localgov_search allows the parking search to run. As expected, a search for parking turned up parks.

Adding parking to protwords_en.txt resolves this.

[ekes]

Breaking this down into the components we can use, integrate, and how. Next steps would look like:-

Results formatting and templating

Agree if we want to move the templating, display configuration into localgov drupal. If so it needs to go into the modules that supply the content types - they already have search results and search index display modes - can be a discussion about where templates live (module or theme).

Server and index default config

If we can reuse the index switching the server backend this will be helpful. It's probably essential for directories, news and later events. Switching indexes means duplicating views. This could be an option for search, but there would have to be a good case for doing so, it's probably really not an option for the others, though if someone has an idea how it'd work (and be maintainable) we could review.

Search, Directories, News ... modules all have a default db server config to roll out of the box working. It would be good to move these into separate modules. Then add the _solr equivalent. There is the configuration for the Search version in this module.

Best practices / Helpful starter config

The stemming is certainly a good example of this. We should make our own version of the https://git.drupalcode.org/project/search_api_solr/-/tree/4.x/jump-start/drupal_configs with customisations like the park/ing. These can be added to over time as ideas come up. Some of these can also go into the default configuration for localgov_search_db (or whatever we call it). IIRC you can also override the stemmer there.

The "jump start" configuration we make should also be the one that comes with lando when it installs the servers.

Supplementary features

Some of the features here, and in the future, can be added to the main modules configuration as they are backend server agnostic. Others will only work with one (usually solr), these could be added to the _db _solr modules, the added complexity would be if/when they require changes to the view/index to operate (and don't inject themselves). We will have to do this if they aren't common to both backends. Directories itself has examples of dynamically updating the view based on other configuration.

Looking what we have here...

Search API autocomplete

Works with db and solr. So if it wants to go in, it can go directly into the search module configuration.

Search API spellcheck

Only declares a dependency on search_api. Although my assumption would be it requires solr, this needs checking. If it's both we've not got anything complicated here?

[ekes]

See issues #27 #28 #29 #31 #32 #33 #34 #39 for follow-up; also localgovdrupal/localgov_search_solr