Allow to remove "Taxonomy Vocabulary" from urls

currently, this just won't work. you need a two-way mapping, so that the path always translates back to a valid assignment of facets.

please explain, what exactly you want to accomplish, because the code doesn't make sense

Hi,

would also really favor for a solution to remove the taxonomy vocabulary from the url. If more than one facet is applied eg. in commerce filtering first for a manufacturer and then further refining for a category, the urls get blown up unnecessary.

products/field_brand/some-brand-1/field_category/some-category-52

vs.

products/some-brand-1/some-category-52

By being able to remove the taxonomy vocabulary the url would get much more readable, shorter, It would also represent a SEO best practice.

Greetings

i'm changing this to a feature request which has been discussed with mh86. he's not yet working on it & but explained me an idea for enabling such a feature.

it's basically a follow up to #1863774: Taxonomy Pathauto coder which will get rid of the vocabulary name and leave just the term alias within the url.

in order to make it happen, we will also need to change some url processor logic, because currently its is tied to 2-part url segments per facet.

feel free to get in touch, if you want to provide funding in order to speed up this process

I had the same issue and I end up with creating a new facetapi url processors, it is not a generic solution which I have my taxonomy hierarchical as a configurable array(I know how to match my taxonomy hierarchy and my url pattern). So only issue on this task I think determining which facets belongs to which URL part and that's tough.

Finally found some time to work on this issue. Attached is a first working patch with a few known issues.

The patch introduces a new 'single term alias' mode where the alias is just constructed by the term name. This requires the pathauto pattern to be set to taxonomy/[term:name] and to re-generate all term aliases.

Unfortunately the assumption that an facet alias always consist of [facet-name]/[value] is very deep in the Facet API Pretty Paths system. To get it working it required some hacking in the class FacetapiUrlProcessorPrettyPaths and I introduced a 'resolveFacetByValue' callback that the coder plugins can implement to directly load the facet by a single URL argument (in our case the term name).

There are currently a few issues with the patch:

• The Facet API Pretty Paths module does not know anything about the base path. So it tries to construct the base path by using all URL elements that cannot be mapped to facets. In case any segment of the base path matches with a term name, the system will now badly break. I really would love to see a possibility to either set or retrieve the base path and not to do such complex reconstructions.
• The pattern for the single term alias mode is currently hard-coded to 'taxonomy/[term:name]'. We could also allow different patterns, as long as they are unique across all vocabularies and retrieve the pattern from the pathauto system
• Slight performance loss if the single term alias mode is activated (the system tries to resolve the term for each URL segment)
• Some documentation still assumes an alias is always constructed out of '[facet-name]/[value]'
• The code might need some further cleanup

And one more thing:
The system does not support multiple facets for the same search with the same vocabulary. So the mapping between vocabulary and facet should be unique.

hi mh86,

thanks a lot for approaching this :)

maybe it makes sense, that we try to get rid of the assumptions around [facet-name]/[value] that we are making at the moment. i can see that the patch already tries to do that at a certain level, but i think we could go a bit farther:

i'm thinking of treating $args as a stack that gets consumed by a chain of FacetApiPrettyPathsCoderDefault (sub)classes. Every coder ties to decode from the current stack state, and will either consume one or many parts of the arg stack.

sounds great, will give it a try and report back any findings!

Thanks for the feedback.
Having a chain of coder classes that decode the URL arguments sound interesting, although I don't know how exactly it should/can look like. Maybe we can discuss this in person when we meet each other the next time.

I'm still struggling a bit with the base path issue and I've just realized that there is possibility to retrieve the base path from the Facet API adapter, so it seems like we could use $this->adapter->getSearchPath() in FacetapiUrlProcessorPrettyPaths:fetchParams().

Is there any reason to not use this function?

yeah, i'd be happy discuss this in person.

regarding base path... that's a complex issue, see #1861786: Fix base path issues

