diacritics are not removed from ǢǣǼǽǮǯ

This change makes a ton of sense. It even has a test.

As a note, at least on my system, when I looked at the patch file in the browser, the characters were weird. But when I applied the patch and looked at the files in my terminal or text editor, the characters were readable and the patch looks correct to me.

+++ b/core/lib/Drupal/Component/Transliteration/PhpTransliteration.php
@@ -23,6 +23,21 @@
+  const DIACRITICS_MAP = [

This map is now added to the global namespace but it is (necessarily) a very incomplete map. It'd be nice to add protected in front of it but then it's going to be Drupal 9 only because scoped constants were only introduced in PHP 7.1. Maybe we can consider a name that doesn't imply a complete map or somehow describes what it maps.

Another question I have is will this list grow? Because if if does then we might want to consider placing it somewhere else because then we don't have to instantiate it when we load this class.

How about making the list a protected property - that's supported and then it does not bleed into the public API.

It looks to me as though the concerns of alexpott have been addressed. I still like the patch. The tests still pass. No coder errors. And this is a sensible fix to removeDiacritics(), with a very small impact (removes diacritics from a total of 4 characters that were incorrectly being passed up in the previous code). Back to RTBC.

One more thing to consider. Re-indexing. I think this change makes a re-index necessary because it changes search input and the text that is indexed... yes there probably aren't too many ǢǣǼǽǮǯ characters in people's text (this statement might very well be a statement of my ignorance) but this change will breaking searching for them on an already indexed site.

+++ b/core/modules/search/search.install
@@ -154,3 +154,13 @@ function search_requirements($phase) {
+/**
+ * Mark everything for reindexing after diacritics removal rule change.
+ */
+function search_update_9000() {

Let's do this in a post update - this is not a schema change and it also doesn't force our hand wrt to D8 and D9 update numbers for the search module.

Patch is working for 9.1.x

@jpatel657 the patch in #16 applied to 9.1.x already. You could have used the add test button to kick off an 9.1.x test against that branch. Since #19 is exactly the same as #16 I'm removing issue credit.

Also since this is a bug that occurs in 8.9.x that's the correct branch for this patch. It's great that the same patch applies to 9.1.x so we can applied the same patch to all branches.

Apparently, post update functions go into the module_name.post_update.php file. Other than that, looks OK to me.

@jhodgdon is correct - that's exactly where they go. Nice catch.

Back to RTBC as all the outstanding feedback is addressed.

This looks good to me, but there's a conflict in search.post_update.php now.

Here's a patch for 9.1.x, and #27 still applies to 8.9.x.

As a note, at least on my system, when I looked at the patch file in the browser, the characters were weird. But when I applied the patch and looked at the files in my terminal or text editor, the characters were readable and the patch looks correct to me.

@jhodgdon #2922638: No charset on response for patch & text files

Committed/pushed to 9.1.x and backported to 8.9.x, thanks!