What does Page Paths module do?

[pogidude]

Just wondering what the Page Paths module does. Not really sure what this means in the module description

Enables page paths/urls to be queryable by selectors. Also offers potential for improved load performance. Builds an index at install (may take time on a large site)

[ryan]

This module does two things:

1. Gives you the ability to perform text matching on page paths/urls with selectors, i.e. $pages->find("path%=blahblahblah"); 

2. Adds an index of page paths in a separate table, potentially making retrieval of a page by path faster. Meaning, it can increase the performance of $pages->get("/path/to/page/"); and similar types of retrievals. 

I honestly haven't used this module all that much. Its performance benefit is theoretical and I'm not sure it's actually measurable. As a result, I'm not sure I'd necessarily install it unless you want to perform text matching on page paths. This one will probably be removed from the core in PW 3.0 and kept as a 3rd party module. 

[teppo]

I'm finding this interesting for perhaps a bit odd reason:

In the past I've had quite a few times when I had to dig data directly from MySQL. Since a page there doesn't "know" it's full URL, just it's name and the id of it's parent, a) locating a page is a bit of a hassle -- which is why I've often let page edit do that for me -- and b) getting useful page-related data (with full URLs, that is) directly with SQL queries is even more troublesome.

Sounds like this module, as a side effect, actually adds this "feature" I've been missing

 

Note: as far as I know there's no simple way to do a recursive query in MySQL without stored procedures. I'd love to be wrong on this one, but so far I haven't found any other way to do it.

[dragan]

Can you post a real-life example of such a query? What's the reason you query mySQL directly, what kind of scenarios?

[ryan]

Note: as far as I know there's no simple way to do a recursive query in MySQL without stored procedures. I'd love to be wrong on this one, but so far I haven't found any other way to do it.

The way that ProcessWire does it is to take a path, explode it to an array with "/" as the delimiter and then construct a query that joins back the pages table for every segment of the path. The longer the path, the more joins, and I suppose the more potential for overhead. It sounds potentially slow, but I've found it's actually incredibly fast. While it's nice to have those paths cached in their own table as the PagePaths module does, I haven't seen it make a measurable difference from the uncached/joined version that ProcessWire uses by default. Though if you were having to deal with large numbers of such paths in a single request, it might make a measurable difference there. There's also a lot of potential overhead with renaming or moving a lower-level page with lots of descendants, as it requires re-building the cache for all of those pages. This is the primary reason PW does it dynamically with joins rather than keeping a cache of them like in the PagePaths module. 

Can you post a real-life example of such a query? What's the reason you query mySQL directly, what kind of scenarios?

You don't query MySQL directly. I suppose you could query the pages_paths table directly if you wanted to, but that's not the point of this module. An example of a real life query would be to find all pages that have "chicken/nuggets" as part of the URL:

$pages->find("path%=chicken/nuggets"); 

[teppo]

In the past I've had quite a few times when I had to dig data directly from MySQL. Since a page there doesn't "know" it's full URL, just it's name and the id of it's parent, a) locating a page is a bit of a hassle -- which is why I've often let page edit do that for me -- and b) getting useful page-related data (with full URLs, that is) directly with SQL queries is even more troublesome.

Can you post a real-life example of such a query? What's the reason you query mySQL directly, what kind of scenarios?

Answer is long overdue, but I've mostly used this for one-time requests for pages with specific content in specific field(s), i.e. "give me a list of personnel with phone number starting with xxx / email address with domain example.com", sometimes with a twist or two (".. but only those people we mention in one or more of our news items"). Other times I've just needed a simple list of pages matching certain criteria (such as created / edited within given time frame) possibly combined with something like a list of pages they're connected to via a Page field.

This is doable via selectors and PHP, but sometimes I just prefer SQL; no need to write even the simplest of scripts or format the output myself (and when formatting, replacing, combining, calculating etc. results is needed, (My)SQL has very good tools for this.) This way I can also add any related data with a JOIN or two, export it as CSV with INTO OUTFILE.. and so on.

Most of the time it's just a personal preference, something that makes sense in my workflow and saves me a few lousy minutes of work 

Note that I've very, very rarely used this at template files or modules -- just a few times to make some common but relatively complex and memory-consuming (from PW's point of view) task faster by cutting some corners -- and it always feels like a very dirty hack. Definitely not something I'd recommend doing.

[froot]

need to dig this thread.

I have a setup where the page parents's and page parents parents's name and title are repetitive, so when filtering certain children of a specific page, I can never just filter for their parent's name or title, nor for their parent's parent name or title.

Long story short, in order to uniquely identify a page, I would need something better than to filter by id, because that one is never apparent.

So I tried with filtering "path" "contains", but obviously I need to install this PagePaths module as it says below the filter options. But that module is nowhere to be found… 

What to do? 

[bernhard]

PagePaths is a core module, you just need to go to Modules > Core and click on "install" ?