Hi, I'm working with the Search Api Sorts module, but the sort URLs do not use the pretty facet path (the have the old ?f[0]= format). I am on a pretty path, like search/category/Backpack/.

The $_GET on that page outputs:

Array
(
    [q] => search
    [f] => Array
        (
            [0] => categories%3Aname:Backpack
        )

)

So the question is, how do I turn this $_GET data into a pretty path? So I can use it in my Search Api Sorts links.

CommentFileSizeAuthor
#11 1661552-11.patch841 bytesAnonymous (not verified)
#7 1661552_facetapi_pretty_paths_get_path_from_any_module.patch1.13 KBdasjo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

This works for my special case

  // Pretty facet path trick
  $path = $_GET['q'];
  if (module_exists('facetapi_pretty_paths')) {
    $path = ltrim(parse_url(request_uri(), PHP_URL_PATH), '/');    
    unset($_GET['f']);
  }

But of course, if someone knows a beter way to integrate Pretty Paths with my Search Api Sorts extension, I'm all ears

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

this should be the same problem as with #1529692: Add views pager support

i'd be happy to better support such scenarios, where urls aren't directly generated by the facet api, but i don't really know how to handle this in a generic way...

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Active » Fixed

I think $_REQUEST['q'] is easier than what I posted in #1.
Anytime you need the pretty path, just do:

  $path = $_GET['q'];
  if (module_exists('facetapi_pretty_paths')) {
    $path = $_REQUEST['q'];

    // optionally unset the query filter index 'f' 
    unset($_GET['f']);
  }
Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Active

For some quirky reason, $_REQUEST can be empty on default PHP installation, so I would not use it in Drupal code:
http://stackoverflow.com/questions/5701588/why-is-request-empty

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

morningtime, what about converting your search_api_x modules to facetapi_x? so they work on a more general level + you should get pretty paths working for free

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

what about converting your search_api_x modules to facetapi_x?

As soon as I have time for it...

you should get pretty paths working for free

How is this possible if there is no way/function to get the pretty paths from outside the pretty paths extension? My modules of course already are based on facetapi anyway, and there is simply no function to get the active pretty facets path. $_REQUEST['q'] has it, but $_REQUEST is not available on all PHP installations so I avoid using it.

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented
Title: How to 'get' pretty path on any page from any module? » Get pretty path on any page from any module
Category: support » task
Status: Active » Needs review
FileSize
1661552_facetapi_pretty_paths_get_path_from_any_module.patch1.13 KB

ok, i might have overseen something.

what do you think about the attached patch?

similarly to #1717424: Quickest way to find 'pretty path alias' setting? you should be able to access FacetapiUrlProcessorPrettyPaths::getFullPath()

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

does this help morningtime? if we need such functionality i'd like to get it in before doing a beta release

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Yes it's very usefull to store the original $_GET[q] somewhere. I would be able to use this function in my extensions. Please apply it to a beta release.
Thanks.

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented
Status: Needs review » Fixed

ok, committed: http://drupalcode.org/project/facetapi_pretty_paths.git/commit/7e466c2

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Fixed » Needs review
FileSize
1661552-11.patch841 bytes

I'm trying to get this to work, but here's some problems.

Approach 1
$path = FacetapiUrlProcessorPrettyPaths::getFullPath();
Fails because FacetapiUrlProcessorPrettyPaths is not static.

Approach 2

$pretty = new FacetapiUrlProcessorPrettyPaths;
$path = $pretty->getFullPath();

Fails with Recoverable fatal error: Argument 1 passed to FacetapiUrlProcessorPrettyPaths::__construct() must be an instance of FacetapiAdapter, none given, called in

So to do it correctly, it actually needs to be done like this:

static $fullPath = FALSE:

...

  public static function getFullPath() {
    return empty(self::$fullPath) ? $_GET['q'] : self::$fullPath;
  }

Notice the test whether empty($fullPath) because in that case $_GET['q'] was not yet altered and $fullPath is still NULL.

Attached a working patch to allow the use of $path = FacetapiUrlProcessorPrettyPaths::getFullPath(); from anywhere in Drupal module code, with always correct output.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs review » Needs work

