🇨🇦Canada @mparker17

I've built what I feel is a good starting point for a guide - Using Elasticsearch Connector 8.0.x →

There's more information to fill in, but I think that can be done by myself and other contributors, or requested in follow-up issues. Note that I didn't want to duplicate documentation elsewhere, so where possible I directed readers to more-comprehensive guides.

I'm going to tentatively mark this as Fixed. I think if you notice any important omissions or serious problems with the guide, then feel free to re-open this ticket, but for everything else, a more-focused follow-up issue would be best.

Thanks for your understanding and patience!

(forgot to change the status before clicking Save on that last comment)

Checking on the status of these features in 2025...

1. search_api_grouping - this will be done in ✨ Elasticsearch Connector -> Search Api Integration -> Implement search_api_grouping Postponed
2. search_api_multi -
   1. This feature was only supported in search_api-7.x-1.x, and no longer exists in search_api-8.x-1.x
   2. Neither search_api nor elasticsearch_connector have any supported Drupal 7 versions.
   3. As of 2025-08-30, there are ~251 sites still using a elasticsearch_connector-7.x version
   4. Is there still interest in adding support for this to an elasticsearch_connector-7.x version?
3. search_api_service_extra -
   1. This feature was only supported in search_api-7.x-1.x, and no longer exists in search_api-8.x-1.x
   2. Neither search_api nor elasticsearch_connector have any supported Drupal 7 versions.
   3. As of 2025-08-30, there are ~251 sites still using a elasticsearch_connector-7.x version
   4. Is there still interest in adding support for this to an elasticsearch_connector-7.x version?
4. search_api_data_type_location - this was added to elasticsearch_connector-7.x-1.x in #2192609: Elasticsearch Connector -> Search Api Integration -> Geo functionality → , elasticsearch_connector-8.x-5.x in #2865662: Add support for geofield mapping → , elasticsearch_connector-8.x-7.x in #3061167: ES 7.x support! → , and still works in the elasticsearch_connector-8.0.x version →
5. search_api_data_type_geohash -
   1. This appears to come from the Drupal 7 versions of the Geocluster module → (it was never present in the Drupal 8 version), which no longer has any supported releases (and as of 2025-08-30, only 49 sites still use this module → )
   2. Is there still interest in adding support for this to an elasticsearch_connector-7.x version?

Looking at the comments...

The request for Excerpt support from #2 and clarified in #5 was done in ✨ Highlighting support (leverage Elasticsearch highlighting) Needs review

The request for Suggesters support in #7 and #11 was done in ✨ Support for Search API Spellcheck Active

The request for custom analyzer support in #7 will be done in ✨ Define custom analyzers for an index Active

Given that all the functionality requests that I can see in this ticket either...