the thing with the base path is really pretty complex. Spent some time today to find alternatives. Unfortunately I couldn't get it working in a general way, but at least I know now why it isn't working with the Search API.
The Search API Facet API Adapter tries to retrieve the base path from the current Search API search, but at the time the Facet API and the Facet API Pretty Paths system is initialized, the current search isn't yet set. So SearchApiFacetapiAdapter::getSearchPath(); returns $_GET['q'], which isn't save.

we could also include base path settings within the pretty paths module where you can set your own base path or select from a set of available strategies...

but i guess this should be discussed within a separate issue, probably as a follow-up to #1861786: Fix base path issues

I'll come back to #1861786: Fix base path issues once I have something working. It needs to be fixed in the Search API first and I think I know already how the base path issue can be solved.

This is working fine for me, if someone need to make validation trough view global null argument you need to make a few changes on -/sites/all/views/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc

<?php

/**
 * @file
 * Contains the 'taxonomy term' argument validator plugin.
 */

/**
 * Validate whether an argument is an acceptable node.
 */
class views_plugin_argument_validate_taxonomy_term extends views_plugin_argument_validate {
  function init(&$view, &$argument, $options) {
    parent::init($view, $argument, $options);

    // Convert legacy vids option to machine name vocabularies.
    if (!empty($this->options['vids'])) {
      $vocabularies = taxonomy_get_vocabularies();
      foreach ($this->options['vids'] as $vid) {
        if (isset($vocabularies[$vid], $vocabularies[$vid]->machine_name)) {
          $this->options['vocabularies'][$vocabularies[$vid]->machine_name] = $vocabularies[$vid]->machine_name;
        }
      }
    }
  }

  function option_definition() {
    $options = parent::option_definition();
    $options['vocabularies'] = array('default' => array());
    $options['type'] = array('default' => 'tid');
    $options['transform'] = array('default' => FALSE, 'bool' => TRUE);

    return $options;
  }

  function options_form(&$form, &$form_state) {
    $vocabularies = taxonomy_get_vocabularies();
    $options = array();
    foreach ($vocabularies as $voc) {
      $options[$voc->machine_name] = check_plain($voc->name);
    }

    $form['vocabularies'] = array(
      '#type' => 'checkboxes',
      '#prefix' => '<div id="edit-options-validate-argument-vocabulary-wrapper">',
      '#suffix' => '</div>',
      '#title' => t('Vocabularies'),
      '#options' => $options,
      '#default_value' => $this->options['vocabularies'],
      '#description' => t('If you wish to validate for specific vocabularies, check them; if none are checked, all terms will pass.'),
    );

    $form['type'] = array(
      '#type' => 'select',
      '#title' => t('Filter value type'),
      '#options' => array(
        'tid' => t('Term ID'),
        'pathauto' => t('Pathauto'),
        'tids' => t('Term IDs separated by , or +'),
        'name' => t('Term name'),
        'convert' => t('Term name converted to Term ID'),
      ),
      '#default_value' => $this->options['type'],
      '#description' => t('Select the form of this filter value; if using term name, it is generally more efficient to convert it to a term ID and use Taxonomy: Term ID rather than Taxonomy: Term Name" as the filter.'),
    );

    $form['transform'] = array(
      '#type' => 'checkbox',
      '#title' => t('Transform dashes in URL to spaces in term name filter values'),
      '#default_value' => $this->options['transform'],
    );
  }

  function options_submit(&$form, &$form_state, &$options = array()) {
    // Filter unselected items so we don't unnecessarily store giant arrays.
    $options['vocabularies'] = array_filter($options['vocabularies']);
  }

  function convert_options(&$options) {
    if (!isset($options['vocabularies']) && !empty($this->argument->options['validate_argument_vocabulary'])) {
      $options['vocabularies'] = $this->argument->options['validate_argument_vocabulary'];
      $options['type'] = $this->argument->options['validate_argument_type'];
      $options['transform'] = isset($this->argument->options['validate_argument_transform']) ? $this->argument->options['validate_argument_transform'] : FALSE;
    }
  }

