jlstrecker → created an issue.
The latest patch (#44) partly breaks result counts for facets that use the AND operator.
Basic steps to reproduce:
- Set up a search page with a full-text search and one facet (list of links, AND operator).
- Click on one of the facet links.
- Without the patch, the counts on the facet links are updated to reflect that the result set has been narrowed.
- With the patch, the counts on the facet links fail to update.
Tested on a fresh Drupal 10 installation with:
- Elasticsearch Connector 8.x-7.0-alpha4 + patch #44
- Umami installation profile
- Search index of Article content with fields for Title (fulltext) and Tags
- View showing indexed Title field with exposed filter for fulltext search
- Facet for Tags field — List of links, Show the amount of results, Operator=AND
I ran into what may be the same bug. It started happening when I applied a similar patch to one listed above (#3052574: https://git.drupalcode.org/project/facets/-/merge_requests/113.diff).
I have a View with Ajax enabled that initially shows no results. As expected, facets are hidden at that point. Once I enter search text into the exposed filter and the View shows some results, the facets should appear. That was the case before I applied the patch. But now, the facets remain hidden (they appear in the HTML but have class "hidden").
I was able to work around the problem by changing each facet's "Empty facet behavior" from "Do not display facet" to "Display text" and leaving the "Empty text" field empty.
That module does support Elasticsearch, even if it's not obvious from the issue queue. We moved a site over from Search API Elasticsearch Attachments to Search API Attachments without any trouble.
When we were previously using search_api_elasticsearch_attachments, Drupal would send attachments to Elasticsearch and use an Elasticsearch pipeline to invoke Tika to extract text.
Now, with search_api_attachments, Drupal sends attachments to Tika then sends the resulting text to the search index as a field.
I don't think this module is maintained anymore. I would recommend switching to Search API Attachments → , which covers the same functionality as this module (indexing files for Elasticsearch) and is currently maintained.
If Stamen map tiles moving to Stadia hosting and will no longer be available at old URL 📌 Stamen map tiles moving to Stadia hosting and will no longer be available at old URL Needs review gets merged in as it is now, then this issue would be a duplicate. That merge request also adds Toner back in.
Thanks! I looked over the code and tested with the Stamen Toner style. The tiles successfully load on both a local dev site and an AWS-hosted site. I confirmed that it's no longer requesting tiles from stamen-tiles-*.ssl.fastly.net, now only tiles.stadiamaps.com. On the public site, once I deployed the change, rebuilt caches, and registered for domain-based authentication with Stadia, the "basemap tiles will no longer be available" message no longer appeared. (On the dev site the message never appeared.)
jlstrecker → created an issue.