Using the Registry from config.php

I’m working on a couple of additions to my Architect plugin, and had hoped to offer a few “optional extras” to developers, within the Readme.

Specifically, I want each person who uses the plugin to have all the basic functionality out of the box, and then be able to add a few Page Methods by themselves. I’d prefer those extra methods not be baked in, because they might collide with field names and make bugs harder to track down.

Anyway, in config.php, I tried to use the Registry to set the following:

kirby()->set('page::method', 'architect', function($page) {
  return Architect::blueprint($page->intendedTemplate());
});

This causes the method registry to blow up on line 63, saying that the page class doesn’t exist, and therefore can’t be extended. Including this in a plugin works as expected.

Important: the legacy strategy for adding page methods also blows up, but (as expected) right in the config file. The page class is still not available.

page::$methods['architect'] = function($page) {
  return Architect::blueprint($page->intendedTemplate());
};

Is there anything special about the way the page class is loaded that prevents it from being available in config.php, unlike other Registry options? I can set a route there, as expected.

Tips?

I think I may have come to a realization, independently…

It seems like these method-adding mechanisms have never been available within config.php, and I’d just imagined handling it this way.

Perhaps the Readme’s recommendation needs to be to add a second plugin file like architect-customizations.php and provide additional methods in there, as everything works swimmingly once inside the context of a plugin.

I’d interpreted “The best place to do this is in a plugin file: /site/plugins/page-methods.php” as an organizational suggestion, and not a statement about the limits of where core objects can be extended.

:wink:

1 Like

How about this? Just an idea.

kirby()->set('page::method', 'architect', function($page) {
  return Architect::blueprint(kirby()->page()->intendedTemplate());
});

I think the Page class is not loaded when Kirby includes the config files because, depending on your settings, it will have to load either the single-language or the multilang implementation of that class. Kirby loads a bunch of classes, including PageAbstract, but not the Page class at this point.

Solutions for what you want to do:

  1. Do it in a file in site/plugins.
  2. It might be possible to let users define a config entry and add to page methods in your plugin.

Second option may look like:

c::set('architect.page.methods', [
  'architect' => function($page) {
    return Architect::blueprint($page->intendedTemplate());
  },
  'othermethod' => function($page) {
    …
  }
]);

But maybe that’s overly verbose and it would be better to introduce your users to how page methods can be registered, which is a skill they can apply for other needs.

1 Like

I don’t think the $page object or page() are loaded correctly as early as in the config.php?

I would add it as a plugin because of the way Kirby works. I’ve made a plugin myself that require an additional plugin for it to work:

https://github.com/jenstornell/kirby-recaptcha

2. Add your PHP callback as a plugin

What @fvsch wrote is correct. It’s not just the current $page that’s missing, but the whole Page class.
Registering methods will only work from plugins, not from the config.php.

2 Likes

Very insightful answer— makes total sense.

Love this sentiment:

…it would be better to introduce your users to how page methods can be registered, which is a skill they can apply for other needs.

:vulcan: