Hyphens and forward slashes (-/) break Views contextual filters

This is also a problem here. I have a site which uses CCK Location city names as arguments. There are some cities which have a dash in it (like "Kangnam-gu" in South Korea) and that breaks the view argument.

I did not know there was an option in the views argument settings called "Transform spaces to dashes in URL"

When I turned that OFF the problem above was solved for me.

Adding tag

Marking #814374: Can't pass argument when value cotains forward slash as a duplicate of this issue.

Also in the original post it says
"plus signs, dashes, or backslashes (#+-/)"

backslash : is \
forwardslash is /

TravisCarden did you test with \ or / ?

#814374: Can't pass argument when value cotains forward slash tested with /

marked #893096: Single argument but the word has a + as a duplicate

@dereine
Weren't you working on something similar during the DevDays? Maybe you have a comment :)

The reason why this does not work is that #/+ are things which has special meanings in the url.

For example # doesn't get sent to the browser, + is a space.

There's no way to make the / work -- not because of encoding, but because Drupal separates arguments by / and there's no way to avoid that, encoding or otherwise. SO no matter what you do, that will simply never work.

The others actually should work # and ? and stuff get properly encoded by Drupal's link functions and should be decoded by HTTP itself.

I'd be SHOCKED if - don't work -- they get used often, and nothing encodes them anyway. Caveat: They'd break if you turn on the convert dashes to spaces functionality and you have both spaces AND dashes in a word.

