Hi,

I'm using search_api/facet_api in my current project and I moved from using facet api pretty path to my own "pretty path" module that uses hook_url_inbound/outbound_alter hooks instead of a facet_api plugin.

I found this solution much better because it doesn't depend on the facetapi plugin being called and so it is available everywhere (pager, custom links). You just add a link setting the 'f' variable and the rewriter will provide a pretty path (like "q" works elsewhere in drupal).

I bet there are good reasons for facetapi to provide an extension point for plugins to deal with the urls, but I'm probably missing them, so I'm opening this issue to understand the rationale behind using a pecific facetapi plugin instead of the standard drupal hooks.

PS: maybe I should have opened this in the facetapi project?

Comments

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented
Project: Facet API Pretty Paths » Facet API

hi bago,

thanks for your input.

personally, i like the fact that we are integrating with facet api in order to have pretty path logic being executed only when appropriate. as you stated this doesn't work for pager links at the moment, so i'm open to discussing this further.

as suggested, i'm moving this to the facet api queue in order to get feedback from cpliakas or other people with insights on the facet api on that matter.

cpliakas’s picture

cpliakas commented

Hi guys.

I am in favor of moving away from a plugin if it would be a better developer experience, but I see a lot of challenges and assumptions that would be required to do this in hook_url_outbound_alter() in a way that scales beyond a single search page with a single backend. I am sure all the benefits and flexibility of the plugin could be coded in another way around this hook, but I found the plugin architecture to be an easier way to do this while being consistent with how all other systems in Facet API work.

It is also important to note that "f" is not a constant. Also, Facet API always uses a URL Processor plugin to construct the initial links, so hook_url_outbound_alter() will always be overriding things as opposed to building them correctly up front. Just a couple of things to consider as we proceed.

Thanks,
Chris

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

bago, i have found a way to avoid altering the query path in facetapi pretty paths. that would be another take on the problem: #1777714: Don't modify the query path

what do you think?

bago’s picture

bago commented

dasjo, I think that the issue you're linking is not related with my question. If I understand your fixes, there, it does not fixes views pagination, nor it fixes linkability to filter pages using url().

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

bago, yes it does fix views pagination, please try

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

... in a way that scales beyond a single search page with a single backend

actually, i haven't really thought of that with the current implementation of facetapi pretty paths. would be interesting how and if at all we can handle such situations

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented
Issue summary: View changes

reference the facetapi project