Leaderboard

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/

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

@ryan - I just discovered that findRaw() won't return the "url" field. I suppose that is to be expected given that it's not a DB stored field, but rather calculated at runtime, but it does still somewhat limit the functionality of findRaw in LOTS of useful situations. Do you think it would make sense to support this, or would it just slows things down too much? The other thing is I am wondering if you'd consider an option to return a standard PHP object rather than an array? It would make it so much easier to switch between find() and findRaw() Thanks.

Use the type "markup", which will accept HTML eg: 'name' => 'docs', 'label' => 'Docs', 'type' => 'markup', 'value' => '<strong>TEST</strong>'

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

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 ?

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.

Excited to be learning REACT/NextJS. It's so 'on-trend'. I can double my hourly rate, take 3x as long to deliver a website with 2/3 of the Google Lighthouse results and who doesn't love the spinner while the component content loads? Doing a well optimised PW site with minimal JS, fast page loads, accessibility, SEO and more built in is so old hat. And even better, with JS frontends, the code maintenance goes on and on. No end to revenue possibilities. FML

Just an observation, thanks to Tracy's Selector Queries (Debug Info panel), both the has() and getID() methods use the same query.

You mean like this? Use this very hackish hook and replace the word “tabcontents” with the name of your FieldsetPage field: $this->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $event->return = $event->return . '<script>document.querySelector("#wrap_Inputfield_tabcontents > label.InputfieldHeader").remove();</script>'; }); Might want to only apply it to certain templates, too, but whatever. Sorry, I couldn’t find an easy way to remove the element from the output directly, but this should be fine.

I never did like October ? ! I've fixed the code.

you’re missing october there ?

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

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

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

This is great!

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.

I only get an empty TextformatterVideoEmbed Tag rendered on a https/vimeo.com/xxx link. Is there any fix for that already?

A great module in need of a couple of issues fixed and pull requests actioned to make it work going forward.

Just gave it a try and this is the response I get from YouTube when not using HTTPS: { "error": { "code": 403, "message": "SSL is required to perform this operation.", "status": "PERMISSION_DENIED" } } Happens on 3.0.148 as well as 3.0.165. The way TextformatterVideoEmbed is set is that if it doesn't get a proper response (one with "html" key) it won't do anything, so this is technically expected behaviour. That being said, I don't see any reason why this module should use the HTTP protocol even if the site itself does, and since YouTube no longer seems to allow that it's definitely not the right thing to do. I've opened an issue for this for @ryan: https://github.com/ryancramerdesign/TextformatterVideoEmbed/issues/16 ?