Term reference autocomplete widget having problems handling terms containing forward slashes. [#1000748]

Environment

Drupal 7, rc2. Php 5.2.6 on Debian Lenny.

To reproduce

Add a few terms containing forward slashes to an existing vocabulary. For example, "AC/DC", "Sweet/Sour", "Yin/Yang".
Add a Term reference field to a content type and have it use an autocomplete term widget. Have the widget reference the vocabulary used above, and have it allow an unlimited number of values.
Try adding some content and typing text contained in one of the terms entered above into the widget field, e.g. 'yi'. You should be able to add the first term. Try adding a second term, e.g. 'swe'. Nothing happens.

Expected behavior

What should happen is that you get quoted terms which contain the text you type.

Proposed fix

One part of the problem comes from using clean urls. When a term with a slash gets passed as a url argumnt to the autocomplete endpoint, the slash aren't properly decoded by the default url rewrite system. I'm not sure how to solve this problem other than by disabling clean urls.

However there is a problem even When clean urls are disabled. Terms with slashes are interpreted as additional arguments by the drupal menu system. For example, Yin/Yang is seen as two separate arguments 'Yin' and 'Yang'.

I've got a hackety solution to this in the taxonomy_autocomplete function of taxonomy.pages.inc. I'm hoping there's a better fix.

The hack involves looking for extra arguments, and appending them to expected arguments. Here it is:


...

function taxonomy_autocomplete($field_name, $tags_typed = '') {

  // Yuck!  Super kludgy! >:p
  // If there were extra arguments due to terms containing slashes, 
  // then append them to $tags_typed
  if (func_num_args() > 2 ) {
     $all_args = func_get_args();
     $tags_typed .= '/' . implode('/', array_slice($all_args,2));
  }
  // Continue on...

  ...

I'm hoping there is a cleaner fix.

Note: you may also need to fix the use of multiple quoted terms as per this issue: http://drupal.org/node/1000736

Comment	File	Size	Author
#5	1000748-axyjo.patch	4.17 KB	axyjo

Comments

Comment #1

joachim commented 17 December 2010 at 08:17

Status:

Active

» Postponed (maintainer needs more info)

Works for me on OS X with MAMP.

Can you give more details about your server setup?

Comment #2

joachim commented 17 December 2010 at 08:24

Priority:	Normal	» Major
Status:	Postponed (maintainer needs more info)	» Active

Actually, no, confirming.

If I create a tag 'foo/bar' and then enter 'foo/' into the autocomplete, I get a big 404 Javascript alert.

This is a regression from 6.x.

Comment #3

joachim commented 17 December 2010 at 08:55

The problem is in the Javascript that constructs a URL to fetch autocomplete from.

The actual autocomplete path works, as this terminal output with curl demonstrates:

~ joachim$ curl http://localhost:8888/7-drupal/taxonomy/autocomplete/field_tags/f
{"foo\/bar":"foo\/bar"}
~ joachim$ curl http://localhost:8888/7-drupal/taxonomy/autocomplete/field_tags/foo
{"foo\/bar":"foo\/bar"}
~ joachim$ curl http://localhost:8888/7-drupal/taxonomy/autocomplete/field_tags/foo/
{"foo\/bar":"foo\/bar"}
~ joachim$ curl http://localhost:8888/7-drupal/taxonomy/autocomplete/field_tags/foo/b
{"foo\/bar":"foo\/bar"}
~ joachim$

The correct tag 'foo/bar' is being returned from the URL in all cases, even when I include the slash.

Comment #4

axyjo commented 23 December 2010 at 11:18

Version:

7.0-rc2

» 7.x-dev

From IRC:

I just found something interesting: using the Chrome debugging tools, I found out that for slashes, the javascript seems to convert slashes to "%2F" in the URL. curl-ing the page "http://localhost:8888/drupal/taxonomy/autocomplete/field_tag/AC%2F" returns a 404 while the page "http://localhost:8888/drupal/taxonomy/autocomplete/field_tag/AC/" returns a valid response.

Oh, and I reproduced this in HEAD.

Helpful?

EDIT: "seems to convert it" -> "seems to convert slashes"

Comment #5

axyjo commented 23 December 2010 at 11:49

Status:

Active

» Needs work

Status	File	Size
new	1000748-axyjo.patch	4.17 KB

Okay, this is a TOTAL hack. It's probably not good for production use, but it fixes the issue. Also, the test added has just been added to test with slashes, but since it's a Javascript bug, I'm not sure whether it's appropriate.

Comment #6

joachim commented 23 December 2010 at 14:08

Nice job writing a test too!

It does look like a hack though... :/ I wonder whether it's possible to have the PHP side unencode the %2F back to a slash, and whether that would be better.

Comment #7

axyjo commented 23 December 2010 at 13:33

The test is just copied and pasted from the one above it :) just changed the term names. The thing with the PHP side is that the taxonomy_autocomplete() function doesn't seem to get called once the % sign in thrown in to the URL. I assume this affects more than just taxonomy_autocomplete() and something really bad in the menu router causes Drupal to choke.

Comment #8

axyjo commented 23 December 2010 at 14:02

No, I lied. %20 (spaces) work fine.
EDIT: Okay, something really strange is happening. I `git stash`ed the patch, cleared my cache and tried again, and autocomplete queries like "AC/" and "AC/D" were fine.