I am using Drupal 10.3.10 and PHP 8.1.32. Also, I have "Simple XML Sitemap (Search engines)" and "Simple XML Sitemap (Views)" modules enabled. There are no other custom or contrib modules that extend the Simple XML Sitemap module. I will try to reproduce the error on a clean install and report it here.
mvnovick → created an issue.
Summary
Patch #9 works for Drupal 10.4.4 for a single taxonomy. However, I found a serious problem when multiple taxonomies are involved. Selecting all taxonomy terms individually or selecting the "all" option produce different results when several taxonomy fields pointing to different taxonomies are present in a node.
I tried the following on a clean Drupal 10.4.4 install with patch #9 applied:
Scenario 1
1. Created taxonomy vocabulary "Taxonomy 1" with terms "T1-1" and "T1-2".
2. Created taxonomy vocabulary "Taxonomy 2" with terms "T2-1" and "T2-2".
3. Added fields "Taxonomy 1 Field" and "Taxonomy 2 Field" to the "Basic page" content type referring to "Taxonomy 1" and "Taxonomy 2" vocabularies, respectively.
4. Created and published a "Basic page" node with term "T2-1" assigned to "Taxonomy 2 Field", and left "Taxonomy 1 Field" blank.
5. Added vocabularies "Taxonomy 1" and "Taxonomy 2" to the Tac Lite module.
6. Created a Tac Lite scheme with "view" permissions.
7. Granted permissions to terms "T1-1" and "T1-2" in "Taxonomy 1" for the "Anonymous user" role. The "all" option was not selected.
8. Rebuilt content permissions and cleared caches.
Now the "Basic page" node is not accessible by the Anonymous user. This is correct because this user doesn't have permission to access any terms from "Taxonomy 2", and no terms from "Taxonomy 1" were assigned to "Taxonomy 1 Field".
Scenario 2
The same as above, only in step 7 permission was granted to all terms in "Taxonomy 1" for the "Anonymous user" role by selecting the "all" option.
Now the "Basic page" node is accessible by the Anonymous user. This is incorrect because this user doesn't have any permissions to access terms from "Taxonomy 2" and can only access "Taxonomy 1" terms, but none were assigned to the node.
Conclusion
It looks like Tac Lite grants access to content when the "all" option is selected for a taxonomy field that is blank in the content, while access would be denied based on taxonomy terms present in other taxonomy fields. This can create serious content access violations on sites that use multiple taxonomies to restrict content access. There should be no change in Tac Lite functionality when all taxonomy terms are selected individually or when the "all" option is used.
mvnovick → created an issue.
It looks like the culprit is the Parent Node Path Auto module. When I use a Pathauto pattern that uses the parent page relationship, the Pathauto settings for updating URL aliases are no longer respected. I will report this an an issue for the Parent Node module.
Re-saving the “Search: Fulltext search” filter seems to work. I am not seeing the "Search keys are given but no fulltext fields are defined." error any more.
mvnovick → created an issue.
I enabled the search_api_solr_devel module and examined the debugging information it provided. It looks like Solr removes stopwords from phrase searches. For example, the search for 'one or two' becomes the search for 'one ? two'. Also, grammatical stemming is applied to phrase searches as well. For example, the search for 'admitted students' becomes the search for 'admit student'. The Stopwords and Stemmer processors are not enabled in the Drupal configuration for the Solr index. Is there any way to disable stopwords and stemming in phrase searches? Theoretically, I can delete all stopwords from the Solr Schema, but I would still like to skip stopwords in multi-word searches.
mvnovick → created an issue.
mvnovick → created an issue.
The problem with anonymous user still persists, and patch #11 still works in Drupal 10.3.
I am also having the same issue, but I do not have the Security Review module installed.
I am getting the the problem as described above with Drupal 10.2.2, CKEditor List Style 1.5, and patch #18.
mvnovick → created an issue.
mvnovick → created an issue.
Properly configuring image field display settings solved the problem. Thank you very much, Chi!
mvnovick → created an issue.