  function validate_argument($argument) {
    $vocabularies = array_filter($this->options['vocabularies']);
    $type = $this->options['type'];
    $transform = $this->options['transform'];

    switch ($type) {

      case 'tid':
        if (!is_numeric($argument)) {
          return FALSE;
       }

        $query = db_select('taxonomy_term_data', 'td');
        $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
        $query->fields('td');
        $query->condition('td.tid', $argument);
        $query->addTag('term_access');
        $term = $query->execute()->fetchObject();
        if (!$term) {
          return FALSE;
        }
        $term = taxonomy_term_load($term->tid);
        $this->argument->validated_title = check_plain(entity_label('taxonomy_term', $term));
        return empty($vocabularies) || !empty($vocabularies[$term->vocabulary_machine_name]);

      case 'pathauto':

$termo = $argument;
$aaa = db_query("SELECT source FROM {url_alias} WHERE alias = :termo", array( ':termo' => 'taxonomy/'.$termo))->fetchField();
if (!$aaa) return FALSE;
$aaa = explode("/", $aaa);
$argumentb = $aaa['2'];
        $query = db_select('taxonomy_term_data', 'td');
        $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
        $query->fields('td');
        $query->condition('td.tid', $argumentb);
        $query->addTag('term_access');
        $term = $query->execute()->fetchObject();
        if (!$term) {
          return FALSE;
        }
        $term = taxonomy_term_load($term->tid);
        $this->argument->validated_title = check_plain(entity_label('taxonomy_term', $term));
        return empty($vocabularies) || !empty($vocabularies[$term->vocabulary_machine_name]);

      case 'tids':
        // An empty argument is not a term so doesn't pass.
        if (empty($argument)) {
          return FALSE;
        }

        $tids = new stdClass();
        $tids->value = $argument;
        $tids = views_break_phrase($argument, $tids);
        if ($tids->value == array(-1)) {
          return FALSE;
        }

        $test = drupal_map_assoc($tids->value);
        $titles = array();

        // check, if some tids already verified
        static $validated_cache = array();
        foreach ($test as $tid) {
          if (isset($validated_cache[$tid])) {
            if ($validated_cache[$tid] === FALSE) {
              return FALSE;
            }
            else {
              $titles[] = $validated_cache[$tid];
              unset($test[$tid]);
            }
          }
        }

        // if unverified tids left - verify them and cache results
        if (count($test)) {
          $query = db_select('taxonomy_term_data', 'td');
          $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
          $query->fields('td');
          $query->fields('tv', array('machine_name'));
          $query->condition('td.tid', $test);

          $result = $query->execute();

          foreach ($result as $term) {
            if ($vocabularies && empty($vocabularies[$term->machine_name])) {
              $validated_cache[$term->tid] = FALSE;
              return FALSE;
            }
            $term = taxonomy_term_load($term->tid);
            $titles[] = $validated_cache[$term->tid] = check_plain(entity_label('taxonomy_term', $term));
            unset($test[$term->tid]);
          }
        }

        // Remove duplicate titles
        $titles = array_unique($titles);

        $this->argument->validated_title = implode($tids->operator == 'or' ? ' + ' : ', ', $titles);
        // If this is not empty, we did not find a tid.
        return empty($test);

      case 'name':
      case 'convert':
        $query = db_select('taxonomy_term_data', 'td');
        $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
        $query->fields('td');
        $query->fields('tv', array('machine_name'));
        if (!empty($vocabularies)) {
          $query->condition('tv.machine_name', $vocabularies);
        }
        if ($transform) {
          $query->where("replace(td.name, ' ', '-') = :name", array(':name' => $argument));
        }
        else {
          $query->condition('td.name', $argument);
        }
        $term = $query->execute()->fetchObject();

        if ($term && (empty($vocabularies) || !empty($vocabularies[$term->machine_name]))) {
          if ($type == 'convert') {
            $this->argument->argument = $term->tid;
          }
          $term = taxonomy_term_load($term->tid);
          $this->argument->validated_title = check_plain(entity_label('taxonomy_term', $term));
          return TRUE;
        }
        return FALSE;
    }
  }

