Skip to content

[5.x] Fix incorrect blueprint being resolved on localizations #11810

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

Draft
wants to merge 1 commit into
base: 5.x
Choose a base branch
from

Conversation

duncanmcclean
Copy link
Member

@duncanmcclean duncanmcclean commented May 21, 2025

This pull request attempts to fix an issue where the incorrect blueprint is resolved on localisations, where the collection is dated and hide: true is set on the entry blueprint.

I'm not sure that this is the final fix, but it certainly fixes it on the sites I've tested it on.

Related to support ticket #7046.

Steps to reproduce

  1. Setup a multisite, with two sites: site A & site B.
  2. Create a dated collection, setup in both sites.
  3. Configure two blueprints for the collection:
    • home (should be hidden)
    • landing_pages
  4. Create an entry in site A
    • It should use the home blueprint: blueprint: home
  5. Localise the entry into site B
  6. Then, run the following code snippet in Tinkerwell:
    use Statamic\Facades\Entry;
    use Statamic\Facades\Stache;
    
    Stache::clear();
    
    $entry = Entry::find('id-of-the-localized-entry');
    
    $entry->blueprint()->handle();
    • We expect home to be returned, because we're explicitly setting the blueprint on the origin entry.
    • However, landing_pages will be returned instead.
      • This is because it's failing to resolve the origin entry, so it's falling back to the "default" blueprint, which in our case happens to be landing_pages since the home blueprint is hidden.
        • Because its a dated collection, when BasicStore@getItem calls Entry@ getCurrentDirtyStateAttributes(), it attempts to get the entry date, which ends up calling the blueprint() method.
        • However, at this point, it's possible the origin entry hasn't been loaded into the Stache yet, so it doesn't know about the origin blueprint, so it caches the "default" blueprint.
        • This cached, default blueprint, is what ends up breaking things. This PR fixes it by clearing the blueprint cache key in Entry@hasDate.

TLDR:

  • Needs to be a multisite, with at least 2 sites.
  • Collection has to be dated.
  • Collection has to have two blueprints: one hidden, one not.
  • Entry needs to be localised into another site.
  • Origin entry should be explicitly using the hidden blueprint.
  • Need to run php artisan cache:clear before attempting to get the localization's blueprint.

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.

1 participant