Leaderboard

This week on the core dev branch there are several new hookable methods added to the Page class. While many of them may be redundant with hooks already available on the Pages class, those on the Page class are more convenient to use in some cases, especially when it comes to using custom Page classes. It's helpful because you can hook CustomPageClass::method rather than Page::method to more easily target specific types of pages. Or you can override the methods in a custom page class, without having to hook them at all. I'll get into this with more details and examples in a future blog post that goes in-depth on using custom page classes. Here's a summary of the methods that were added with links to their API reference documentation pages: Page::addReady() Page::added() Page::addStatusReady() Page::addedStatus() Page::removeStatusReady() Page::removedStatus() Page::cloneReady() Page::cloned() Page::deleteReady() Page::deleted() Page::editReady() Page::moveReady() Page::moved() Page::renameReady() Page::renamed() Page::saveReady() Page::saved() Page::renderPage() The above is just for this week, but there's quite a bit more in 3.0.253 relative to 3.0.252, so be sure to check the last issues from ProcessWire Weekly for more details.

That will definitely be welcome, for sure! Thanks in advance.

Always wanted those on Page. Even before custom classes existed. Great addition! I think that custom classes truly need more introduction and use cases. So eagerly waiting for Ryan's upcoming blog post.

@ryan, You'd mentioned at some point that existing installs could retain the old theme and perhaps users prompted to update to the new one. At the moment if I upgrade an existing site to the dev branch, the new theme is enabled by default. This breaks any custom TinyMCE styling as the new theme overrides it. Are you planning to implement this prior to the next master version? Ideally for us, given we have several hundred sites which we update to the latest master when it is available, nothing would change for the users. We could then turn on recommending a theme upgrade on a per site basis, or if we choose to, force the upgrade on the users. Cheers, Chris

Hi, I've noticed that the base url in the OpenApi document is wrong with this configuration, e.g. "<domain>/testeapi/testeapi/api" instead of "<domain>/testeapi/api"

Hi everyone, hi @sebi, First, thanks for this module I'm discovering at this moment 🙂 I got stuck a bit with something, so I wanted to share, in case. I installed my processwire in a subfolder, as I usually do. But with your module, i got 404 with all my fetches. So i tried to modify some stuff with the .htaccess, but never managed (point 8.A). Finally, I found out that in your "router.php", you have a "getCurrentUrl()" function that is using "$_SERVER['REQUEST_URI']". Unfortunately, when using a pw in a subfolder, this "$_SERVER['REQUEST_URI']" contains the full path. So the module would never find any route. // line 177 in "Router.php" $routeInfo = $dispatcher->dispatch($httpMethod, SELF::getCurrentUrl()); // with pw installed in a subfolder, this $routeInfo return an empty array Only way I found out is to modify this $ with a hook: $wire->addHookBefore('AppApi::handleApiRequest', function (HookEvent $event) { $scriptName = $_SERVER['SCRIPT_NAME']; $scriptDir = rtrim(dirname($scriptName), '/'); // print_r( $scriptDir."*"); $uri = $_SERVER['REQUEST_URI']; if (strpos($uri, $scriptDir) === 0) { $_SERVER['REQUEST_URI'] = substr($uri, strlen($scriptDir)); } }); Maybe there is another $ you could use there ? Or maybe I missed something. Anyway, like this, my fetches finally work, and I can really start to play with all of it 🙂 Thanks again ++