Unable to put query string in my path

You should be able to do things like this by using url encoding instead of the non-alpha-numeric characters, for example entreprises%3Factivite%3Dassociations would be your redirect if you wanted to redirect to entreprises?activite=associations.

An easy way to do this if you don't know the codes for these characters is to use php code for the path and put the following for the path:

  $url = urlencode('entreprises?activite=associations');
  return $url;

This should work, but I have tried doing this many different ways and it doesn't work.

For some reason when you encode these characters they don't get decoded when you click the link but double encoded, so you end up with entreprises%253Factivite%253Dassociations.

Does anyone know why this is the case and/or how to get around it?

If I figure it out i'll get back to you.

But if I wanted to redirect to vacancys&otr=!tid?

I'm having the same problem, and trying to *decode* the resulting url. Linking to:

http://votesizing.org/en/Content_Wizard%3Ftid%3DSteve%20Glickman

... breaks, whereas:

http://votesizing.org/en/Content_Wizard?tid=Steve%20Glickman

... does not break. I've tried a lot of things with the code, php and settings; and am starting to wonder if this module is sending the right href string, but another one is mangling/encoding/breaking it.

Thanks in advance for any help.

Found this post:

http://drupal.org/node/158687#comment-580458

... and fixed.

I have views with exposed filter = b/search, in this module path for vocabulary = b/search?tid=!tid, but in result path = b/search%3Ftid%3D45
:(

So this is a problem with drupal, not the module? PHP solution in #1 did not work for me.

Try typing the full url rather than the relative one:

http://www.example.com/b/search?tid=!tid

I've had this issue all over drupal.

Let me know if it works for you.

Yes, this seems to be a problem with drupal.

The solution in #5 worked for me but from reading on the issue raised in that post and a few others it linked to there are a few different issues that are looking at the problem.

Will have to have a look and see what the best of those core solutions are.

unfortunately no, divinevette. It results in a repeat of the domain, because it appends rather than replaces, so you end up with:

example.com/example.com/b/search?tid=!tid.

Is it reasonable to allow for replacement instead of just appending, agileware? Or would that work at all...? Because although it reapeated the domain, everything else came out properly.

Any movement on this? I didn't understand the link in #5, or how to solve (a patrch for 5.x? on 6.x?)

I am trying to redirect my image tax links to a views filter which looks something like this: 'image-galleries/?race=55' which in tax_redirect is this: 'image-galleries/?race-!tid.' The odd thing is that if I hover over the link in firefox, it looks perfect. If I click the link, I get "image-galleries/%3Frace%3D55." In Safari, it is bad both hovered and clicked.

Using the full URL worked for me, but I had to comment out the '//' replace

Line: 556
//while (strpos($path, '//') !== FALSE) {
//$path = str_replace('//', '/', $path);
//}

#12 worked for me. Thanks ^_^

I traced it through and found a weakness in taxonomy_link.
If it is passed a (perfectly legal) path containing a query or fragment, it then places it into a link arrray is such a way that it would be munged when l() tries to use it later.
This can be avoided like so:

taxonomy.module.

BEWARE:core hack
SMILE: core hack -> core patch

 function taxonomy_link($type, $node = NULL) {
  if ($type == 'taxonomy terms' && $node != NULL) {
    $links = array();
    // If previewing, the terms must be converted to objects first.
    if (isset($node->build_mode) && $node->build_mode == NODE_BUILD_PREVIEW) {
      $node->taxonomy = taxonomy_preview_terms($node);
    }
    if (!empty($node->taxonomy)) {
      foreach ($node->taxonomy as $term) {
        // During preview the free tagging terms are in an array unlike the
        // other terms which are objects. So we have to check if a $term
        // is an object or not.
        if (is_object($term)) {
########################################
          // dman 2009-04
          // Although we (specifically taxonomy_redirect)
          // can return things via hook_term_path ... Using this array 
          // method of creating links encodes our URLs later!
          // I wanted to rewrite to redirect terms to a filtered view: /publications?tid=n

          $path = taxonomy_term_path($term);
          $url_parts = parse_url($path);
          // Need to pass the path  back in bits to avoid encoding.
          
          $links['taxonomy_term_'. $term->tid] = array(
            'title' => $term->name,
            'href' => $url_parts['path'],
            'query' => isset($url_parts['query']) ? $url_parts['query'] : '',
            'fragment' => isset($url_parts['fragment']) ? $url_parts['fragment'] : '',
            'attributes' => array('rel' => 'tag', 'title' => strip_tags($term->description))
          );
##########################################

        }
        // Previewing free tagging terms; we don't link them because the
        // term-page might not exist yet.
        else {
          foreach ($term as $free_typed) {
            $typed_terms = drupal_explode_tags($free_typed);
            foreach ($typed_terms as $typed_term) {
              $links['taxonomy_preview_term_'. $typed_term] = array(
                'title' => $typed_term,
              );
            }
          }
        }
      }
    }

    // We call this hook again because some modules and themes
    // call taxonomy_link('taxonomy terms') directly.
    drupal_alter('link', $links, $node);

    return $links;
  }
}

I believe this code is more robust that the previous version, and is not a special-case hack (although it is an edge case).
Previously was:

          $links['taxonomy_term_'. $term->tid] = array(
            'title' => $term->name,
            'href' => taxonomy_term_path($term),
            'attributes' => array('rel' => 'tag', 'title' => strip_tags($term->description))
          );

Anyway, Now I can use taxonomy_redirect to send to my filtered, exposed view like we were supposed to.

@dman: I tried this, to no avail.
#12 however, did work. I would prefer to use relative URLs, but this will work for now.

Maria

It appears that it only works, sort of.

My redirect looks like this: http://site.org/topics/!parent_names/?tid=!tid

For second level terms, this works just fine. It goes right to the correct View, with the exposed filter correctly selected.

However, first level terms look like this: http://stnina.org/topics//?tid=28

The TID is correct, but I want the URL to read: http://stnina.org/topics/term_name, no TID. In other words, !parent_term does not work.

I can of course, create redirects for all subterms, but since you can only select one subterm at a time (posting issue on this: http://drupal.org/node/466162).

Are you sure it's a problem with the core? If you examine the URL output by taxonomy redirect, it will transfor this:

strategy-guides?level=!tid&race=All&type=All

into this:

strategy-guides?level=!tid%26race=All%26type=All

which means there is a "25" too much in the URLencode

Anyway - i found a VERY weird fix - place http:// in fron of the path, like this:

http://strategy-guides?level=!tid&race=All&type=All

...And I get a nicely formatted URL - weird...

Thanks houen, your fix works, although it should only be considered a temporary solution.

I think that the correct way to fix this issue would be to have a separate textbox in the ui where we can enter pairs of keys/values which would be formed into a query string and appended to the path. For example:

key1|!tid
key|value

would append '?key1=123&key=value'.

Ideally, we would also be able to use php here, returning an keyed array of values.

I'm finding that the proposed fix from #17 seems to have problems in the safari browsers though it seems to work in most others.

Looks like my proposed solution in #18 won't work because of a limitation of the way hook_term_path() is implemented in core, it only allows you to return a path as a string, and not as an array with options.

we ended up scrapping the mod and implementing in our template.php in the
_links($links, $attributes = array('class' => 'links')) function. A little messy but we achieved what we needed with an array merge of query parameters with the $link and then creating the l();

I've had some success adding the query string using the Url alter module.

dman's solution in #14 makes sense and fixes it for me

I will submit a patch for drupal for that and it may or may not get in.
If not a solution similar to the suggestion in #18 might be the way to go

I have created an issue with dman's fix in #14 at #632646: taxonomy_link doesn't work properly if taxonomy_term_path path contains query or fragment

Hopefully it gets committed, otherwise we go a different way.

Because that doesn't need porting to 7,

I think for D6 version of the module it would be great just add a little help to the settings page
about creating paths with query string
using absolute url and dman's solution in #12

# 17 works for me .. strange though !

I kept it simple per #17

added

http://

in front of the intended relative url instead of messing with the core.

Subscribing, none of the solutions work for me. I haven't testet #17 because I don't want to hack core. Jet I didn't understand all steps behind #12?

I can't add string queries either. My links break every time. There needs to be a fix for this quick or the module is virtually useless.

EDIT: I have found a workaround solution. If you have URL redirect module installed, you can bounce the SQL query string URL to another URL and then use that URL for your taxonomy redirect.

E.g.

actual URL: news?news_type=88
"middleman" URL: news/accounting
taxonomy URL: category/news-category/accounting

i found it a bit strange to find that the $path is sent through the t() function before returning it. The t() documentation states:

Human-readable text that will be displayed somewhere within a page should be run through the t() function.

I dont think a path qualifies for this.

Attached is a patch that replaces t($path) with

return htmlspecialchars_decode($path);

Which makes sure that the question marks from the $path are rendered as question marks. No need to patch code for that it seems. (in my setup).

but does need review...

@ batje:
Thanks for the patch.

The path really shouldn't be run through t().
I added a new issue for that and it has been fixed. See #989516: Improper use of t() function on a url string

Unfortunately for my testing (using entreprises?activite=associations like the original poster) the patch in #31 doesn't seem to fix the problem.
Annoyingly, the problem isn't resolvable in this manner.

If anyone else is successful with it please let me know your set up. What redirect url you are testing with.

Now that I have come back to this I have had a quick look over it and with fresh eyes I have a solution :)

Basically it is a way of doing dman's solution from #14 (and the patch for core at #632646: taxonomy_link doesn't work properly if taxonomy_term_path path contains query or fragment) without having to hack core.

