Out of memory when extending blueprint with type:default

[buergi]

I noticed that I was not able to open /admin/plugins/flex-objects in browser (just white page appears), the log showed error messages like the following

[27-Feb-2024 18:30:40 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 40960 bytes) in /var/www/html/vendor/filp/whoops/src/Whoops/Util/Misc.php on line 50
[27-Feb-2024 18:31:03 Europe/Berlin] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/vendor/rockettheme/toolbox/ResourceLocator/src/UniformResourceLocator.php on line 305

Even increasing the memory_limit did not change anything. I localized the problem to be a custom addon which defined a blueprint called default.yaml with this content (I removed the unimportant part)

title: Default
'@extends':
    type:default

When I change the type to defaulx or something else everything works.
I'm actually not having any idea what I'm talking about, and what exactly is going on here, maybe I shouldn't have defined the blueprint like that. But maybe you can decide if this is a user error on my side or if there is something broken.

[leotiger]

Having the same problem here. While searching for reasons why the configuration page of flex-objects does not open once Studioeditor is activated, I found this issue and bingo, perfectly valid blueprint files which extend default cause an error in flex-objects. If I change to defaultx everything runs smoothly.

[leotiger]

In my case the problem arises when the blueprint that extends default blueprint is name default as well. Simply renaming the blueprint to something else, e.g. plugin name resolves the issue.

[leotiger]

Another approach to fix the problem is to provide a full fledged default.yaml blueprint without extending it. Depends on what you need.

[leotiger]

Don't know if there's some documentation on how to inheritate blueprints, fact is, what I've stated before was a partial fix as the inheritance chain for blueprints got interrupted by this approach. Let's expose my findings for the inheritance chain for blueprints in a list:

1. System
2. admin/flex
3. other plugins
4. themes

The fix I exposed simply established a new common ancestor but this didn't make it to theme blueprints, bad, you could say no extend possible, let's not expose it in a biological way...

What's necessary is to copy the blueprint folder structure from system / admin which means that you have to place your blueprints for pages inside of your plugin the following way:

system inheritance if you create this folder structure inside your plugin

• blueprints
• • pages
• • • default.yaml

admin inheritance if you create this folder structure inside your plugin

• blueprints
• • admin
• • • pages
• • • • raw.yaml

From admin you have to inherit raw or others and theme blueprints extending default won't make it into your configuration.

If it's not pages, do it the same way for other inheritances...

Now your default.yaml can extend without problems and will arrive perfectly at any theme blueprint which may override things again. One thing to mention so, don't include a title for the blueprint itself if you extend, anything else can be extended, overwritten, whatsoever, simply don't add title: PLUGIN_ADMIN.DEFAULT to your blueprint.

This way you can keep extending changes at a minimum, that's what extending is all about :-).

One more thing: if your blueprint folder structure follows the system blueprint folder structure there's no need to register your blueprints via hooks. GRAV does this automatically for you. Probably this was different some 8 years ago, things are changing.

What's important, this should make it into the core documentation for GRAV, probably/hopefully it's already there...

Related: Approval of StudioEditor