Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Per #3027653-51: Allow block and layout plugins to determine if they are being previewed, block and layout templates should be provided with a variable, "in_preview", to inform the templates whether they're being rendered in preview mode (TRUE) or regularly (FALSE).
Proposed resolution
Modify template_preprocess_HOOK in where necessary to add the "in_preview" template variable.
User interface changes
None.
API changes
None.
Data model changes
None.
Issue fork drupal-3273317
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #5
clayfreemanAside from the small bit of key reordering I did, this looks RTBC to me!
Comment #6
tim.plunkett+1, thanks @clayfreeman and @larowlan. Glad we didn't need a getter after all
Comment #7
larowlanAdded a change record
Comment #8
clayfreemanI actually didn't realize that it would be easy to implement this for block templates also; setting back to Needs Work, as I think it will be needed by #3137995: Can't manage Status Messages block in Layout Builder and it's better scoped to happen in this issue.
Comment #9
clayfreemanI will need to follow-up on this commit with a test case, but I primarily just need to know that existing tests pass for now. Also adjusting issue title and description to match.
Comment #10
clayfreemanComment #11
clayfreemanI believe this should be good for additional review on the block stuff that I added. I also updated the change record with the new information.
I noticed there may be an opportunity to combine the layout template test with the one that was added in #3027653: Allow block and layout plugins to determine if they are being previewed, but I don't know if it's worth the effort since it's already written and working as intended.
Comment #12
clayfreemanMost recent commit adds a bunch of lines documenting the availability of the new
in_previewvariable. Not sure if this is required or desireable by maintainers, but should be easy enough to revert if not. (I've never done this before, so I'm not sure what the general preference is for this type of change.)Comment #13
danflanagan8I'm not a maintainer by any means, but I think this is a new property worth advertising! Of course I was the one who requested the change. :)
I also manually tested the code and it works great! I used it to clean up a contrib module of mine that used a horrible hack to change the layout template during preview. I was able to change
{% if content.background.layout_builder_add_block %}to
{% if in_preview %}I swear I couldn't figure out a better way before. This new property is incredible. Can't wait til I can actually commit this change.
I also used in_preview in a block template to do a POC fix #3027653: Allow block and layout plugins to determine if they are being previewed, which was @clayfreeman's idea. Worked great for me there.
I think the test coverage is appropriate. I'm ready to RTBC when the latest tests pass. I'm a little worried my requests to update the template docs is going to cause tests related to template hashes to fail. We'll see!
Comment #14
clayfreemanThe test did fail on some sort of hashing mechanism which I'm not too familiar with. The additional template documentation changes, at least as I perceive them, have a pretty wide scope. I'm not sure if the changes are worth making, especially since the functionality is documented in the block template base hook.
Perhaps a maintainer could weigh in as to whether I should revert my last commit or seek a fix for the hash changes.
Comment #15
larowlanI think the docs changes are worthwhile
Comment #16
danflanagan8Thanks for gutting out these changes to the docs and hashes, @clayfreeman. I think it's worth it to make it easier to stumble upon this new variable.
That fail was a random quickedit thing, so let's consider this green.
Looks awesome. I tested manually as described in #13. RTBC.
Can't wait to start using this!
Comment #17
quietone CreditAttribution: quietone at PreviousNext commentedSorry folks, this will need to be on 10.0.x now and the MRs is no longer mergeable so tests are not running. It would be good to add an MR for 9.5.x.
Comment #18
clayfreemanAssuming RTBC can stick on this since it was just a reroll, though feel free to revert if that's not the case.
ETA: Noting for the record that the diff from MR !2053 applies cleanly to 9.5.x, so I'm not sure there's any value in creating a separate MR.
Comment #19
alexpottCommitted and pushed 6483b2997a to 10.1.x and 1b3ec547f2 to 10.0.x. Thanks!
Committed 00243d3 and pushed to 9.5.x. Thanks!
I rerolled the patch for 10.x - removing all the changes to files that no longer exist. I backported this to 9.5.x because it is an addition will no BC implications and this has been RTBC since May 2022.