-
Notifications
You must be signed in to change notification settings - Fork 630
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
Entry Edit changed warnings appear to not function under Live Preview #3092
Comments
Thanks, fixed for the next release. Unfortunately it’s not easy to determine whether anything has changed when Live Preview is open, as all of the Live Preview fields get moved to a separate form than the one Craft checks when unloading the page. So now Craft will just always ask if really want to leave the page, if Live Preview is active. |
Tested and does the job, thanks, Brandon. Also must say, this move certainly clears what you'll understand was my underlying question: what happens when the Live Preview frame is no longer always showing a Twig presentation, and in particular may have navigated off the initially presented preview page. What you did is especially safe for points one might see there. Even so, I kind of wonder why it's necessary? I'm probably getting dense after one more quasi-allnighter, but not yet connecting why Craft wouldn't always be watching the initial and then left-hand, initiating frame form, for changes? A smile, as feel I'm about to learn there are reasons :) Which may be good to understand, among the other subtleties I'm chasing down getting present work as smooth as possible in what a shakedown on a client's proto-site helped see..... cheers |
When the page first loads, Craft’s JS serializes the form POST data in its initial state. On page unload, it compares the current serialized POST data to the load-time record. If they’re different, it shows the warning message. When Live Preview opens, it copies a portion of the form into a separate form within its editor pane. (Which fields, exactly, depends on the element type’s implementation.) Any changes to the content within that form are only applied back to the main form when LP is closed. So for the duration, as far as Craft’s unload comparator is concerned, nothing is changing until LP has closed. |
Brandon, thank you. I keep thinking I get this, even at this hour -- and then think again. In truth I don't guess well why you do it, but I fully trust there's a good reason. Not one of several mind has blinked and then proposed. I'll have to scope out the code, after I close the final tricky bits of, indeed, the JS side of this current long project. You've given me the pattern to look for to do that scoping in reasonable time. I keep thinking I have those tricky bits patiently worked down to one, and I'm up still because of course I think I'm just at the moment going to corral the final one. It might be true, for this shakedown site . In any case, @angrybrad is ever more correct about his weighing scales of the tens and nineties of percents :) You take good care, both... |
Description
This seems straghfforward. Normally when you've made changes on an Entry in the CP, attempting to leave the page by any means, such as closing, browser back button, links like return to Entry listing, attempting to refresh,, etc.. will result in a blocking dialog. This asks assurance that you want to lose your changes, nicely worded to suit what you tried.
However, at least recently (and I think it is recently), this blocking dialog doesn't appear -- if you've pushed the Live Preview button, and are watching the page, before you begin editing it.
If you've made changes before opening Live Vue, then you get the dialog regardless. So it's duirng edits while in Live Preview where the changed-content event or response don't appear to be active.
Steps to reproduce
Additional info
PHP version 7.1.17
Database driver & version MySQL 5.7.22
Image driver & version GD 7.1.17
Craft edition & version Craft Pro 3.0.15
Yii version 2.0.15.1
Twig version 2.4.8
Guzzle version 6.3.3
Imagine version 0.7-dev
Plugins: a handful; I disabled them all
The text was updated successfully, but these errors were encountered: