Which has access the the Page object matching the request’s URL.
And which can do things like redirecting the page (returning a 301 response) and maybe all kinds of other things.
I’m not sure developers need a helper plugin for that, especially if it means calling that plugin’s code from a snippet. That seems rather brittle.
It looks like developers could just write their own “plugin” script to do whatever they need to do. The main issue is making sure that plugin script has access to the relevant Page object. After a few tries I was able to hack this:
<?php // site/plugins/not-really-a-plugin.php
// page() returns null in this context, but we can retrieve the current path
$path = kirby()->path();
// We should have a page object, or NULL for 404 pages
$page = page( $path ? $path : c::get('home', 'home') );
if ($page) {
if ($page->status()->value == 'unpublished') {
go($page->parent()->url());
}
}
There might be ways to return a 410 Gone response and page, too.
On a single language setup this solution might be ok. On a multilanguage setup it does not work. When writing echo $path; it prints something like this:
de/not-the-same-url-for-de
The plugin has support for multilanguage setup as well.
It looks like developers could just write their own “plugin” script to do whatever they need to do.
I don’t think any browser has trouble with whitespace before the doctype. They may have trouble with non-whitespace, and probably with HTML comments, but whitespace is okay.
I would remove the whole doctype handling thing (it’s needless complexity), and just add a note to call the function before the doctype or any HTML content. This is perfectly fine in my experience:
In any case, I would love to have a global controller that is run for all pages and before the template’s controller. Like you, when I read the Kirby docs saying that controllers/site.php would only run as a fallback, I was like “damn, that’s too bad”.
is there a way to define and set new filter types? if we could we could use them as middleware before certain routes (or before all of them). Either way, I would like to be able to define new filters.
I’m not sure how all the new browsers handle it, but I’ve had issues with whitespace before the doctype a few years ago myself. Maybe the problem is not a problem anymore.
Always include one of the doctypes mentioned here as the very first thing in all of your HTML documents.
It’s not, at least since IE8 (maybe IE6-7 had issues, but I worked on CSS for those browsers too and I don’t remember this issue). Other issues you may have seen are IE 8-10 going in Compatibility mode, but that would be for other reasons (local network, intranets, X-UA-Compatible headers or lack thereof).
My biggest problem with the routes is that they run before the $page object created. Often I want to do something on the current page, redirect it or do something else depending on some field value or so. For now I’ll do these things with my plugin until something greater is built in, like the feature request issue that @lukasbestle have added.
