Term ID converted to name URL: spaces and special characters

Sorry, due to URL safety encoding, there's no way to make that less ugly with Views' capabilities.

There should be checkboxes in the argument options to convert spaces to dashes.

Taxonomy: Term ID only accepts numbers, so it couldn't possibly do it. The validator could, but the problem here is that there isn't currently a good mechanism for the validator and the argument to communicate for the summary. For the moment, I'm afraid this is going ot have to remain an issue.

I'll add this to the feature requests.

Subscribing, looking for this also,
greetings,
Martijn

I needed this too, so I put together a patch to add a validator option to transform spaces to dashes in the URL. This argument has no summary view options, so I'm thinking that #8 should not be a problem.

This works fine for me to use a term name with spaces in the URL and retrieve nodes tagged with its child or parent terms.

Oops, updated patch. I tried to make the checkbox dependent on selecting the term name option, but that wasn't working right so I went back to showing it with the taxonomy term options. If there's a way to show it only when the term name option is chosen, I couldn't figure it out.

KarenS: There almost certainly is a way to do that, but it's a pretty obtuse syntax. Especially if radio buttons are involved. I'll look more deeply at this soon.

Patch apply and works fine (not deeply tested).
my 2 cents.

Thank you KarenS for this patch!!

I found this thread after searching around for how to convert dashes in the URL to spaces in the term name.
i.e. /viewpath/my-term allows me to filter results for all items tagged with "My Term"

I couldn't figure out how to get this working natively using the arguments validator. But it appears that KarenS's patch in #11 allows this.

A couple of things to note though:

1 ) Correct me if I'm wrong, but rather than the verbiage on line 48 "Transform spaces to dashes in URL", isn't it more correct to say "Transform dashes to spaces in URL"?

2 ) Usage:

- It works as expected when the Argument is "Taxonomy: Term ID" and the Argument Type is "Term name/synonym converted to Term ID" and the new "dashes to spaces" checkbox is checked.

- However, if the Argument is "Taxonomy: Term" and the Argument Type is "Term name or synonym", you have to check BOTH the new "dashes to spaces" checkbox AND the "spaces to dashes" checkbox near the bottom of the Argument Configuration fieldset. I'm not quite sure why this is.

Besides that wierdness, it works like a charm! I haven't tested this on levels with depth yet, but considering that the meat of the code is the statement on line 107 $argument = str_replace('-', ' ', $argument);, I don't see why there would be any problems.

bookmark

The correct name should be Tramsform dashes in URL to spaces in term name arguments

My 2 cents

This is my issue as well:

I found this thread after searching around for how to convert dashes in the URL to spaces in the term name.
i.e. /viewpath/my-term allows me to filter results for all items tagged with "My Term"

I was able to get this working without using the patch (my development requirements preclude including any code that is not part of an official module release) by using the "Term Synonym" argument and setting up a synonym for each of the terms that I needed to be processed through the view. So "My Term" gained a "my-term" synonym and was returned via /viewpath/my-term. Obviously this is impractical if you are dealing with many terms, but if you have only a few to deal with as I did...it works.

There is the transliteration module for this kind of work, which is also used in pathauto.

So it'd be great to make Views use it on generation of arguments.

Committed. Thanks, Karen!

There is one issue with the patch in #11.

If you have taxonomy terms that already have spaces and dashes, that patch can't tell which dashes were originally spaces and which were dashes.

This patch fixes that issue.

It also makes it so that the transform option only appears when you select the convert option for the argument type.

That's a nice improvement. Committed!

You say that your taxonomy term name includes a special character (ampersand), which is converted to %2526, and the argument still works. For some reason this isn't working form me. Spaces are correctly converted into dashes. However, when I use a taxonomy term with an ampersand in it, I am unable grab the taxonomy term name from the URL in a views argument. Is there anyway around this?

Also having this issue. When using the Term argument and Transform spaces to dashes in URL is checked, if my term has an ampersand, it isn't removed or converted, which causes the page to return a 404 error.

I'm confirming #25. I have, for example, a taxonomy term "Colds & Flu". I have to enter "colds-%2526-flu" in the URL to get the argument to validate.

@balsama @daobydesign @madmatter23 no action is taken on closed issues. So if this issue needs to be re-opened then the status should be updated and a sufficient description of why it should be re-opened (or even better a patch) included.

Leaving status as closed (works for me).

The attached patch adds a checkbox to convert the word "and" into an ampersand in query when used as part of an argument and also converts the word "and" to an ampersand in the title of the view. This is useful for sites that have existing taxonomy terms containing ampersands when you want to use them as views arguments in the URL. Previously, the only way to do so was to enter "%2526" in the url.

With this patch, for the taxonomy term "Colds & Flu" ,the URL: /colds-%2526-flu becomes colds-and-flu.

Please use drupal codestyle see http://drupal.org/coding-standards

Forgot to add spaces to the string in the title so that words like "hand" don't get partially replaced.

@dereine, what part of the coding standards did I not follow? I don't see anything wrong.

Spaces instead of tabs :)

This one should be good. I think my patch creator was adding some arbitrary spaces.

I have a couple of notes:
* This really should have it's own new feature request issue. Your patch is for the string argument handler and this issue is for the taxonomy term argument handler.
It is good for people looking for issues if patches providing different functionality are in separate issues.
* The patch should be created from to root of the views folder - See http://drupal.org/patch/create (the whole page is useful but specifically the part under the heading 'Switches for the diff command' relates to this).
* Even getting around that issue the patch doesn't seem to apply cleanly. I tried 6.x-2.11, which is the version you listed in this issue and also 6.x-2.x-dev and it didn't apply fully.
* Also, it is useful to give the patch a more meaningful name. This helps people that deal with a lot of patches. It also helps people who have applied the patch to see where it has come from on drupal.org. See http://drupal.org/patch/submit
* There are still quite a few lines that start with a tabs instead of spaces.