The patch is against current cvs but will apply with offset to 6.x-1.3

It seems to fix the problem for me but if others can test it would be great to get some feedback.

It would still be good to get the above mentioned core patch in but seeing as it has been there a year and hasn't been looked at I don't have high hopes. If it does ever get in this patch can just be reverted.

Also, it might be a good idea to be able to disable this feature in the case you do not have queries or fragments in your redirects as it would save a little on processing time.

Is there a definite fix or workaround for this?

My taxonomy redirect of news?tid=5 gets turned into news%3Ftid%3D5

I'm pretty sure that the patch in #34 is the definite fix for this, I just haven't had time to come back and commit it and no one but me has tested it and given feedback.

OK, I will test it and post again.

#34 worked for me. Will this be committed?

Thank you

Patch in #34 will only work for node links, not anywhere else where taxonomy_term_path() is called directly.

Yeah, your right.
The solution in #632646: taxonomy_link doesn't work properly if taxonomy_term_path path contains query or fragment is also in the same boat.

At least this will fix it for anyone who is not calling taxonomy_term_path() directly, although some other modules people have installed might be calling it for them.

Although if you are manually calling taxonomy_term_path() you could also then use
parse_url($term_path);
on your path and create the link properly.

The root of this issue, now that I think about it is actually taxonomy_term_path().
The problem is that it returns a string instead of a proper link array like is used elsewhere in drupal.

