Form API #autocomplete_path JS and callbacks to use GET q= parameter instead of menu tail

Actually... wouldn't they need to be modified to specify a controller, not a path, and then Drupal takes care of forming the appropriate URL?

Fixing title.

KISS?

Didn't update all autocomplete-related tests yet, as I wasn't sure whether this simple solution will be accepted.

Works for me. Here's test fixes and a couple minor code fixes.

+++ b/core/modules/taxonomy/taxonomy.pages.inc
@@ -102,21 +102,14 @@ function taxonomy_term_feed(Term $term) {
-function taxonomy_autocomplete($field_name, $tags_typed = '') {
-  // If the request has a '/' in the search text, then the menu system will have
-  // split it into multiple arguments, recover the intended $tags_typed.
-  $args = func_get_args();
-  // Shift off the $field_name argument.
-  array_shift($args);
-  $tags_typed = implode('/', $args);
+function taxonomy_autocomplete($field_name) {
+  // A comma-separated list of term names entered in the autocomplete form
+  // element. Only the last term is used for autocompletion.
+  $tags_typed = drupal_container()->get('request')->query->get('q');

IMO, the DX change above is a wash, but...

+++ b/core/modules/user/user.pages.inc
@@ -14,9 +14,9 @@
-function user_autocomplete($string = '') {
+function user_autocomplete() {
   $matches = array();
-  if ($string) {
+  if ($string = drupal_container()->get('request')->query->get('q')) {

The DX of this got much worse, and will be annoying for every contrib module that implements an autocomplete callback. However, I think we'll be able to improve it as we move controllers to the new route system, because the controller will be able to receive $request (or maybe even $query or $q) as a direct parameter. So please, let's not hold this up on that.

Thanks!

The Views page callback argument handling looks strange, but those two Views callbacks for users and taxonomy terms shouldn't exist in the first place... ;)

Also, we might want to consider to introduce two base Autocomplete controllers in the future; one for single term autocompletion, and the much more interesting, one for autocompleting a term in a text field supporting multiple tags — it looks like we're duplicating quite some complex code there. Lastly, we have an issue somewhere for introducing a generic entity autocomplete route/callback/handler (but I'm unable to find it right now).

Anyway, for now this simple change seems to be required and a long-overdue clean-up and simplification, so I'd think this is ready to go?

Turns out that ?q= is absolutely great and would make our autocomplete callbacks automatically compatible with #1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter) :)

Actually, I'm not sure what we're waiting for. The patch looks great.

#6: drupal8.autocomplete-query.6.patch queued for re-testing.

This looks good to me, too. Any further Symfony-ification can and should happen in follow-up issues.

Committed to 8.x. Thanks.

Does this need a change notice? I would think yes, but I'm not sure. In writing one for #1817656: Let user_autocomplete also find the anonymous user. I wanted to reference this, but there isn't one.

I wrote some code related to this at the top of http://drupal.org/node/1896862 that could probably be stolen for this (and then removed from there).

Created http://drupal.org/node/1901518 and updated the change noticed mentioned in #19.

That change notice looks good. Seems to actually be more straightforward for module devs.