1. has its own tracking tickets ( ✨ Elasticsearch Connector -> Search Api Integration -> Implement search_api_grouping Postponed , ✨ Define custom analyzers for an index Active ),
2. is done ( #2192609: Elasticsearch Connector -> Search Api Integration -> Geo functionality → et. al., ✨ Highlighting support (leverage Elasticsearch highlighting) Needs review , ✨ Support for Search API Spellcheck Active ), or,
3. is only relevant for unsupported versions of Drupal core, or modules (search_api_multi, search_api_service_extra, search_api_data_type_geohash) and the maintainers need clarification on whether people still want it

... I'm going to mark this ticket as Postponed (maintainer needs more info) until we hear back!

mparker17 → created an issue.

Tagging with Needs issue summary update so I remember to update it following the template for future documentation purposes.

I've applied the patch from #13

Merged! Thanks everyone!

mparker17 → changed the visibility of the branch 8.0.x to hidden.

Manual testing worked for me! I think this is ready to merge.

Okay! @kdborg and myself fixed the FilterBuilderTest to account for the new code; and found that the overrides we had been making in ElasticSearchBackendTest were no longer necessary because range filters are now working properly, yay!

We're going to do some manual testing now.

Merged! Thank you very much everyone!

I've added a test now, so I think I'm going to promote this to RTBC.

Testbot likes it except for a PHPStan lint, and my manual testing shows it is working, so this works for me: let's fix the PHPStan lint and see if we can add a test.

(additional context: @kdborg and i are pair-programming on this issue in real time)

Merged! Thanks @Kirk Brown, for the help on Slack.

It seems to be working on my machine, and Testbot likes it too, so I'm going to move it to RTBC.

Okay, let's try this and see what testbot thinks of it.

mparker17 → created an issue.

@phenaproxima are you still working on this?

I've got something working and tested in 🐛 Migrate sitemap.settings.rss_front to SitemapSyndicateBlock's configuration; test, deprecate SitemapSyndicateBlock Active — which will likely conflict with some of your changes here, although with relatively trivial resolutions...

1. both branches create sitemap.post_update.php but create two different hooks with different names - both functions should exist in the final version
2. both branches modify the defaultConfiguration() function in src/Plugin/Block/SitemapSyndicateBlock.php. - this branch should continue deleting the cache key and friends; the other branch should continue creating the rss_feed_path key.

I'm happy to merge this one first and then fix the merge conflicts in the other branch if that's easiest for you, so I'm going to hold off on merging 3545858 until I hear back from you!.

Thanks!

Okay, this seems to be working now, and testbot is happy. Note that it will conflict with 🐛 The Sitemap blocks' settings have no config schema Needs work .

The elasticsearch_connector_statistics sub-module patched here only appears to be in the 7.x-1.x and 7.x-2.x versions of the module: it was never ported to Drupal 8.

For Drupal 8+, it appears that the Search API Stats module → is capable of logging what people are searching for.

As of August 31, 2025, only ~251 sites are using the 7.x- versions of this module → . Is there still interest in fixing this for the 7.x versions? Does the search_api_stats module meet your needs for newer versions of Drupal?

Turns out we deleted rss_front from the global settings in \sitemap_update_8200(), which explains why my test wasn't working.

Updating the issue summary to reflect the new scope.

Made some progress but still have to write the update hook to migrate from the old config.

Assigning to myself.

Elasticsearch Connector has used Search API's UI for index field selection 7.x-1.x, and I can't find any similar requests in the Search API issue queue (although I'm less familiar with it so I may have missed something). I'm going to move this into the Search API issue queue.

Updating the issue summary with a better description.

Updating the issue title to reflect the new scope.

Thanks for your hard work, @phenaproxima!

Updating the issue summary.

Merged! Thanks everyone!

I'll look into making a release with these changes in the next few weeks!

I should also mark this issue as Fixed!

Merged! Thanks everyone!

I'll look into making a new release with these changes in the next few weeks!

Thanks @tom konda!

This looks good to me! Manual testing shows this working well.

I couldn't get the active-trail class to display, even when I put the sitemap in a menu being output onto the sitemap - but the code to detect the active-trail existed before this patch (I think it's likely that I've set up my test site wrong) - I don't see any reason to hold back this change.

Awesome, Testbot is happy, so I think this is ready to commit!

Updating the issue summary as promised.

Awesome, this looks great! Thank you @tom konda and @pcambra!

I'm going to make a very slight change to the test, but overall I think this is ready to merge!

I'm going to update the issue summary shortly so it's a little easier for people who find a link to this issue in the release notes to know what changed at-a-glance.

Hello @kul.pratap,

Thank you for your contribution. I reviewed your code.

First things first, please add a test to check the new functionality.

Also, in my code review, I found that one of the changes you made will cause some problems: please restore the '#input' => FALSE, line that you deleted! I also found a nitpick and made two suggestions.

Quick question: did you use AI to help with this contribution? If you did, you must disclose that, as per the Issue queue guidelines → .

I just received a contribution in ✨ Display table of items found by a scanner Active by @kul.pratap → whose user profile says they are from Innoraft (AFAICT, the new commit-credit system doesn't show who you're working for when you write a comment).

I suspect that it might be commit farming because they picked a brand new module with no active users, and no documentation and patched a version of the module with only a dev release, I had written the issue as a reminder to myself a few hours earlier, and they included an "after" screenshot as proof-of-work.

I suspect that @kul.pratap may not be familiar with issue queue etiquette because they unnecessarily double-uploaded the "after" screenshot.

I suspect that the work may have been AI generated because they unnecessarily renamed a form element and didn't explain why, picked an unnaturally-verbose choice for a table header, they removed the '#input' => FALSE, on a control that doesn't warrant that, and there are no tests even though the Submission guidelines for the module suggest it.

Update the issue summary with slightly clearer wording.

Adding tags to reflect what needs to be done.

In particular, I should update the issue summary so we know what is/is-not in scope. But I'm going to do that tomorrow.

mparker17 → created an issue.

Looking at the history of the cache and max_age configuration...

Looks like it came from the site_map-8.x-1.x-dev project, i.e. added to sitemap in commit 65d9a44 from 2015-11-08.

Switching over to the site_map repo, it looks like cache and max_age were introduced in #2366683: Update site_map to work with 8.0.x branch → . As far as I can tell, that issue sought to reconcile the code already in the 8.x-1.x branch with the code in the 7.x-1.x branch. At this point, the 7.x-1.x branch had a $blocks['syndicate']['cache'] = DRUPAL_NO_CACHE line in hook_block_info() from #1098918: Fix block caching & theming → ; while the Syndicate block's plugin class in the 8.x-1.x branch had a 'cache' => DRUPAL_NO_CACHE default configuration (from the initial D8 port in #2139181: Drupal 8 version → ) but it was never used anywhere. I guess making it configurable was better than making it never-cacheable but it seems that the setting may have been a relic that never properly took advantage of D8+'s [dynamic_]page_cache features.

Regardless, it looks like the cache and max_age configuration never did anything in D8 at any point, so I think we can safely delete it without breaking backwards compatibility.

Looking at the history of the rss_front configuration...

The rss_front configuration item used to control two things: the href for this RSS icon on the Syndicate (sitemap) block, and feed URL on what would become the frontpage plugin (i.e.: \Drupal\sitemap\Plugin\Sitemap\Frontpage).

A separate setting for the frontpage plugin was established in commit 52ab0d4 from 2017-03-22.

The rss_front control on the settings page was removed shortly thereafter in commit commit b35b30f from 2017-03-22.

@phenaproxima are you working on a patch, or would you like me to try? (just want to avoid duplicating our efforts)

Thank you! I had no idea this configuration even existed! 😅

Looking at \Drupal\sitemap\Plugin\Block\SitemapSyndicateBlock, I see several bugs...

1. The cache and max_age config don't actually appear to be used anywhere (but maybe I missed something)
2. I see a call to $this->configFactory->get('sitemap.settings')->get('rss_front'); but no mention of that key in config/schema/sitemap.schema.yml

... but I daresay these belong in follow-up issues because using-previously-unused config and/or adding a settings form for config and/or figuring out what rss_front is supposed to be sound like larger discussions. Thoughts, @phenaproxima?

mparker17 → changed the visibility of the branch 8.x-7.x to hidden.

For what it's worth, we seem to be down to 1 failing test in this branch...

1) Drupal\elasticsearch_connector\Tests\Kernel\ElasticsearchTest::testBackend
Search for »test« returned correct number of results.
Failed asserting that 0 matches expected 4.
/builds/project/elasticsearch_connector/web/modules/contrib/search_api/tests/src/Kernel/BackendTestBase.php:256
/builds/project/elasticsearch_connector/web/modules/contrib/search_api/tests/src/Kernel/BackendTestBase.php:98

Note that I rebased the merge request onto the latest 8.x-7.x just now.

Awesome, thanks @vitaliyb98!

I had apparently pushed to the wrong issue fork in #2... I've now created a merge request in the correct issue fork: I apologize for the confusion.

I had been hesitating on this patch because it requires additional permissions...

1. additional cluster-level permission: monitor
2. additional index-level permissions: maintenance, monitor

That being said, when I was writing the guide on setting up an API key with a role descriptor → , I included these permissions, so it's probably okay for now.

Probably a better solution would be to test whether or not we have these permissions before trying to access data that requires it (i.e.: because we could selectively display information based on what the API key we're connecting with has permission to view). Ideally, Elasticsearch has a has-privileges API and a get application privileges API we could use to query this; another option could be to try getting the data and catching 403 errors, but the Elasticsearch Connector module doesn't yet have infrastructure to support either of those approaches.

It is still possible to create a custom analyzer for an index in the latest versions of Elasticsearch, and I think this would be a desirable feature for the 8.0.x version too. So I'm moving this into the 8.0.x queue.

Note that the nGram and edgeNGram token filter names and similar tokenizer names were deprecated in versions 6.4 and 7.6 respectively; and were removed in Elasticsearch 8.0 — the new names are ngram and edge_ngram in both cases.

It seems this bug exists in the 7.x-1.x, 7.x-2.x, and 7.x-5.x branches, but all of those are unsupported, and Drupal 7 is end-of-life now → .

That being said, as of August 31, 2025, only ~251 sites are using the 7.x- versions of this module → .

Is there still interest in fixing this?

How I determined which versions the bug exists on...

$ git remote -vv
origin	git@git.drupal.org:project/elasticsearch_connector.git (fetch)
origin	git@git.drupal.org:project/elasticsearch_connector.git (push)
$ git fetch --all -t -pP
$ git branch -r
  origin/7.x-1.x
  origin/7.x-2.x
  origin/7.x-5.x
  origin/8.0.x
  origin/8.x-1.x
  origin/8.x-2.x
  origin/8.x-5.x
  origin/8.x-6.x
  origin/8.x-7.x
  origin/HEAD -> origin/8.0.x

$ git switch 7.x-1.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '7.x-1.x'
Your branch is up to date with 'origin/7.x-1.x'.

./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:function elasticsearch_connector_statistics_tokens($type, $tokens, array $data = array(), array $options = array()) {
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:      $statistics = elasticsearch_connector_statistics_get($node->nid);

$ git switch 7.x-2.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '7.x-2.x'
Your branch is up to date with 'origin/7.x-2.x'.

./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:function elasticsearch_connector_statistics_tokens($type, $tokens, array $data = array(), array $options = array()) {
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:      $statistics = elasticsearch_connector_statistics_get($node->nid);

$ git switch 7.x-5.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '7.x-5.x'
Your branch is up to date with 'origin/7.x-5.x'.

./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:function elasticsearch_connector_statistics_tokens($type, $tokens, array $data = array(), array $options = array()) {
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:        $statistics = elasticsearch_connector_statistics_get($node->nid);
./modules/elasticsearch_connector_statistics/elasticsearch_connector_statistics.tokens.inc:      $statistics = elasticsearch_connector_statistics_get($node->nid);

$ git switch 8.x-1.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.x-1.x'
Your branch is up to date with 'origin/8.x-1.x'.

$ git switch 8.x-2.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.x-2.x'
Your branch is up to date with 'origin/8.x-2.x'.

$ git switch 8.x-5.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.x-5.x'
Your branch is up to date with 'origin/8.x-5.x'.

$ git switch 8.x-6.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.x-6.x'
Your branch is up to date with 'origin/8.x-6.x'.

$ git switch 8.x-7.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.x-7.x'
Your branch is up to date with 'origin/8.x-7.x'.

$ git switch 8.0.x ; grep -r 'elasticsearch_connector_statistics_tokens' . ; grep -r -w 'elasticsearch_connector_statistics_get' .
Switched to branch '8.0.x'
Your branch is up to date with 'origin/8.0.x'.

If the bug had been fixed then I would have seen a line with function elasticsearch_connector_statistics_get() {

The bug isn't present on any branches that don't return any results for either of the grep lines.

Agreed! Adding tests ultimately benefits you, because they ensure that the functionality that you (and your clients) depend on won't regress. Tagging with "Needs tests"

mparker17 → created an issue.

mparker17 → created an issue.

Merged!

Works for testbot; that's good enough for me.

Added a merge request.

mparker17 → created an issue.

@timurtripp, thanks for the clarification!

(because automated tests only run on merge requests, I prefer to review merge requests)

I notice that there is a failing test...

1) Drupal\Tests\sitemap\Functional\SitemapTaxonomyTest::testVocabularyDescription
Behat\Mink\Exception\ResponseTextException: The text "rwxrdqg6" was not found anywhere in the text of the current page.
/builds/issue/sitemap-3544638/vendor/behat/mink/src/WebAssert.php:907
/builds/issue/sitemap-3544638/vendor/behat/mink/src/WebAssert.php:293
/builds/issue/sitemap-3544638/web/core/tests/Drupal/Tests/WebAssert.php:981
/builds/issue/sitemap-3544638/tests/src/Functional/SitemapTaxonomyTest.php:265
FAILURES!

Looking at the test (tests/src/Functional/SitemapTaxonomyTest.php line 265), the test has just tried to save the Sitemap settings form and is now looking for the taxonomy description on the page, but it can't find it.

From experience, this can sometimes be caused by an error when saving the settings form (that is to say, the test is seeing either a PHP error or the settings form, but was expecting to see the sitemap). This seems relevant because I see the merge request adds some things to the settings form.

For what it's worth, I wrote some documentation on debugging functional tests in the sitemap module → , which should help.

I seem to recall that automated tests (now) strictly check the configuration schema (which is defined in → config/schema/sitemap.schema.yml): because the merge request adds settings but don't change the schema (sitemap.schema.yml), that might explain why trying to save the sitemap settings causes a failure: the configuration-with-no-schema only gets added when the page is saved, i.e.: and the default form values get saved.

On that note, the new functionality will need some automated tests, i.e.: to ensure that other contributors' changes to this module in the future don't break the functionality that your site/client depends on.

@timurtripp, thanks for the contribution!

Which is more up-to-date: the merge request or the patch?

@bserem, it looks like the Search API Stats module → and/or the Search API Tracking modules → do something similar to what you're asking for.

May I trouble you to try out these modules to see if they meet your needs, and post back here with the results?

Something is wrong with the patch: I cannot apply it.

$ git apply --index ~/Downloads/3456789-2-elasticsearch-connector-single-value-fields.patch 
error: corrupt patch at line 57

$ patch -p1 < ~/Downloads/3456789-2-elasticsearch-connector-single-value-fields.patch 
patching file 'src/ElasticSearch/Parameters/Factory/IndexFactory.php'
patch: **** malformed patch at line 56:        $params['body'][] = ['index' => ['_id' => $id]];

Moving to Needs work.

mparker17 → changed the visibility of the branch 3545049-single-value-fields-indexed-as-arrays to hidden.

Ah, this is a patch against the 8.x-7.x branch of the module, so I'm going to move it into that queue.

Updating issue title

Updated slightly to reflect new additions to the guide.

Lots of links to relevant Elasticsearch documentation and mention the roles needed to create API keys.

Moving to Needs Work. This page could use a walkthrough that is more step-by-step; or link to documentation on the Elastic website with a walkthrough.

Add configure optional modules section as a related page; removed the developing links.

Moving to Needs Work. This page could use a walkthrough that is more step-by-step; or link to documentation on the Elastic website with a walkthrough.

Moving to Needs Work. This page could use a walkthrough that is more step-by-step; or link to documentation on the Elastic website with a walkthrough.

Move to Needs Work. This page could have more information contrasting Elasticsearch with other solutions, like OpenSearch, Solr, Search API Database, etc.

I've built what I feel is a good starting point for a guide - Using Elasticsearch Connector 8.0.x →

There's more information to fill in, but I think that can be done by myself and other contributors, or requested in follow-up issues. Note that I didn't want to duplicate documentation elsewhere, so where possible I directed readers to more-comprehensive guides.

I'm going to tentatively mark this as Fixed. I think if you notice any important omissions or serious problems with the guide, then feel free to re-open this ticket, but for everything else, a more-focused follow-up issue would be best.

Thanks for your understanding and patience!

Link to configure optional modules.

Link to modules without documentation. Start a Next steps section.

Add Search API Decoupled link

Title change; fill in more info about views, drush output formats.

Link to next step in guide

Add drush docs, document how to manually rebuild tracking information.

Link to the correct next page in guide.

Filled in the rest of the page.

Link to next page in guide.

Link to next page in guide.

Turn sentence into a tip.

Turn a sentence into a tip.

Turn a sentence into a tip.

Filled in the rough notes.

Fill in the rough notes previously on the page.

Removed empty h2

Filled out the previous rough notes into a full documentation page.

Fill in documentation around the rough notes.

Link to next sections in the guide.

Link to next sections in the guide.

Link to next sections in the guide.

Link to next sections in the guide.

Link to next sections in guide.

To follow-up on my last comment, I have now written some documentation on how to set up Sitemap module for local development: https://www.drupal.org/docs/contributed-modules/sitemap/developing-sitem... →

Hi everyone, thank you for your contributions!

The type property is automatically set to drupal-module in Drupal.org's packaging script, so I removed it from the composer.json committed to git in ✨ Simplify composer.json Active ... the packaging script runs when I make a release, and the fully-filled-in composer.json makes onto composer.drupal.org and into the zip and tar.gz files.

If you're finding that composer is cloning the module in your project instead of downloading a packaged stable version, then your project's minimum-stability might be set wrong; or you might have a stability override for Sitemap module - removing the stability override might help. I also recommend double-checking that prefer-stable is set to true.

If you need to clone the Sitemap module because you want to develop the module (i.e.: contribute patches or merge requests), then I recommend using ddev's ddev-drupal-contrib add-on. Using ddev-drupal-contrib will get around asking Composer to clone the Sitemap module (i.e.: so composer won't complain about the missing type properly). I apologize for not updating the sitemap module's documentation with instructions as I have done for elasticsearch_connector →

Link to next page in guide.

Add link to next page in guide.

Link to next pages in guide.