Taxonomy term path is not in drupal 7 and I really can't see the drupal 6 core team wanting to change an API function that drastically so I guess we are stuck with it and contrib modules and custom coders just have to work around in ways like the patches in #34 and #632646: taxonomy_link doesn't work properly if taxonomy_term_path path contains query or fragment do.

So really it is up to any module that calls taxonomy_term_path() to make sure that it does the necessary fixes for query strings and fragments to work, because taxonomy_term_path() just doesn't support them properly.

Maybe a drupal planet blog post or something would be good to try to get some word out to module maintainers etc. that use taxonomy_term_path()?

Yup, looks like the taxonomy system in D6 just simply wasn't designed to be flexible enough to fix this. Both hook_term_path() and taxonomy_term_path() return strings and not proper link arrays. Tempted to mark this as "won't fix". :(

I guess it depends if it is better to:

a. commit the patch in #34, which will fix the problem for users on simple set-ups who only care about node links, although on setups that also have term links printing elsewhere there will be inconsistency, where some links will be correct and some not (not great);
OR
b. mark as won't fix and document the problem (leaving this patch here for users who want the half-assed fix).

#34 worked for me.

It's weird that this problem have not found a definitive solution.
I've tried different solution in this post #34 #14 & #5, the only one that work for me is that of houen #17

I wanted to precise it
Instead of writing
projects?programme=!tid

You should write
http://projects?programme=!tid

& it'll link to
http://www.archiref.com/en/projects?programme=82

You don't write the domain, the language code ...only http:// before the url and it works.

Now I'm going to unpatch taxonomy_redirect and core taxonomy, because unfortunately, those patches haven't work for me

Nothing of all solutions didn't work for me... Tried with patches, hacking core and solution #17 and nothing...
It worked with php snippets, but unfortunately not for anonymous users..
Any help?