Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
duncanmcclean wants to merge1 commit into5.x
base:5.x
Choose a base branch
Loading
fromorigin-blueprint

Conversation

duncanmcclean
Copy link
Member

@duncanmccleanduncanmcclean commentedMay 21, 2025
edited
Loading

This pull request attempts to fix an issue where the incorrect blueprint is resolved on localisations, where the collection is dated andhide: 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:
    useStatamic\Facades\Entry;useStatamic\Facades\Stache;Stache::clear();$entry = Entry::find('id-of-the-localized-entry');$entry->blueprint()->handle();
    • We expecthome 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 belanding_pages since thehome blueprint is hidden.
        • Because its a dated collection, whenBasicStore@getItem callsEntry@ getCurrentDirtyStateAttributes(), it attempts to get the entry date, which ends up calling theblueprint() 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 inEntry@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 runphp artisan cache:clear before attempting to get the localization's blueprint.

@PhilJ
Copy link

+1 Merging this pull request would fix the issue we have with our multi page setup. We get 404 errors on localized pages due to the wrong blueprint being loaded.

@jasonvarga
Copy link
Member

Duncan, this is still a draft. Is it waiting on something?

@duncanmcclean
Copy link
MemberAuthor

duncanmcclean commentedJul 15, 2025
edited
Loading

It works but we weren't sure if it was the "right" approach or not.

Anyways, I've marked this as ready for review. Feel free to change it if you want.

@duncanmccleanduncanmcclean marked this pull request as ready for reviewJuly 15, 2025 17:22
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

3 participants
@duncanmcclean@PhilJ@jasonvarga

[8]ページ先頭

©2009-2025 Movatter.jp