Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.x] Ensure unique blueprint instance #10353

Open
wants to merge 2 commits into
base: 5.x
Choose a base branch
from

Conversation

aerni
Copy link
Contributor

@aerni aerni commented Jun 21, 2024

This PR allows to programmatically add fields to an entry's blueprint without also altering the fields of other entries that use the same blueprint.

I've come across this issue on a multisite, where I need to extend the blueprint for only one localization. Consider this simplified event listener:

<?php

namespace App\Listeners;

use Statamic\Events\EntryBlueprintFound;

class ExtendEntryBlueprint
{
    public function handle(EntryBlueprintFound $event): void
    {
        if ($event->entry?->locale() !== 'german') {
            return;
        }

        $event->blueprint->ensureField('description', [
            'type' => 'text',
            'display' => 'Description',
        ]);

        ray($event->blueprint);
    }
}

While the listener would only add the description field when it encounters a German entry, the fields would still be added to other entries that share the same blueprint because we are dealing with the same blueprint instance.

A simple way to reproduce this issue on a fresh installation:

  1. Create a multisite and add german as the second site
  2. Add the german site to the pages collection
  3. Localize the Home page

The EntryBlueprintFound event is triggered for the german localization and its origin. Without this PR, the origin also ends up with the ensured description field.

@aerni aerni changed the title Ensure unique blueprint instance [5.x] Ensure unique blueprint instance Jun 21, 2024
@aerni
Copy link
Contributor Author

aerni commented Jun 21, 2024

There are quite a few more tests failing because they all use assertSame and thus assert that the object instance is the same. So this PR might result in a minor breaking change and unexpected behavior for users that relied on it to work the way it works now. Though, I don't think it should cause any issues.

Please let me know what you think, and I'll fix the tests if you're up for merging this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant