We were are also getting this on Drupal 10.2.6 for us we had some paths which appeared to be missing the alias value. Not 100% sure why or how these empty alias existed, they were all taxonomy terms.
We were able to delete the paths via the /admin/config/search/path interface and solve the problem.
I had a quick go:
1) Installed a11y_autocomplete_element module (
https://www.drupal.org/project/a11y_auto →
)
2) Replaced ''#type' => 'a11y_autocomplete' anywhere you'd use '#type' => 'select'"
3) Replace dependency 'core/autocomplete' with 'a11y_autocomplete_element/a11y_autocomplete_element'
4) drush cr
For some reason `/core/misc/autocomplete.js` library is still loading, any idea why?
Thanks.
Also just reposting the suggestion from @lukus to replace the autocomplete element with this contrib module:
https://www.drupal.org/project/a11y_autocomplete_element →
Plus also pointing to related issue ( https://www.drupal.org/project/drupal/issues/3076171 📌 Provide a new library to replace jQuery UI autocomplete Needs work ) - long read!!! See comment at top.
I'm keen to see this progressing.
I've been debugging our site and I've noticed with search autocomplete enabled the site includes around 50 JS files and with search autocomplete disabled this reduces down to 20 JS files.
It looks like the module has a dependency on `drupal.autocomplete` which has a further dependencies on `core/internal.jquery_ui` and `core/drupal.ajax`
It would be good to address this to improve performance and SEO.
Thanks.
Thanks I will need to figure out a way of doing this. Perhaps a drush command exists.
The workaround we used for this in the end was simply to untick the box "Enable advanced aggregation" which can be found on the admin page: /admin/config/development/performance/advagg
It was an issue in a project, which we are no longer maintaining. Been a while since this was reported so I would assume the issue was with a previous version of taxonomy_menu (or Drupal) and is now fixed.
Thanks.
Thanks @fabianderijk, tested the development branch and I can confirm the issue has now been resolved. Many thanks for the super quick response and fix.
sittard → created an issue. See original summary → .
Any updates on this? I'm interested in using this module but this issue suggests that it does not work with organisational (Office 365) emails, is that still correct?
So patching info.yml is a special case. Figured it out thanks to: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... →
Please find attached patch for use 'in real life" patching rc2.
I can't seem to get this patch to apply to CKEditor Table Tools Toolbar 2.0.0-rc1. Any chance we could get a release to move this along? Thanks.
We are using the pre-processors in the following order: Ignore Case, Transliteration, HTML Filter, Tokenizer, Ignore Characters, Stemmer and Type Specific Boosting.
We are seeing the following error: An overlong word (more than 50 characters) was encountered while indexing: tsukaketonaruyounacijidenazhuangkuangkafurokuramunishengrirumareteirukotokabiyaotesu.
On investigation we notice this error happening because of the “Transliteration” processor which converts chinese/japanese characters into romanized words causing the long words.
When disabling the transliteration most of the errors disappear apart from a few words that are converted from links. However disabling the transliterator might cause search issues for other languages with special characters (such as polish or spanish) as searching those words without special characters will not work. For example a search string that contains letter “o” will not match special characters in strings such as “ò”.
Please can you advise
By the way I noticed the same error after upgrading from 2.0.0-beta1 to 2.0.0-beta2 rolled back to 2.0.0-beta1 and error has gone away.