+++ views_handler_argument_stringNEW.inc
@@ -145,9 +152,18 @@
-    if (!empty($this->options['transform_dash'])) {
+    if (!empty($this->options['transform_dash']) && empty($this->options['transform_amp'])) {
       $argument = strtr($argument, '-', ' ');
     }
+	
+	if (!empty($this->options['transform_dash']) && !empty($this->options['transform_amp'])) {
+     $argument = strtr($argument, '-', ' ');
+	  $argument = str_replace(' and ',  ' & ', $argument);
+   }
+	
+	if (empty($this->options['transform_dash']) && !empty($this->options['transform_amp'])) {
+	  $argument = str_replace(' and ',  ' & ', $argument);
+   }

The logic here isn't ideal.

You should only need something like this:

<?php
  if (!empty($this->options['transform_dash'])) {
    $argument = strtr($argument, '-', ' ');
  }
  if (!empty($this->options['transform_amp'])) {
    $argument = str_replace(' and ',  ' & ', $argument);
  }
?>

Also, it's great that you are making patches. The more people that can do that the better. The whole patches section is useful to anyone making patches. - http://drupal.org/patch

Powered by Dreditor.

New patch attached.

1. Created from the module root directory
2. Tested and applies cleanly
3. Name changed
4. All tabs converted to spaces
5. Logic rewritten to achieve same result with only two IF statements

Thanks to @Agileware for the feedback.

Cool, that's looking a lot better.

One more thing though:

+++ handlers/views_handler_argument_stringNEW.inc	2010-08-18 10:23:25.000000000 -0400
@@ -201,9 +212,18 @@ class views_handler_argument_string exte
-    if (!empty($this->options['transform_dash'])) {
+    if (!empty($this->options['transform_dash']) && empty($this->options['transform_amp'])) {
       $title = strtr($title, '-', ' ');
     }
+
+    if (!empty($this->options['transform_dash']) && !empty($this->options['transform_amp'])) {
+      $title = strtr($title, '-', ' ');
+      $title = str_replace(' and ', ' & ', $title);
+    }
+	
+    if (empty($this->options['transform_dash']) && !empty($this->options['transform_amp'])) {
+      $title = str_replace(' and ', ' & ', $title);
+    }

This part can also use the simplified if logic.

Powered by Dreditor.

Oops that was me, I should check who is logged in before posting. Sharing computers = :(

Updated. Thanks.

The problem here is that there are a gazillion possible ways to try to transform a field, and it has to be a reversible transformation so that you can get back to it.

I'm not sure I want to go down the path of adding more, arbitrary transformations.

The right answer is through data. Using fields for nodes and synonyms for taxonomy, you can create unique identifiers through whatever transformations you desire and store those in the database. That makes it much easier to use THAT as an argument, get the data you need, and have your cake and eat it too.

In an ideal world, there's a module that does it for you, and lets you have some control over how these unique identifiers are formed. But I don't think I want to add more of these to Views.

I am more or less still beginner with Drupal but I have the following problems with using synonyms as an argument. I'll try to explain.

We have a section with articles on our site which using catogeries (litterally) like "Work @Our-Company". The name of our company is using dash in the name (For a personal reason I don't want to write a real name). I would like to have a link then for this category like /articles/category/work-at-our-company. I cannot use space-to-dash rewrite rule for the argument because it will be then rewritten in sql query to "work @our company" which will also remove the dash in the name of the company. There is also no way for me to rewrite at sign to the simple "at".

Now I came to point where the synonyms look as a good choice. For example to make a synonym like "work-at-our-company". But here I don't see the way how to translate synonyms. The original category term is translated via i18n translate interface to more than 5 languages, like for german something like "Arbeit @Our-Company". How to make a synonym for a translated category term? Because adding something like "arbeit-in-our-company" is possible only to the default term which has a language "english". I am stucked here. Still I think this is more related to taxonomy/i18n than the views. Can someone give an advice on this?

The conclusion:
I just want to have the link like articles/category/work-at-our-company in english language and artikel/kategorie/arbeit-in-our-company in german, where the both links are using the same term name which is "Work @Our-Company".

Your best bet may be path aliasing, but pathauto won't handle things outside of taxonomy/term automatically. So you would have to set up the aliasing manually. I THINK i18n language selection works okay with path aliasing.

Am I correct that the synonym solution no longer works in Drupal 7? I've set up path aliasing and that works fine except for this problem: the Search by Page module has trouble building its index. This module allows you to list pages which it should load and index during cron runs. The term that's giving me issues is "Books & E-Books". When I load in my browser either the original page created by the view (find/resources/books-&-e-books) or the path alias (find/resources/books-and-ebooks), the page displays fine. However, when the SBP module loads the page for indexing, I get this error:

Content not rendered (not found) - PID (559), path (find/resources/books-&-e-books), language (en)

or this one (depending on which page I've listed in the SBP settings page)

Content not rendered (not found) - PID (559), path (find/resources/books-and-ebooks), language (en)

As you can see, Drupal can not render this View either with its actual URL or its alias. I've reported this to the SBP issue queue, but the module maintainer sees this as a problem with ampersands not being valid in paths. Do you have any thoughts which may help me sole this problem?

Thank you.

I just found this thread after a reply in the pathauto module telling me this problem stems from views. Here was my original post and fix using combination of Rules and Path Alias http://drupal.org/node/1459158#comment-5666278

Will probably try the patch when i get around to it, but now working in Drupal 7. This temporary fix worked in Drupal 6 for me.