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.

Comments

morningtime’s picture

This works for my special case

<?php
 
 
// 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

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...

morningtime’s picture

Status:Active» Fixed

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

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

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

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

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

morningtime’s picture

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

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
StatusFileSize
new1.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

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

morningtime’s picture

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

morningtime’s picture

Status:Fixed» Needs review
StatusFileSize
new841 bytes

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

Approach 1

<?php
 $path
= FacetapiUrlProcessorPrettyPaths::getFullPath();
?>

Fails because FacetapiUrlProcessorPrettyPaths is not static.

Approach 2

<?php
 
$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:

<?php
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.

morningtime’s picture

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:

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

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

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

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.

<?php
// 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

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

Status:Needs review» Reviewed & tested by the community

Forgot to update status.

morningtime’s picture

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

dasjo’s picture

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

Issue summary:View changes

slash