PW 3.0.173 – Core updates, new hook type

[ryan]

ProcessWire 3.0.173 adds several new requested features and this post focuses on one of my favorites: the ability to hook into and handle ProcessWire URLs, independent of pages— 

https://processwire.com/blog/posts/pw-3.0.173/

[elabx]

Great addition!! Kudos to @bernhard for bringing this on board! 

[ryan]

I'm getting a look at this thread linked from the PW Weekly, where it looks like this topic has been discussed. BitPoet has an example where named arguments are in the format like "{user}" (if I understood it correctly) and I really like that. It would provide for an option to have named arguments without having to specify what would be in it... just "any valid PW page name characters". That sounds useful. I'll add support for it, in addition to the named arguments support mentioned in the blog post. We can support that without interfering with other regular expression features by having it convert that to a PCRE capture group. 

[markus_blue_tomato]

28 minutes ago, ryan said:

ProcessWire 3.0.173 adds several new requested features and this post focuses on one of my favorites: the ability to hook into and handle ProcessWire URLs, independent of pages— 

https://processwire.com/blog/posts/pw-3.0.173/

This is great!

[bernhard]

 ? ? ? ? ?

What a great addition!! Thank you Ryan!! ? 

[Robin S]

Love the new URL hooks!

The post doesn't mention what happens when a hooked URL or regex matches an existing page URL, but on testing it looks like the page URL takes precedence. That makes sense.

In the blog post there are examples where trailing slashes are present and absent, and tests seem to show that the hooked URLs work regardless of whether a trailing slash is present or absent in the requested URL. But what if you want to enforce a trailing slash or no trailing slash and redirect accordingly as per real page URLs?

[dotnetic]

Thanks. Great addition. It's like routes in Laravel. Much needed

[dotnetic]

ProcessJumplinks could be modified to use this. Don't know if @Mike Rockett is still working on v2?

 

[eelkenet]

Great addition @ryan! Quick question: will ProCache be able to cache (the result from) these URL hooks?

[adrian]

And it would be great if @David Karich could update Page Hit Counter to use it.

[LMD]

Oh my, this is excellent!

A first use case I thought of was archives (eg. blogs) filtered by date: YYYY/MM/DD

/**
 * This example merely displays back the selected date as a string, but it could be used to show date-based archives.
 * The following URLs are valid:
 * /YYYY
 * /YYYY/MM
 * /YYYY/MM/DD
 */

// Build basic date regex to eliminate very silly things (e.g. 2021/15/92)
$dateRegexY = '(year:\d{4})'; // any four digits (could be narrowed, e.g. '(19|20)\d{2}'
$dateRegexM = '(month:(0[1-9]|1[0-2]))'; // 01-09 or 10-12
$dateRegexD = '(day:(0[1-9]|[1-2][0-9]|3[0-1]))'; // 01-09, 10-29, 30-31 (will need further validation!)

// Put it together
$dateRegex = '/' . $dateRegexY . '(/' . $dateRegexM . '(/' . $dateRegexD . ')?)?';

$wire->addHook($dateRegex, function($event) {
	$date = $event->year
	. ($event->month ? '/' . $event->month : '')
	. ($event->day ? '/' . $event->day : '');

	return $date;
});

The possibilities are endless.

Edited March 6, 2021 by LMD
Forgot October existed; other fixes

[Jan Romero]

you’re missing october there ?

[bernhard]

Another showcase ?

$this->addHook('/rockgrid2/(.*)', function($event) {
  $name = trim($event->arguments(1),"/");
  $grid = $this->getGrid($name);
  if(!$grid) throw new Wire404Exception("Grid not found");
  if($event->config->ajax) $grid->json(); // send json and die()
  return $grid->debug();
});

When requested via AJAX you get gzipped json (as source for a tabulator grid), when requested in the browser you get a sortable+filterable grid of your data ? 

And tracy is always waiting for bd() calls for quick and easy debugging ? 

[LMD]

37 minutes ago, Jan Romero said:

you’re missing october there ?

I never did like October ? !

 I've fixed the code.

[StanLindsey]

@ryan great work, I love this! This can totally form part of a great API endpoint generator. Or auto allowing Ajax endpoints for getting resources. 

