right now, we have
Pretty paths will be generated as "search/url/segment1/segment2/".
- By default, a segment will look like: "<alias>/<value>".
- For taxonomy terms it outputs the id as well: "<alias>/<term-name>-<term-id>".
there are some @todo notes in the code where i believe we could make this pluggable.
use cases might be
- allow other facet types to be processed differently
- allow other modules to implement differnent url-encoding methods (right now we use pathauto to make pretty paths from term-names for example).
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | facetapi_pretty_paths_1431682_pluggability.patch | 1.62 KB | dasjo |
Comments
Comment #1
Anonymous (not verified) commentedYes, it would be great to have full control over the paths generated.
Comment #2
dasjowould love to see proposals as a text or even better by submitting patches :)
Comment #3
dasjoattached a patch as an idea.
another possibility, as discussed with mh86:
define mappers in info hook as callbacks that other modules can alter
- 1st level: per field-type (taxonomy, entity reference, ...)
- 2nd level: per facet / realm?
Comment #4
dasjocommitted pluggability.
This introduces a new ctools plugin type "coders" which allows for having different implementations for the helper functions:
-
encodePathSegment-
decodePathSegmentAlias-
decodePathSegmentValue-
prettyPathtwo coder implementation plugins are provided by default
-
FacetApiPrettyPathsCoderDefault-
FacetApiPrettyPathsCoderTaxonomycoder plugins are registered using
hook_facetapi_pretty_paths_codersand may be altered as well:hook_facetapi_pretty_paths_coders_alterfacetapi_pretty_paths_coder_callbackhandles selecting the right coder implementation for a given task. you can define different coders on a per-facet basis, seefacetapi_pretty_paths_facetapi_facet_info_alterComment #5.0
(not verified) commentedUpdated issue summary.