  function process_summary_arguments(&$args) {
    $type = $this->options['type'];
    $transform = $this->options['transform'];
    $vocabularies = array_filter($this->options['vocabularies']);

    if ($type == 'convert') {
      $arg_keys = array_flip($args);

      $query = db_select('taxonomy_term_data', 'td');
      $query->condition('tid', $args);
      $query->addField('td', 'tid', 'tid');
      if (!empty($vocabularies)) {
        $query->leftJoin('taxonomy_vocabulary', 'tv', 'td.vid = tv.vid');
        $query->condition('tv.machine_name', $vocabularies);
      }
      if ($transform) {
        $query->addExpression("REPLACE(td.name, ' ', '-')", 'name');
      }
      else {
        $query->addField('td', 'name', 'name');
      }

      foreach ($query->execute()->fetchAllKeyed() as $tid => $term) {
        $args[$arg_keys[$tid]] = $term;
      }
    }
  }
}

There is a new option called "pathauto" on the taxonomy validation, who check the name on your path and validate.

Hope this can help somenone

Thanks for pointing that out!
Please try to post a patch next time so it's easier to reuse, understand your changes and there's less clutter on the issue page :)

Is #15 a solution for this issue or is it something different?

Please see #6 for the latest solution to this issue and report back your findings

i cant get #6 to work. i have patched the module, set the pattern and regenerated all aliases. is there anything else i have to do? and will this also work if i want to filter on multiple terms?

I have a small reroll of my patch from #6.

