You can’t have one closure for several Kirby hooks because func_get_args()
doesn’t work unless you explicitly specify the arguments in the function definition.
Also, I’d argue that having this name-based approach is not so useful. Instead of looking up the argument position, I now have to look up the argument name.
Except this comes with a drawback. For example, in an :after
hook, I want to call the content()
method of the new object. It can be a Page, Site, File, whatever. With the current setup, it’s crappy because I need to have all three arguments ($newPage
, $newSite
, $newFile
) and have separate logic for them. In the other case, I simply have an argument $new
, make sure it’s first, and that’s it. If I want to distinguish between Page and Site, I can use is_a()
as usual.
I think this feature adds more confusion (especially when it comes to func_get_args()
) than convenience. Kirby would be better off without it and will have a few lines of code less. Or it could simply offload this complicated arguments system in the $event
object that is passed. Then, you could use $event->newPage()
or $event->newSite()
and $event->newObject()
when you don’t care about the type of object.
The arguments are already accessible from the $event
object. This is one of the main reasons why we added the $event
object recently. Please let me know in case it doesn’t suit your needs.
@Hristiyan Dodov Does $event->arguments()
( https://getkirby.com/docs/reference/objects/cms/event/arguments) solve your use case? I would close this then.