Is it possible to get the whole request URL in the hook handler? Incase you want to handle any number of sub routes? Or do you have to explicitly name each path segment? 

(Oh I guess the regex option enables this as per your JSON example. )

[markus-th]

Thanks for this terrific feature, I will be able to use this directly on one of the next projects as a short link for QR codes on products. 

This will save me so much work.

[ryan]

Quote

The post doesn't mention what happens when a hooked URL or regex matches an existing page URL, but on testing it looks like the page URL takes precedence. That makes sense.

@Robin S That's correct, an existing page has precedence. I'd like to make it so you can optionally override that too, but still working to identify the most efficient way. I'm trying to avoid a solution that adds the overhead of checking hooks and regular expressions for every request before identifying the page. Currently it only does that if the request doesn't end up matching a page, which adds no overhead to page rendering requests. Once the technical details are worked out, likely the solution will involve using an $wire->addHookBefore('/path/', ...) (rather than just addHook) which will receive a matched page (if there is one) and then it can decide whether to let it proceed as-is, change the Page object, or do something else. 

Quote

In the blog post there are examples where trailing slashes are present and absent, and tests seem to show that the hooked URLs work regardless of whether a trailing slash is present or absent in the requested URL. But what if you want to enforce a trailing slash or no trailing slash and redirect accordingly as per real page URLs?

That's also a technical still to work out. We could easily enforce trailing vs non-trailing slash but didn't want to do it without someone dictating that's what they want. Otherwise someone could very easily end up having every request getting 301'd without realizing it. So seemed safest just to allow either for the moment. I do plan to add a way to let you dictate what's required so that it can perform necessary redirects for you. I'm currently thinking that if the match pattern ends with a slash, it'll enforce the slash; if it doesn't, it'll enforce no-slash; and if it ends with a /? it'll allow for either. 

Quote

Quick question: will ProCache be able to cache (the result from) these URL hooks?

@eelkenet It doesn't at present since the feature was just added, but I do think it will be possible for ProCache to cache them. I've already started looking into it here. 

Quote

Is it possible to get the whole request URL in the hook handler? Incase you want to handle any number of sub routes? Or do you have to explicitly name each path segment? 

@StanLindsey The entire matched URL is always in $event->arguments(0). If it would be helpful I can also add a named argument to it, like 'url' or something, so you could do $event->arguments('url'); or just $event->url 

 

[bernhard]

Am I the only one seeing the page id indicator on all ProcessPageEdit pages since 3.0.173 ? I guess no, since it happens on the second instance I upgraded just now as well...

[adrian]

https://github.com/processwire/processwire-issues/issues/1345

[Mike Rockett]

On 3/6/2021 at 1:44 PM, dotnetic said:

ProcessJumplinks could be modified to use this. Don't know if @Mike Rockett is still working on v2?

JL2 uses FastRoute to do what's being done here, although it obviously needs to hook into the 404 process in order to work. The reason I picked FastRoute was because, at the time, I simply didn't like the approach in current v1, and wanted something a little more robust, feature reach, and fast. JL2 could use this new feature (which is a great addition to PW), though some additional work would need to be done to make the URIs transform to the regex approach being used here, which is quite different.

That aside, I'm afraid JL2 on hold, once again. Simply don't have the time to take it on right now, and doubtful that I will any time soon. In all honesty, I would be much happier if someone were to take the project over and give it new life. It's been in the pipeline for a long time now, and it's really come down to me making promises I uninentionally couldn't keep, much as I wanted to be able to. So, if anyone is able and willing to take it over, please feel free to pop me a DM.

[maxf5]

Since the update (30173) pages with active pagination are throwing a 404.

Anybody also have this issue?

[cb2004]

13 hours ago, maxf5 said:

Since the update (30173) pages with active pagination are throwing a 404.

Anybody also have this issue?

I can confirm this issue with the latest dev at time of posting (commit 6146ba4eb1fa3650a43c789a98026d7af4b5e317)

[szabesz]

cross reference: 

 

[hollyvalero]

I noticed this too in 3.0.173 and when I rolled back to 3.0.172 it went away.

[adrian]

Has anyone checked 3.0.174 to see if this is now fixed?