Modifying the blueprint in EntryBlueprintFound not working properly

[simonerd]

Bug description

Modifying the blueprint in the EntryBlueprintFound event doesn't seem to have any effect. The docs state:

"You may modify the blueprint here and it will be reflected in the publish form (and wherever else a blueprint is used)".

However, I find that nothing seems to change in my case.

Our use case would be to utilize this event to use one blueprint in multiple collections. We're trying to separate otherwise identical content into multiple collections for performance, permission and usability reasons. We want to avoid copy-pasting blueprint files. Fieldsets don't include tabs and sections and our relevant blueprint is a bit more complex, so we don't have many (native) options.

Example
Assume a fresh Statamic 5 install. We have a pages collection with a page blueprint and create a subpages collection, with a subpage blueprint. What we actually want to achieve is that the latter should use the same blueprint as the former, so collections.pages.page instead of collections.subpages.subpage. I can use the event to hook into the blueprint discovery process and adjust accordingly:

Event::listen(EntryBlueprintFound::class, function ($event) {
    // simplified
    if ($event->blueprint->handle() === 'subpage') {
        $event->blueprint = Blueprint::find('collections.pages.page');
    }
});

However, modifying $event->blueprint does not have any effect.

Expected behaviour: Opening or creating an entry in the subpages collection should use the pages.page blueprint.

Actual behaviour: Opening or creating an entry in the subpages collection uses the subpages.subpage blueprint.

I also tested a less-offensive thing than overwriting the blueprint:

$event->blueprint->setHidden(true);

Expected behaviour: When opening the collection index the (relevant) blueprint should not be available in the "Create Entry" menu.

Actual behaviour: The (relevant) blueprint is still available in the "Create Entry" menu.

How to reproduce

See in description above.

Logs

Environment

Environment
Application Name: Statamic
Laravel Version: 12.19.3
PHP Version: 8.3.8
Composer Version: 2.8.9
Environment: local
Debug Mode: ENABLED
URL: statamic5.test
Maintenance Mode: OFF
Timezone: UTC
Locale: en

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: file
Database: sqlite
Logs: stack / single
Mail: log
Queue: sync
Session: file

Storage
public/storage: NOT LINKED

Statamic
Addons: 1
Sites: 1
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 5.58.1 Solo

Installation

Fresh statamic/statamic site via CLI

Additional details

No response

[simonerd]

When looking into the relevant code for our use case, there doesn't seem to be any logic to actually modify the blueprint. I'm not familiar with how Laravel events work under the hood, but when dumping $blueprint after the event was dispatched it's still the same as before:

// Statamic\Entries\Entry::blueprint(), L179
// […]
Blink::put($key, $blueprint);

EntryBlueprintFound::dispatch($blueprint, $this);

return $blueprint;

I achieved what I wanted by hacking this around the event dispatcher:

First, in my event listener:

Event::listen(EntryBlueprintFound::class, function ($event) {
    if ($event->blueprint->handle() === 'subpage') {
        $event->blueprint = Blueprint::find('collections.pages.page');
    }

    // NEW: return the event
    return $event;
});

In Entry::blueprint():

// NEW: process the return values of the listeners
$returnedBlueprint = collect(EntryBlueprintFound::dispatch($blueprint, $this))
->filter()
->last()?
->blueprint;

if ($returnedBlueprint instanceof Blueprint) {
    $blueprint = $returnedBlueprint;
}

Blink::put($key, $blueprint);

return $blueprint;

Don't quite know what to think about it though.

Happy to create a PR with changes if you could provide a bit of feedback/input where to go.

[duncanmcclean]

The most common use case for the EntryBlueprintField event is for "ensuring" fields, like this:

$event->blueprint->ensureField('price', [
    'type' => 'integer',
    'prepend' => '£',
]);

Just to rule out any other issues at play, can you try that and see if it works?

[simonerd]

@duncanmcclean

Just to rule out any other issues at play, can you try that and see if it works?

That works perfectly fine 👍🏻

[duncanmcclean]

Instead of replacing the actual blueprint instance, are you able to update the contents of the blueprint?

$event->blueprint->setContents($yourOtherBlueprint->contents());

[simonerd]

Brilliant! Thanks @duncanmcclean, that works! 🥳

As far as I can see from my test, this would fully resolve my issue. So for me this could be closed – but probably the docs should be updated accordingly. Happy to create a PR for this next week, if that helps, so you can continue to focus on v6 😉😁

[duncanmcclean]

Great!

So for me this could be closed – but probably the docs should be updated accordingly. Happy to create a PR for this next week, if that helps, so you can continue to focus on v6 😉😁

If you can, that'd be awesome! Thanks 🙂

[infabo]

The most common use case for the EntryBlueprintField event is for "ensuring" fields, like this:

$event->blueprint->ensureField('price', [
'type' => 'integer',
'prepend' => '£',
]);

Just to rule out any other issues at play, can you try that and see if it works?

Does this actually work? I have tried something basic like

<?php

namespace App\Listeners;

use Statamic\Events\EntryBlueprintFound;

class ModifyDoughBlueprint
{
    public function handle(EntryBlueprintFound $event): void
    {
        $event->blueprint->ensureField('title', [
            'type' => 'integer',
            'prepend' => '£',
        ]);
    }
}

And it is not reflected in the form. Title field is still a text field and has no prepended pound symbol. EntryBlueprintFound listener is executed though.