Skip to content
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

Closed
narration-sd opened this issue Jul 13, 2018 · 4 comments
Closed

Comments

@narration-sd
Copy link
Contributor

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

  1. I tried this with a very simple page. I know you prefer code:
{% set pages = craft.entries.section('pages') %}
{% for page in pages %}
  <h3>{{ page.title }}</h3>
{% endfor %}
  1. Editing an entry without Live Preview , attempting to refresh the page, bingo, the dialog.
  2. Reload then, to clear to normal status, in between
  3. Now open Live Preview on the entry, edit again. You can see the results this time
  4. Attempt to refresh, and refresh just happens -- no warning or delay, edited changes gone.
  5. Any other move to leave the page gets matching response, according to Live Preview status.

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

@brandonkelly
Copy link
Member

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.

@narration-sd
Copy link
Contributor Author

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

@brandonkelly
Copy link
Member

brandonkelly commented Jul 14, 2018

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.

@narration-sd
Copy link
Contributor Author

narration-sd commented Jul 14, 2018

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants