Previewing articles inline

phiw13 · 2024-12-02 08:19:39

etc wrote #338397:

You’d need to debug it yourself, I’m afraid. Tested and retested, Safari works for me on the demo site.

You want a login to my test site ? Send me an email and I’ll set up an account where you can see for yourself.

etc · 2024-12-02 09:19:50

phiw13 wrote #338398:

You want a login to my test site ? Send me an email and I’ll set up an account where you can see for yourself.

Sure I can test, the mail address is in my profile. But if it does not work for you on the demo site, the problem seems to be on the client side. I don’t remember which Safari version I have tested.

Anybody with Safari, can you test shift-click the View link on Write tab, please?

phiw13 · 2024-12-02 09:32:41

etc wrote #338399:

[…]

On the demo site, I added a script to the <head> of the archive page template

<script defer src="./scipt/sndsp.min.js"></script>

I then accessed the only article, shift-click on the “View” link. Result below (screenshot):

dev.l-c-n.com/_b/Screenshot%202024-12-02%20at%2018.24.19.png

–^–

I don’t see any email address in your forum profile only the forum email link.

etc · 2024-12-02 09:45:08

Ah. Scripts surely won’t work in sandboxed iframes. If you are absolutely confident of your site content, unchecking ‘sanitize’ should work. Another option would be to expose the iframe sandbox attribute to site admins, for fine-tuning.

But, as you say, our time can be better-spent :-)

I’ve just tested Sandspace, it works for me locally, in Firefox, though.

giz · 2024-12-02 17:09:14

etc wrote #338396:

They need (eventually) to be textiled first, right?
Also, you can change section/form ‘on the fly’ while previewing, without actually saving the article.

They’ve been textiled already; the html in the preview tab would be the source. Similarly, current section etc. is also available.

Anybody with Safari, can you test shift-click the View link on Write tab, please?

It works, but I also get error Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

.

I’m not wild about splitting preview functionality across 2 areas; doesn’t a dedicated ‘preview page’ link belong in the Preview modal?

etc · 2024-12-02 18:13:46

giz wrote #338407:

They’ve been textiled already; the html in the preview tab would be the source. Similarly, current section etc. is also available.

They aren’t, until you click Preview button, which makes a call to the server (check the console). We could populate them on page load, but then you’d have to save the article to refresh the preview.

It works, but I also get error Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

That’s not an error per se when the frame is sandboxed. Otherwise (malicious) public side scripts might be able to access the admin side. If you site is totally under your control, just uncheck ‘Sanitize’ checkbox, but I’m very sceptical re doing it by default.

Also, that’s what your site visitors with disabled js will see.

I’m not wild about splitting preview functionality across 2 areas; doesn’t a dedicated ‘preview page’ link belong in the Preview modal?

Me neither, but putting it inside div.txp-dialog along with body/excerpt preview pane yields double scrollbars when jQUI does its job. We can revisit it in txp 5.

giz · 2024-12-02 20:02:43

etc wrote #338408:

They aren’t, until you click Preview button, which makes a call to the server (check the console). We could populate them on page load, but then you’d have to save the article to refresh the preview.

Agreed. In txp 5 we can roll everything into the preview tab. I’m using <details> to control visibility of the panes, and their contents can either be inline on page load, or loaded asynchronously. A Page Preview iframe can be triggered asynchronously as required, and we could use the html pane as a source for populating the iframe.

etc · 2024-12-02 20:25:36

etc wrote #338408:

If you site is totally under your control, just uncheck ‘Sanitize’ checkbox, but I’m very sceptical re doing it by default.

To develop a little more, try unsanitized inline preview of an article containing

<script>window.parent.document.getElementById('title').value = 'Hacked!';</script>

and enjoy your new article title.

phiw13 · 2024-12-03 01:00:49

etc wrote #338401:

Ah. Scripts surely won’t work in sandboxed iframes. If you are absolutely confident of your site content, unchecking ‘sanitize’ should work. Another option would be to expose the iframe sandbox attribute to site admins, for fine-tuning.

Yes, you can do that for “Draft” or “Pending” articles, but not for “Live” articles.

Live article are always sandboxed, (there is no checkbox to toggle “sanitise”)

<iframe id="preview-frame" name="preview" tabindex="-1" class="txp-dialog ui-dialog-content ui-widget-content" sandbox="" srcdoc="…………"</iframe>

draft article, (checkbox toggle off)

<iframe id="preview-frame" name="preview" tabindex="-1" class="txp-dialog ui-dialog-content ui-widget-content" srcdoc="…………"</iframe>

For me, what is interesting is the possibility to (pre-)view changes / edits to live articles without saving (like: verifying that my edits are correct, code wise). If I save the article then the changes are immediately reflect on the public side for all to see. I can do that sanity check without problems with the preview dialog – including sanitised view. Having the full view of the article doing that in an iframe is a bonus.

I am not at all convinced a “Live” article should be sandboxed in the iframe the way it is now.

And of course I am trusting the code surrounding the article (outside of article body or excerpt).

PS – a annoying side effect of the sanitised view in the iframe is that the reviewer (or author) cannot locate where the potentially dangerous elements are. At least they are some bit visible in the pre-view dialog

–^–

I’ve just tested Sandspace, it works for me locally, in Firefox, though.

Yes, that issue has nothing to do with the admin theme in use. And yes Firefox behave differently than Safari.

phiw13 · 2024-12-03 01:02:46

giz wrote #338407:

They’ve been textiled already; the html in the preview tab would be the source. Similarly, current section etc. is also available.

It works, but I also get error Blocked script execution in 'about:srcdoc' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

Do you have script(s) running on the page? Or any form of CSP policy in place?

I’m not wild about splitting preview functionality across 2 areas; doesn’t a dedicated ‘preview page’ link belong in the Preview modal?

The default view page is fine as it is there as it is an completely different view form what is offered in the preview dialog.

Now, if you specifically talk about that easter egg functionality triggered by a shift-click on the “view” link, hmmm. It is still a different view (global) whereas the “preview” button offeres an local view – article body or article excerpt only. I think I am strongly inclined to prefer to keep the two views separate.

(and by next week I’ probably have forgotten about that shift-click action as the key-combo is hardwired in my fingers to the default Safari action: “add to reading list”)

etc · 2024-12-03 07:57:53

phiw13 wrote #338413:

Live article are always sandboxed, (there is no checkbox to toggle “sanitise”)
…
For me, what is interesting is the possibility to (pre-)view changes / edits to live articles without saving (like: verifying that my edits are correct, code wise).

I agree, previewing before saving is the most useful (and the most tricky) feature. We can restore ‘Sanitize’ checkbox for live articles, no problem there.

And of course I am trusting the code surrounding the article (outside of article body or excerpt).

Here is the point: do we say ‘trust your authors too’ and the living is easy, or we add ‘Sanitize’ checkboxes everywhere? It’s very hard to prevent injections without thoroughly inspecting the content. A malicious code could be hidden, say, in a custom field of a future article and bite one day.

PS – a annoying side effect of the sanitised view in the iframe is that the reviewer (or author) cannot locate where the potentially dangerous elements are. At least they are some bit visible in the pre-view dialog

We can pass it through DOMPurify, as we do for body/excerpt preview, but it makes one more checkbox. Suggest an interface?

There is another potentially annoying effect: relative public side URLs will (?) be resolved with respect to the admin root. Setting <base /> in public templates might help, but is a bit restrictive.

All this makes me think the (pre)view should be refactored.

etc · 2024-12-03 07:58:29

phiw13 wrote #338414:

(and by next week I’ probably have forgotten about that shift-click action as the key-combo is hardwired in my fingers to the default Safari action: “add to reading list”)

Suggest an interface :-)

phiw13 · 2024-12-04 00:07:31

etc wrote #338417:

Suggest an interface :-)

Nah… it is fine for now. Compare it to some of the more specialised menu items in macOS, half hidden behind the option key.

The alternative would be an additional <button /> but given that the Write panel is already quite stuffed with buttons, it is a little difficult.

Textpattern CMS support forum

#16 2024-12-02 08:19:39

Re: Previewing articles inline

etc wrote #338397:

#17 2024-12-02 09:19:50

Re: Previewing articles inline

phiw13 wrote #338398:

#18 2024-12-02 09:32:41

Re: Previewing articles inline

etc wrote #338399:

#19 2024-12-02 09:45:08

Re: Previewing articles inline

#20 2024-12-02 17:09:14

Re: Previewing articles inline

etc wrote #338396:

#21 2024-12-02 18:13:46

Re: Previewing articles inline

giz wrote #338407:

#22 2024-12-02 20:02:43

Re: Previewing articles inline

etc wrote #338408:

#23 2024-12-02 20:25:36

Re: Previewing articles inline

etc wrote #338408:

#24 2024-12-03 01:00:49

Re: Previewing articles inline

etc wrote #338401:

#25 2024-12-03 01:02:46

Re: Previewing articles inline

giz wrote #338407:

#26 2024-12-03 07:57:53

Re: Previewing articles inline

phiw13 wrote #338413:

#27 2024-12-03 07:58:29

Re: Previewing articles inline

phiw13 wrote #338414:

#28 2024-12-04 00:07:31

Re: Previewing articles inline

etc wrote #338417:

Board footer