This patch is based on a fix in the Search API that allows us to safely retrieve the base path ([#2159827). Sorry for not yet re-opening #1861786: Fix base path issues - it's already a bit complicated to keep everything separated.
By retrieving the base path via the adapter we also avoid possible clashes between the base path and terms with the same alias.

I recently had a quite similar need and solved the unique-term-name exactly the same way, +1 on doing that. However, how we should clearly notify users somewhere that this url alias pattern must be configured and in *active* use or the stuff will fail for them. Maybe, we could put a warning message to the setting?

Extending the facet coders that way makes sense + having the method in the base class does not make it an API change given it's required to use the base class? I guess in practice every coder does.

Besides that, here a review - mostly nitpicks:

1. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -17,7 +24,27 @@
   +  private function singleTermAliasMode() {
   

   Should use protected so that inherited classes can use it?

2. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -17,7 +24,27 @@
   +   * Taxonomy pathauto special case: <facet alias>/<term-name alias> (default)
   +   * or <term-name alias> (single term alias mode)
   

   Summary should fit in one line.

3. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -36,15 +63,31 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +   * Taxonomy pathauto special case: <facet alias>/<term-name alias> (default)
   +   * or <term-name alias> (single term alias mode)
   

   Summary should fit in one line.

4. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -66,6 +109,77 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +   * Resolves the facet for a single URL value if the single term alias mode is
   +   * on.
   

   Summary should fit in one line.

5. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -66,6 +109,77 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +   * Helper function that tries to load the term id for a given term name in
   +   * case the 'single term alias' mode is used.
   

   Summary should fit in one line.

6. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -66,6 +109,77 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +   * @return The term id if found, else FALSE.
   

   Description should be a line below.

7. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -66,6 +109,77 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +   * Helper function that returns an array of facets, keyed by the vocabulary
   +   * machine name.
   

   Summary should fit in one line.

8. +++ b/plugins/coders/facetapi_pretty_paths_coder_taxonomy_pathauto.inc
   @@ -66,6 +109,77 @@ class FacetApiPrettyPathsCoderTaxonomyPathauto extends FacetApiPrettyPathsCoderD
   +  private function getFacetsByVoc($adapter) {
   

   Should be protected?

9. +++ b/plugins/facetapi/url_processor_pretty_paths.inc
   @@ -72,48 +72,59 @@ class FacetapiUrlProcessorPrettyPaths extends FacetapiUrlProcessorStandard {
   +    if (strpos($this->fullPath, $this->basePath) === 0) {
   +      $facet_path = drupal_substr($this->fullPath, drupal_strlen($this->basePath));
   +    }
   +    $args = explode('/', $facet_path);
   

   Once we know our facet_path now, we should process the args in the logical order, i.e. from the beginning to the end? Or is there any reason left to do it reversed?

10. +++ b/plugins/facetapi/url_processor_pretty_paths.inc
    @@ -72,48 +72,59 @@ class FacetapiUrlProcessorPrettyPaths extends FacetapiUrlProcessorStandard {
    +        foreach ($facets as $facet_alias => $facet) {
    +          $pretty_paths_alias = $this->getFacetPrettyPathsAlias($facet);
    +
    +          // Add to params if alias from url matches alias from facet settings.
    +          if ($pretty_paths_alias == $alias) {
    

    This should use a static lookup map from alias to facet as it does for vocabularies?

11. +++ b/plugins/facetapi/url_processor_pretty_paths.inc
    @@ -72,48 +72,59 @@ class FacetapiUrlProcessorPrettyPaths extends FacetapiUrlProcessorStandard {
    +        // When no more facet path segments have been found,
    ...
    +        if (!$found) {
    ...
    +        // we assume the rest of the url as the search basePath.
    

    Deprecated?

12. +++ b/plugins/facetapi/url_processor_pretty_paths.inc
    @@ -218,6 +246,39 @@ class FacetapiUrlProcessorPrettyPaths extends FacetapiUrlProcessorStandard {
    +   * @return A facet object if it can be resolved by the value, else FALSE.
    

    Should specify the class + use a new line for the summary.

13. +++ b/plugins/facetapi/url_processor_pretty_paths.inc
    @@ -218,6 +246,39 @@ class FacetapiUrlProcessorPrettyPaths extends FacetapiUrlProcessorStandard {
    +   * Tries to resolve the facet by a single value in the URL (e.g. a special
    +   * mapping between term names and vocabularies/facets might be used).
    

    1 line summary.

+1

Patches should be rolled (& tested) against latest dev afaik (and it doesn't apply to latest dev.

attached a simple re-roll using git rebase towards the latest dev version

@dasjo: great.. working fine for me!

Only issue I see is that every path begins with search/site/..
My search pages have custom urls, so thats not correct I think. Is that the base path issue mentioned above?
In the other taxonomy coder patch, I think the path was retained (see #2160497: Date coder for pretty paths)

yeah those nasty base path issues, i hope we can get those finally fixed for all the use cases :)

could you have a look at
#2159827: Fix search base path in Facet API adapter
#1861786: Fix base path issues

@dasjo
#2159827: Fix search base path in Facet API adapter is for search_api, which i'm not using (using standalone apachesolr integration)
#1861786: Fix base path issues is closed and committed, so I'm not sure what to look for there.

Sorry for the slighly off-topic, but the paths are retained with the patch in #2160497: Date coder for pretty paths (i just restored it to test), and I cant see why they don't here.

I'd say that's because of the following line that's being added by the patch:

    $this->basePath = $this->adapter->getSearchPath();

so that doesn't seem to work for the way that you are altering the search path right now?
could you share a bit of the way how your search paths are set up with apachesolr module at the moment?

ideally, the right base path should be returned from the facet api adapter using the getSearchPath method.

so we should look at FacetapiUrlProcessorPrettyPaths::getBasePath():
http://drupalcode.org/project/facetapi_pretty_paths.git/blob/refs/heads/...

it has some logic to get search_api's base path.

i asked nick_vh on apache_solr and it seems you should be able to get the search_path through the adapter and its search environment

Sorry for not getting back at this, turns out in my usecase I did not need this patch after all. If time permits I will look back into it.

I'm trying patch #24 but I'm not sure if it's not working for me or I didn't set something right. Anyway I have standard pretty facet paths working and as soon I apply the patch (without any configuration changes) clicking on facets does not activate them and I get all nodes without filters.

Maybe some recent chages to facetapi or search api broke this patch?

I'm not even discussing next step to remove facet aliases from url at this point.

can you describe which urls are generated for the facets with the patch.
you'll need to make sure that the terms have url aliases associated with them.

OK I'll try to describe step by step what is going on.

Before applying patch #24 I have a facet and one of links is:
/products/category/lamps-224

Then I apply the patch and enable Reuse term aliases. The same link becomes:
/products/category/lamps
so something is working ;)

My terms aliases are set to: taxonomy/[term:name].

But after applying the patch regardless of "Reuse term aliases" option the search page does not filter nodes based on the path. Just as if I have opened main search path.

sorry for not getting back earlier, could you fix your problem?
can you describe how the search is created? are you using panels or any other layer in between?

Unfortunately I gave up and sticked with default pretty paths.

would be great if someone could address fago's comments in #21 and roll a new patch. i'd be willing to include this within the next release

Hello,

I'm also having same problem, trying to generate URL's without any aliases in them just the taxonomy term names:

I explained my process in here: http://drupal.stackexchange.com/questions/175822/search-api-search-widge...

But I tried to somehow substitute the facets, with taxonomy pages (but it didn't worked out) and I'm getting back to the facets.

With current version and patch 24 I'm able to generate urls such us:

http://localhost/search/field_city/{name_of_region}/field_city/{name_of_sub_region}/field_city/{name_of_city}?search_api_views_fulltext={yorkshire terrier}&field_city=1031

But I'm trying to achieve

http://localhost/{name_of_region}/{name_of_sub_region}/{name_of_city}/search?s={yorkshire terrier}&field_city=1031

Or in case of category type search
http://localhost/home-garden/pets/dogs/{name_of_region}or{name_of_sub_region}or{name_of_city}/search?s={yorkshire terrier}&field_city=1031

I'm super stuck with this and I'm currently running in circles so if anyone could suggest me the best approach to get that kind of clean facets url that would be great, I assume that I would need to write a my own hook for sort? not sure how to use the hooks described or what can be in them. are there any examples ? or how can I figure out what can I do in specific hook ?

is there any solution for the initial problem "Allow to remove 'Taxonomy Vocabulary' from urls" that made it into the official release or any new separated module?

any update on this to get URL structure without 'Taxonomy Vocabulary' from in URL

I managed to get this to work after some fiddling.

These are the steps I took:
- The lastest dev version of this module plus patch #24. There was one discrepancy with the patch and the dev code so I had to apply the patch code in url_processor_pretty_paths.inc fetchParams() manually. Namely I had to do $params['q'] = $this->basePath; instead of $params['q'] = $this->pathWithoutSegments; patch in comment #41.
- The patch above didn't work without the patch from https://www.drupal.org/project/search_api/issues/2159827#comment-11880360 I just used the patched module to avoid any issues. This solved the basePath issue.
- I had to set Default path pattern (applies to all vocabularies with blank patterns below) in /admin/config/search/path/patterns to taxonomy/[term:name]. Then I had to recreate my URL aliases for the taxonomy terms. This then got my facet urls working when I went to the desired URL manually.
- Now the last bit that got me so that my facet block links were created properly in /admin/config/search/facetapi_pretty_paths I had to change Base path provider from Default base path provider to Adapter base path provider

- make sure to reindex, clear caches, etc just to make sure it's all good.

Now I just need to do a bit more testing, but so far so good, I can go to the facet urls without any vocab prefixes and I have multiple vocabs in my facets and I can select multiple facets and they all seem to be working well!

sorry this patch is meant to be for comment #40 but I couldn't find a way to add the file to the comment and then I couldn't delete this file after I uploaded it..

Thanx @farse!
The patch from #41 works as expected.