-
Notifications
You must be signed in to change notification settings - Fork 642
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
[3.2.1] On New Entries, Previews don't show actual preview #4554
Comments
additional info: chasing down why the New'd entry doesn't show in other query methods (see email, updated), it appears to be because there's a draftId, but no draft to match it. So perhaps the hiding is due to validation failing. However, removing the draftId from the New'd Entry's element in the database, while allowing query, doesn't fix this current issue; in fact it just causes Garnish to error, so that there's no update from edit inputs to the preview panel at all. Given these points, and that it doesn't pop out for me from skimming the 3.2.1 release code changelist that you actually intended not to use Drafts for unsaved New entries, maybe this missing draft is an unintended side effect? And then cause for this issue and the emailed further unexpected problems? |
When you first create a new entry, it starts out as an “unsaved draft”. So it is in fact a real draft; the part that is missing is that the draft doesn’t have a corresponding source entry yet. Once you click “Save entry” for the first time, the draft will lose its Unsaved drafts do in fact support previewing, at least using the core implementation. |
Ok, I just checked this out rather thoroughly, and agree with your view -- fresh new'd entries are now previewing in normal release way. Thanks much for confirming. The problem leading to this issue post was a matter of hasty twig template re-use, quite remedied. On the other aspect, lots of hours in, and I have better understanding, will get back to you on this. Part of the (cross-issues) insight problem is that though preview elements do exist, they have two kinds of general invisibility. The second and it turns out less or really non-important is that they aren't apparent in the database yet. But I'll discuss offline. Your reply here does cut yet more out of the branching. |
Description
This seems to be a new thing with 3.2.1. It's likely at least side-by-side related to CraftQL invisibility etc. problems detailed overnight in email, to do with changes in preview architecture.
Steps to reproduce
Additional info
The text was updated successfully, but these errors were encountered: