- Issue created by @mandclu
- First commit to issue fork.
- @dieterholvoet opened merge request.
- Status changed to Needs review
over 1 year ago 5:30pm 7 August 2023 - Status changed to Needs work
about 1 year ago 8:45am 8 November 2023 So the fix doesn't work if I do this:
- Add new content
- In the iframe settings, disable
Open preview by default
- Close and reload the page
- Type anything in the title and click the preview button
The page is empty.
Okay, so this is weird. After the first time, it works correctly. Narrowed it down to being connected to the twig cache in some way, every time I flush it, the problem shows up.
- 🇺🇸United States cosmicdreams Minneapolis/St. Paul
Thanks for the error report @admirlju I'll try to reproduce and analyze.
So I've been digging a bit more. I'm not yet sure, but a few things I noticed, might help debug further.
So I'm looking at the module file, and how the iframe and preview compiling is added in
same_page_preview_form_node_form_alter
.
Noticed one thing, when the preview button is clicked but the pane is not open, this hook is called twice, the first time when it opens the pane, the UUID of the preview is wrong, and the second call uses the correct UUID and then displays the data. Now the weird part here, the UUID in$route_parameters
in the first run does not match the UUID loaded in the pane, the second time it does match, so this first run never shows the correct preview node.So knowing this I went to check the
PreviewPaneController.php
, so the controller for the pane. An interesting thing happens here if I put a breakpoint, at any point, in the view method. It delays how long the pane needs to open, and this causes this second hook run to not update the preview.So what I'm assuming happens, after clearing the twig cache, the time to build the preview page is longer and this second call happens before the pane preview page is displayed. However, when the node cache is built, the pane display is fast enough for the second call to refresh the page.
Also, elements that update the preview on blur, open a preview pane that is empty and use the wrong UUID. So this is a bigger problem in general.
- 🇺🇸United States cosmicdreams Minneapolis/St. Paul
I think..... Maybe we've already applied the fix that is in #11. Well, most of it. We aren't (in code) defaulting the display to the 'full' display mode. But doing so might be dangerous because it is possible to get rid of the 'full' display mode. So hard coding that feels dangerous.
Can you retest? Is this still an issue?
- Status changed to Postponed: needs info
28 days ago 4:24pm 20 November 2024 - 🇧🇪Belgium dieterholvoet Brussels
In what release would this issue have been fixed? I'm trying to reproduce it on dev-2.1.x and on 2.1.4, but I can't seem to reproduce it on either version. I tried the 'Steps to reproduce' in the issue description and the steps described in #6.
- 🇫🇮Finland sokru
This can be reproduced easily when creating a new content with Drupal core 11.x and 2.1.4/latest dev commit. I tried reverting 🐛 Preview only works when editing content, not creating Fixed but it didn't help. Attached a screen recording.