Default argument not skipped in breadcrumbs

It would be good if you could provide an export of the view, so it can be reproduced very easy.

Please feel free to flame me if I should've opened a new issue :X

Here is my situation (find attached the view):

The view shows the images paginated that are inside a multivalue field, in a node:
Path: node/%/imagenes

Displaying: 1 image field, one value per row

Argument:

• content id from url
• overriding the title
• Override breadcrumb is off.
• Validation: numeric, show 404 if if doesnt validate.

This results in a breadcrumb entry is inserted pointing to node/all/images, which shows the view with no results.

Idealy (at least in my case) would be to have the breadcrumb point to node/% having the title of the node.

I've also tested removing the argument 'Exception value' all. This results in the breadcrumb link pointing to node/*/imagenes

I'm having the same issue.
I have a view that uses 2 arguments as "Term ID from URL".

The view is in the menu.
The view keeps adding the "all" link within breadcrumb.
E.g. :

- Home
- Term1 [Home -> Term1 -> Vocabulary1_name(/all)]
-- Term2 [Home -> Term1 -> Term2 -> Vocabulary1_name(/all) -> Vocabulary2_name(/all/all)]
-- Term3 [Home -> Term1 -> Term3 -> Vocabulary1_name(/all) -> Vocabulary2_name(/all/all)]

I don't want the breadcrumb to show the vocabulary names with wildcards links.

A couple of ideas to possibly help with this problem are given at #1345852: Override the views breadcrumb path

Just ran into this problem myself.

If you dig around in the Views code long enough, you'll find views_handler_argument::uses_breadrumb() function in handlers/views_handler_argument.inc.

Then it checks in views_handler_argument::default_actions() - and you can see breadcrumb => TRUE under summary, empty, not found, default, and ignore.

The troublesome code seems to be in view::_build_arguments() in includes/view.inc around line 840:

        if ($this->display_handler->uses_breadcrumb() && $argument->uses_breadcrumb()) {
          $path = $this->get_url($breadcrumb_args);
          if (strpos($path, '%') === FALSE) {
            if (!empty($argument->options['breadcrumb_enable']) && !empty($argument->options['breadcrumb'])) {
              $breadcrumb = $argument->options['breadcrumb'];
            }
            else {
              $breadcrumb = $title;
            }
            $this->build_info['breadcrumb'][$path] = str_replace(array_keys($substitutions), $substitutions, $breadcrumb);
          }
        }

This code probably shouldn't run if the contextual filter isn't set to override the breadcrumb, but it does anyway.

As OP probably also found - get_url is receiving an empty $breadcrumb_args, which is causing it to fall down to the default actions, and then when view::get_breadcrumb() is called, it array_merges the Views generated breadcrumb with the Drupal generated breadcrumb which is causing the breadcrumb to output something like Home (/) > Example (/example/all) > Example (/example/5).

This is just a brain dump of what I've figured out so far. I think there probably IS a bug here, but it's difficult to tell whether or not this is working as designed or not.

@jmking following what you started, if you provide a default value for an argument, then uses_breadcrumb() for the argument handler returns true. Attached patch will tell arguments to ignore the breadcrumb if the exception value is empty

#8 is exactly what I needed.

Lets try to get this into dev.

Works for me and is the logical way I think: "empty value" == "empty breadcrumb" which means in french: "If there is no value, I want no exception"

Thanks for this patch.

What's the difference between #8 and #10? Either way, capitalization and punctuation are missing from the comment.

There's no difference, just was trying to requeue to see if the test would go through.

Unfortunately, not until #2450447: Drupal QA is broken for Views 7.x-3.x gets fixed.

Just changing the patch name to match drupal.org standards in accordance to https://www.drupal.org/node/707484

Re-rolled against HEAD

It looks like something with tests is broken. I reviewed the console output and all tests pass. The failure appears to be unrelated to this patch. Re-setting to Needs Review.

Re-rolled against HEAD.