And naturally I have a use case that has exactly this situation: spaces and dashes in the argument (manufacturer supplied data so I can't change it). #curses

Right. So "C - D" unfortunately cannot work. The translation is destructive. If you transform spaces to dashes, and your input is "C---D" when it goes to look it up, it transforms it back into "C D" -- which is not the original title. Transforming spaces to dashes when the original contains spaces AND dashes is destructive. That is a fail.

Likewise, "This/That" can't work for reasons mentioned earlier.

The only one that is odd, then, is "A + B" -- that should work, because the + does get properly encoded and it should transform back. I'm not sure what might be wrong in that case.

Unfortunately, for a situation like this, what I really recommend is using a field of some sort (possibly CCK field) that is populated by PHP code that transforms the title into something that is URL safe. That way, there is no worry about losing data in the translation that cannot be transformed back. You can accomplish this with a little bit of effort using the CCK Computed Field and some PHP to make the transformation. (ctools has a 'cleanstring' utility you can use to easily make the transform).

Thanks for the lead Travis, but I took the easy road on this one and changed the supplied data to be more argument-friendly. But Views Alias looks like a good trick to have up my sleeve.

Not a solution for everyone, but if you want to use dashes, try using ndashes instead.

Put – instead of -. If you look close, the first one is longer than the second one. The first one doesn't get removed in the query, the last one (regular dash) does.

You can just copy it form here: –
Or here: http://www.zytrax.com/tech/web/entities.html

I hope this helps some ppl!

I have a solution (at least for dashes). In my case, I wanted to pass multiple arguments, some of which would have dashes (e.g., "not-front+sitewide+about"). I left the "Transform spaces to dashes in URL" unchecked, so that my arguments were getting passed to the views_break_phrase_string() function with dashes still included. However, they do not get split properly.

In that function, I noticed that the regular expression uses the "\w" shorthand expression, which matches letters, numbers, and underscores (it's actually replaced with "[a-zA-Z0-9_]"). (More on the "\w" character.)

Since dashes are commonly used as replacements for spaces, I think it's a good idea to include dashes as a "word character". The two-line patch accomplishes this.

This patch doesn't apply anymore because the regex changed

Additional please create a patch which can be applied via patch -p1 < patchname. Thanks

Additional it would be cool to document the full regex by making it multi-line items.

I just noticed that the code I changed was also changed as a result of #1153370: Using a taxonomy term with a space in the term produces the wrong query.

See the commit here:
http://drupalcode.org/project/views.git/commitdiff/4b2d0f50359986f7d8146...

Not sure if my solution needs to be reconsidered, and it's been too long now that I can't remember how to test it properly. :)

We are having similar problems with one of our views and I'm not sure after reading this conversation if there is a good answer? Basically, among other fields in our view, we have a URL field and a title field. The View is set up so that the URL field (set to default) is hidden and the Title field is set up to rewrite as the URL field token [field_link_url] with absolute path checked. So, our titles are clickable links that take users to other websites or pages.

This works great except when there is a "+" sign in the URL. When you click on one of these title links, the "+" is converted to %2B and the link breaks. If we replace all "+"s with %20, the links work. It would be great if we didn't have to manually change the URLs!

I should also add, if we have the same link in the body field that is displayed (set to Filtered HTML), the links work fine.

Any help would be greatly appreciated!

The patch in #19 seems related to #1417400: Various characters (UTF-8 characters, dashes, and symbols) cause views_break_phrase_string() not to work, where I've posted a more general patch (that handles more than just dashes).

But it seems to me like the issue here was originally about a slightly different problem...? Which is why I posted my patch in the other issue rather than here.

I had a use case where one of my contextual filters was a URL (with forward slashes, obviously): I got around this issue by implementing 'hook_views_pre_view'

function <mymodule>_views_pre_view(&$view, &$display_id, &$args){
  if( $view->name == '<my specific view name>' ){
    $url = '';
    $last_idx = count($args) -1;
    foreach($args as $key => $piece){
      $url .= $piece;
      if($key != $last_idx){
        $url .= '/';
      }    
    }
    foreach($args as $key => $arg){
      if ($key != 0 ){
        unset($args[$key]);
      }
    }
    $args[0] = $url;
  }
}

There may be a patch that fixes this here: #1768738-2: Terms with ampersand are not converted to term-id when sent as arguments

Adding a tag.

Updated issue summary.

Seemingly related is the fact that hashtags (e.g. #test) as taxonomy term names seem to break (read: hang completely) views as a contextual filter value if and only if that filter is set to allow multivalue. views_break_phrase_string seems to correctly explode the array but it dies somewhere after that.
It curiosuly works if you disable multivalue explosion support for the handler but the results of the views_break_phrase_string are identical either way. It much have to do with how views is processing the multi value array. i just dont know views internals well enough to dig deeper today.

Long story short it seems to work if you ditch multivalue explosion.

I have also run into this issue with Drupal 7.x and Views 7.x. I have a views contextual filter based on a field which can contain both spaces and dashes but the URL alias will be the same regardless. For example:

1. "British Trackstar" --> URL "british-trackstar"
2. "Harley-Davidson" --> URL "harley-davidson"

This situation means that when the views "Transform spaces to dashes in URL" option is enabled #1 works but #2 doesn't, and when the option is disabled it works for #2 but not for #1.

What I did to fix this:
1. Disable the "Transform spaces to dashes in URL" views argument option.
2. Enable "Allow multiple values" views argument option.

Add this hook in a custom module:

/**
 * Implements hook_views_pre_view().
 */
function hook_views_pre_view(&$view, &$display_id, &$args){
if ($view->name == 'your_view_name' && $display_id == 'your_display_id') {
    if (isset($args[0]) && !stristr($args[0], ',')) {
      $args[0] = $args[0] . ',' . str_replace('-', ' ', $args[0]);
    }
  }
}

Note: replace the "your_view_name" and "your_display_id" with the corresponding values. Also check if the $args[0] key is correct, since the code above will only work when the faulty contextual filter is the first contextual filter. If you have more than one you can duplicate the if statement and increase the $args[0] to $args[1].

This seems to work pretty well in my situation without the need to manually create url aliases and all the hassle that this would bring in releases.

Using Drupal 8.0.5 and a contextual filter with a hypen in the field value (e.g., "this - that") does not work.

Any update on this issue? And how can I fix or workaround?

jdn

Here is a patch for 8.2.4 to solve # and & in the same way hyphens was solved.

I added a patch for 8.2.4 to allow # and &, the same way hyphens were allowed.

@obiwankenobi Please submit patches as comments and don't delete the issue summary.

Their comment: "I added a patch for 8.2.4 to allow # and &, the same way hyphens were allowed."

Re-rolled the patch as it was made incorrectly before (which is why tests failed). I also noticed that forward slashes were not added to the regex per the original bug report, so I added that and test coverage as well. This is ready for review.

Nitpick: realized that old array syntax was used in the patch from #36, fixed now.

This issue still remains in Drupal 8.6.13.

If you have a taxonomy term with a hyphen already in the name, using the option "Transform dashes in URL to spaces in term name filter values" means that when trying to use this name as an argument in the URL it serves a 404 not found.

The above patch #43 seems to be in core which is odd!

Any ideas anyone?

we also ran in this issue.
we use taxonomy terms that have spaces an - to make it more fun :-s argument filtering on taxonomy term does not work now.

I ended up creating a new field on the taxonomy vocabulary called "display title". Then wrote a pre-save function to convert spaces to hyphens in the title and used the the unaltered title in the display title field. As well as turning off the setting in Views to convert hyphens to spaces.

Maybe if we unassign someone will review. I don't think it's my problem with slashes but will definitely review if it is / can reproduce anyway.

Also dots? Example: https://libreav.org/software/bshapr vs https://libreav.org/software/radium (the external link title block and the recent releases block at the bottom).

Edit: found I could use 'Content: ID' with 'Entity ID converted from URL path alias' for the default value.

I came here because Contextual Filters are breaking for me when I use a value that has parentheses e.g. "Program in User Experience (UX) Design".

I made a patch using #43 as a starting point but since it's for a different Drupal version I didn't do interdiff, please let me know if I should have.

I could use some help with the testing bit as I've never done it before.

Updated

1. +++ b/core/modules/views/src/Plugin/views/HandlerBase.php
   @@ -728,12 +728,12 @@ public static function breakString($str, $force_int = FALSE) {
   +    if (preg_match('/^([\w0-9-_\.\#\&\/\(\)]+[+ ]+)+[\w0-9-_\.\#\&\/\(\)]+$/u', $str)) {
   ...
   +    elseif (preg_match('/^([\w0-9-_\.\#\&\/\(\)]+[, ]+)*[\w0-9-_\.\#\&\/\(\)]+$/u', $str)) {
   

   Should we maybe move the construction of this pattern to a method so we can be sure that both the ',' and '+' version stay in line with each other? It's hard to tell if we missed a character like this.

2. +++ b/core/modules/views/tests/src/Functional/Handler/HandlerTest.php
   @@ -108,6 +108,21 @@ public function testBreakString() {
   +    $handler = HandlerBase::breakString('Law & Order,word,word');
   +    $this->assertEqualValue(['Law & Order', 'word', 'word'], $handler);
   +    $this->assertEqual('and', $handler->operator);
   

   We are only testing the ',' version of the regex in the new tests, we need to test both.

I faced this issue with hyphens for Text field contextual filters. I fixed it with the following patch.

Hi I am using contextual filter in views with rest export enabled for the display.
http://siteurl/searhkeyword.
When I search keywords like "rainy/cloudy" in my contextual filter it redirect into new path instead of searching that keyword.
http://siteurl/rainy it give me result while if I search http://siteurl/rainy/cloudy it redirect to new path which gives page not found error. I have applied and tried both patches #58 and #43 none works.

I am using 8.9.20 version of Drupal and Solr search api 8.x-1.7.

Bumping priority to major per: https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...

Followed #56

Addressed the issues in #58

Only thing I wasn't 100% on when adding the new tests is when a string like Law & Order+word+word wouldn’t the expected behavior be [‘Law & Order’, 'word’, ‘word’]. Current code appears to be breaking up around spaces

Tried attaching an interdiff but got this error interdiff: Error applying patch1 to reconstructed file. Seems to be missing the tests

This is the same as #65 but with a tests-only patch

Looking good. Some clean up nitpicks:

1. +++ b/core/modules/views/src/Plugin/views/HandlerBase.php
   @@ -874,4 +874,12 @@ public function calculateDependencies() {
   +   * Pass in a string to be added to an auto generated pattern.
   +   */
   +  private static function generatePattern($string = ',') {
   

   This should better describe what pattern we are generating and what we expect it to do.
   Also the parameter needs a docblock @param

2. +++ b/core/modules/views/src/Plugin/views/HandlerBase.php
   @@ -874,4 +874,12 @@ public function calculateDependencies() {
   +    $op = ($string === ',') ? '*' : '+';
   

   Would probably be better to just pass the $op as a parameter too, otherwise we need to document what is going on here

Added 2 from #68 and 1 to the best of my ability

Testing this

Verified for Drupal 9.5.X version
https://www.drupal.org/files/issues/2022-07-15/672606-69.patch

Testing Steps:
* Install a new Drupal instance.
* Created new three taxonomy. named tag1,tag2-tag2,tag3/tag3 for Tag category.
* Created view page to display those taxonomy term. Set name contextual filter wit display summery option. Also added overrided title %1 which is describe by the #29. At last selected Transform spaces to dashes in URL for the view.
* visited page generated by view.

Problem:
For forward slash facing URL generator error.

Test Result :
Before applying patch for tag2-tag2 is working as expected.
However for the forward slash facing another issue. Which cause page unexpected. (same output after applying patch too.)

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "arg_0" for route "view.tag_taxo_list.page_1" must match "[^/]++" ("tag3/tag3" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 203 of /app/core/lib/Drupal/Core/Routing/UrlGenerator.php).

Refer SS:

Without Patch for -

With and without patch for / facing page broken
error

Patch result fail.

If you're seeing it with and without problem sounds like a separate issue unrelated to this issue.

It *is* part of the issue!

As part of the process to build the exposed filter form, ViewsExposedForm::buildForm() builds a URL to stick in $form['#action'], if view::hasUrl() is true then view::getUrl()->toString() is called which eventually causes Symfony to throw a wobbly when it validates the argument against the pattern '[^/]++' (which it patently does not satisfy as the argument *does* contain a '/').

Since I am calling my view(s) programmatically and I couldn't care less about the form, I have a patch for ViewExecutable that adds a "build_the_url" flag + setting function; hasUrl() is modified always to return FALSE if "build_the_url" is not TRUE. This cause buildForm() to create a URL from the current route (which I don't care about). My calling code only sets the flag false if one of the arguments contains '/'.

This is not a viable approach in the general case*, hence the reason why I'm not offering the patch, but just a description.

(*It's just horrible I know - but I've spent more than a week on this and I'm ready to commit mayhem on the lunatics that decided that it was perfectly acceptable to have '/' in the internal representations of the filter values on the site on which I am working!!!!)

Unfortunately, I believe this now has to be targeted for 10.1.x

Reroll the patch #69 with Drupal 10.1.x .

Thanks @Medha Kumari but #76 wasn't needed as #69 still cleanly applied to 10.1 adjusting credit.

The patch looks good here, the only issue remaining is that the URL generated for an item with a / causes a fatal exception now.

Not sure what we can do about that, we might need to replace it with a special character and then switch it back?

We could use ̷ or ̸which are unicode characters that look like slashes but are not

They are U+0337 and U+0338

See https://unicodeplus.com/U+0337 and https://unicodeplus.com/U+0338

I applied #69 on Drupal 9 and I still have the scenario described at #32 being that for terms without dashes in the names like 'two words' the page would load but for terms with a dash in the name like 'two-words' it would be page not found.

'two words' url = 'two-words'
'two-words' url = 'two-words'

The former loads the page the latter shows page not found.

I got 'Transform dashes in URL to spaces in term name filter values' turned on.

Before I applied the patch I think I had exact same experience at #32 like turning 'Transform dashes in URL to spaces in term name filter values' on and off will switch back and forth to working for the 2 scenarios like if turned on it works when a dash is in the name and when turned off it works when no dash in the name and stops working for when there is a dash in the name. I cannot remember exactly if this was so but I remembered that when I first noticed some pages showing page not found I fiddled and turned on 'Transform dashes in URL to spaces in term name filter values' and the issue went away not until some other day I clicked a page and it wasn't working then I turned off 'Transform dashes in URL to spaces in term name filter values' and it started working for the page. I didn't think about terms with a dash in the name or not as at then but I kept getting confused as I kept turning 'Transform dashes in URL to spaces in term name filter values' on and off and each time it would work for the page I was on and tomorrow I check some other page and it won't be working.

Now with patch #69 it only works for terms with no dashes in the names i.e. 'two words' and for 'two-words' it won't work either 'Transform dashes in URL to spaces in term name filter values' is turned on or off.

I tried this patch instead and it worked better.
Both 'two words' and 'two-words' term names work.

Well I thought 'it worked better' but it doesn't so I am back here and will go back to patch #69 once I resume work tomorrow.

#69 working with Drupal 10.2.3

Our issue was specifically with forward slashes in an argument.