silverstripe / silverstripe-elemental

Create pages in Silverstripe CMS using content blocks
http://dna.co.nz
BSD 3-Clause "New" or "Revised" License
110 stars 115 forks source link

Saved/Published blocks not applying to preview #418

Closed brynwhyman closed 5 years ago

brynwhyman commented 6 years ago

When a block is edited in-line, neither saving nor publishing the block submits the block to the site preview.

image

Running the following locally: dnadesign/silverstripe-elemental dev-master 4aee18735c

robbieaverill commented 6 years ago

Right, we probably need an entwine hook to update the preview panel when we perform any actions

NightJar commented 6 years ago

This may end up being much trickier than first thought. As it stands currently we have two preview panels, one based in React, and one via jQuery.Entwine. The former will have no state change to trigger it to reload the iframe, and there are warnings about frivolously using component.forceUpdate() (as it sounds like it'll cascade).

Dealing with the Entwine probably isn't quite so hard, but may involve a bit of ugly hacking to call methods that aren't intended to be public (and this is assuming that entwine will allow it).

There's also consideration to be had around whether or not (or how) browsing in the iframe in the React implementation will affect the main window - at the moment to my memory it is only configured for a single use case (history viewing) and doesn't make the same considerations the Entwine implementation does. But then again as it stands the React implementation is not used anywhere except history views... in the end I guess this point is more around being careful about future-proofing work as to not accidentally introduce a large amount of technical debt.

And all this is not considering the issue that most browsers will simply not re-fetch or re-render an iframe when the src tag is changed to the same value. We can hack around this by introducing a nonsense timestamp get parameter I guess, which would also resolve the React redrawing issue... how does everyone else think about this though?

robbieaverill commented 6 years ago

Dealing with the Entwine probably isn't quite so hard, but may involve a bit of ugly hacking to call methods that aren't intended to be public (and this is assuming that entwine will allow it).

Yeah this is the way forward right now. If you mean calling something like window.jQuery('.cms-preview-panel').entwine('ss').reload() or something, I don't think that's especially "hacky".

the React implementation is not used anywhere except history views...

It's also used in campaigns. We wanted to implement it into the CMS as well, but it would've involved recreating all of the preview controls in React components (e.g. view mode toggle which was done, but also e.g. the resizer).


Please look at the entwine hooks on the non-React preview area, that's what we'd be hoping to use

robbieaverill commented 5 years ago

Fixed with #461