...oops, no I'm wrong, my patch from #11 also does not work. It doesn't pass the correct path at all.
I still have no way of getting the correct path, other than:

$path = ltrim(parse_url(request_uri(), PHP_URL_PATH), '/');
dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

hi morningtime,

you can't access the fullPath in a static way.

my understanding is that facetapi is conceptionally built to support multiple searches. but to be honest i haven't tried that with pretty paths at all and i guess it doesn't work at the moment.

as stated earlier, we have discussed some ways to access and create a FacetapiUrlProcessorPrettyPaths in #1717424: Quickest way to find 'pretty path alias' setting?. does that help?

DYdave’s picture

DYdave CreditAttribution: DYdave commented

Hi dasjo,

Unfortunately, this doesn't really help and we're still stuck at search_api_sorts, with the latest dev being buggy if Facetapi pretty path is installed.
http://drupal.org/node/1741434#comment-6451916

Would you possibly have any recommendations on potential solutions or workarounds for that?

Perhaps we would have to turn ourselves to facetapi or even search_api for that?
I haven't investigated that far yet, but I would greatly appreciate if you could share your thoughts on this.

Any feedback on this would be highly appreciated.
Thanks!

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented
Status: Needs work » Needs review

hi DYdave,

there have been several requests on how to access the FacetapiUrlProcessorPrettyPaths in order to retrieve its settings or to get the full query path. i'll try to answer this in a more reusable way:

FacetapiUrlProcessorPrettyPaths is a specialization of FacetapiUrlProcessor and does attach to FacetapiAdapter.

you can access getFullPath from an instance of FacetapiUrlProcessorPrettyPaths. you can't access it in a static way as of my comment in #13.

you will always need FacetapiAdapter, as this is what FacetapiUrlProcessorPrettyPaths attaches to. the following code example should be generic enough to implement in other contrib modules that want to integrate with pretty paths.

// Get the facet api adapter by the machine readable name of searcher.
FacetapiAdapter $adapter = facetapi_adapter_load('my_searcher');
// Get the url processor and check if it uses pretty paths.
$processor = $adapter->getUrlProcessor();
if ($urlProcessor instanceof FacetapiUrlProcessorPrettyPaths) {
  // Retrieve the full path from the url processor.
  $fullPath = $urlProcessor->getFullPath();
}

thanks for testing, please post your findings and feel free to ask any follow up questions.

DYdave’s picture

DYdave CreditAttribution: DYdave commented

Thanks a lot dasjo,

It's working great in the search_api_sorts module, I have just quickly tested on my localhost based on the previous issues I was following for this module: language prefix + localhost folder problems in the path and pretty much this seems to have fixed it.

I'll keep working in the other tracker on a proper solution for the concerned tickets. I guess we're going to think about how to make the searcher perhaps configurable through the backend, but all this are different discussions.

As a feedback, I used a version very close to the code you provided:
(really almost copy/pasted, thanks very much)

// Get the facet api adapter by the machine readable name of searcher.
$adapter = facetapi_adapter_load('search_api@default_node_index');
// Get the url processor and check if it uses pretty paths.
$urlProcessor = $adapter->getUrlProcessor();
if ($urlProcessor instanceof FacetapiUrlProcessorPrettyPaths) {
  // Retrieve the full path from the url processor.
  $path = $urlProcessor->getFullPath();
}

In my case it's in search_api_sorts.module line 162 on 7.x-1.2+1-dev, and for more details, this is the issue that's been bugging us:
http://drupal.org/node/1741434#comment-6451916
We'll keep on working on the patch and discussing over there if there is anything else stopping us.

Thanks again for your help guys, we'll keep you posted if anything else comes up.

DYdave’s picture

DYdave CreditAttribution: DYdave commented
Status: Needs review » Reviewed & tested by the community

Forgot to update status.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Thanks DYdave! I will have look tomorrow, see if we can finally fix our issue!

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented
Status: Reviewed & tested by the community » Fixed

the original issue was already fixed in #10.

then it turned more in a support request which has been answered in #15.

also see http://drupal.org/node/1741434#comment-6509390

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

(not verified) CreditAttribution: commented
Issue summary: View changes

slash