Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: How much should we trust other authors?
There is no main admin.css […]
I could have written theme.css or default.css or textpattern.css or whatever – it is obvious from context what is suggested: the current admin theme’s stylesheet
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
What is the current admin theme stylesheet? AFAIK, there is no name convention neither php function/method to retrieve it. There is a way is to access document styles via js though, needs testing.
Offline
Re: How much should we trust other authors?
This is my document.styleSheets:
StyleSheetList(3) [
CSSStyleSheet http://localhost/textpattern/textpattern/admin-themes/hiveneutral/assets/css/textpattern.css,
CSSStyleSheet http://localhost/textpattern/textpattern/admin-themes/hiveneutral/assets/css/print.css,
CSSStyleSheet http://localhost/textpattern/textpattern/plugins/com_article_image/style.css ]Which one is main?
Offline
Re: How much should we trust other authors?
The thing you “know” for sure is the $theme_name, you can discrard anything in the plugins ($plugin_path), in the case pf your theme, one stylesheet has a media type of print, you can discard it. Theme can also have one custom stylesheet, “custom.css” by default (users can customise that, check relevant Readme files for the theme).
Here is a potential way forward, without going through hoops to find the “main” stylesheet: create a minimal style block that can be inserted after all the “purifying”. It is agnostic to the theme in use (which probably does the same) The only thing it does is minimize potential overflow.
Is it possible to wrap the inserted article view into wrapper-div, with id=txp-preview-wrapper (name TBD) ? This would avoid spillover into the main Textpattern admin view.
#txp-preview-wrapper :is(img, picture, audio, video, iframe, pre, table) {max-width: 100%; width: auto; height: auto; }
#txp-preview-wrapper pre { overflow: auto; }
#txp-preview-wrapper { -webkit-hyphens: auto; hyphens: auto; } /* split (hyphenate) longlong words */
#txp-preview-wrapper pre > code { -webkit-hyphens: none; hyphens: none; }iframe is included above for those who insert / embed videos from YT, Rumble, e.a
PS – I just saw that you made some (many?), including, if I read the GH page correctly, a wrapper div. I will check that tomorrow.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
phiw13 wrote #336081:
The thing you “know” for sure is the
$theme_name, you can discrard anything in the plugins ($plugin_path), in the case pf your theme, one stylesheet has a media type of
The only thing we know is the theme path, but not what happens inside it. A theme could use many stylesheets (e.g. common.css, article.css), so guessing which one is (are) ‘main’ without convention is unreliable.
Here is a potential way forward, without going through hoops to find the “main” stylesheet: create a minimal style block that can be inserted after all the “purifying”. It is agnostic to the theme in use (which probably does the same) The only thing it does is minimize potential overflow.
That’s (more or less) how it currently works, indeed. The only rule we are injecting atm is *{max-width:100%}, but if we agree on a theme-agnostic set, it can be done.
Is it possible to wrap the inserted article view into wrapper-div, with
id=txp-preview-wrapper(name TBD) ? This would avoid spillover into the main Textpattern admin view.
Here comes the funny part. The preview is already wrapped, but its content is isolated (shadowed) from the main document:
<div id="pane-preview">
<shadow-root>
<div id="txp-preview-wrapper">
<!-- content here -->
</div>
</shadow-root>
</div>No rule you define outside of shadow-root applies to its content (and vice-versa). Neither #pane-preview * nor #txp-preview-wrapper from the ‘main’ stylesheet will match anything. The only rules that will pass through from html/body are those with inherit default value (color, font- etc).
To style inside the preview we need to inject rules into shadow-root itself via link/style/javascript. The question is: which rules must be injected? Since we have no ‘main’ css file, they have to be defined somewhere, but where?
Offline
Re: How much should we trust other authors?
Textpattern traditionally prefers convention over configuration because it makes things easier.
Unfortunately, for theme authors, we define the best practice folder structure but not its contents. So it could be tricky to define a convention for stylesheets.
This is a tough one.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: How much should we trust other authors?
No rule you define outside of shadow-root applies to its content (and vice-versa). Neither #pane-preview * nor #txp-preview-wrapper from the ‘main’ stylesheet will match anything. The only rules that will pass through from html/body are those with inherit default value (color, font- etc).
Yes, I know all that… Good to see you added the wrapper inside your shadow root (#txp-preview-wrapper). Thus my suggestion for a minimal style-block that Textpattern admin inserts (that this the TXP core PHP/JS code), not added by an admin theme.
(oh, and fwiw, * {max-width:auto} is a bit of wild sledgehammer approach – most HTML element have no need or use for it.)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
On a related note,
- Do I understand this correctly: if an article is saved in draft status and you view the article by following the “View” link under the Save button (not the Preview link above the textarea) then most styling and any JS is blocked. JS provided by e.g YT/Vimeo, self-hosted webfonts, manifest.webmanifest, self-hosted linked script(s) + plus maybe some conflicts or something (not clear what it was) caused by some CSP rules.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
phiw13 wrote #336084:
Yes, I know all that… Good to see you added the wrapper inside your shadow root (
#txp-preview-wrapper).
Yep, though it should be done more carefully. Leave it with me.
Thus my suggestion for a minimal style-block that Textpattern admin inserts (that this the TXP core PHP/JS code), not added by an admin theme.
I’m fine with it, if all theme authors agree on the rules. We could put them in some core preview.css file.
Do I understand this correctly: if an article is saved in draft status and you view the article by following the “View” link under the Save button (not the Preview link above the textarea) then most styling and any JS is blocked. JS provided by e.g YT/Vimeo, self-hosted webfonts,
manifest.webmanifest, self-hosted linked script(s) + plus maybe some conflicts or something (not clear what it was) caused by some CSP rules.
Yes, a CSP sandbox directive is set, though it shouldn’t block styles (must be some other CSP rule). We could remove it for author’s own articles.
Offline
Re: How much should we trust other authors?
Yes, a CSP sandbox directive is set, though it shouldn’t block styles (must be some other CSP rule).
After more careful look what was actually happening in my case is that –given that the webfonts are blocked– many small things did not render correctly (font-features not available in the fall back font).
And the reason the webfont blocking: no CORS Access-Control-Allow-Origin header set (although I still see the error after configuring it).
Other things that go wrong: embedded videos do not appear or appear partly.
Blocked script execution in https://player.vimeo.com/video/121745940?h=9c645a9aae' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.We could remove it for author’s own articles.
Dunno. Maybe? For the authors’s own articles, viewing the draft on the public side with all functionality enabled makes life comfortable when authoring.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
Here’s perhaps a solution, but a complicated one, that fixes blocked content caused by Content Security Policy (CSP) header:
Have a script run in the background that reads every published article contents, then extract external links from them, then remove query parameters etc. so that only the base domains are left, then put those domains in an array, remove duplicates, and create a CSP header that allows content from those domains. 😐
Offline
Re: How much should we trust other authors?
Ref, the webfonts & CORS issue for articles in Draft mode:
Header set Access-Control-Allow-Origin *But for some reason I don’t think that is a good idea for a Live server.
(it is not a big issue)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline
Re: How much should we trust other authors?
I actually think the article preview security could be left to site admins, since it happens on the public side now. They should secure their site anyway, by setting appropriate headers (via .htaccess or config.php or <txp:header /> or whatever).
Offline
Offline
Re: How much should we trust other authors?
etc wrote #336163:
Do we really need this wrapper, given that it wraps the whole preview content?
Do you mean <div id="txp-preview-wrapper" class="body"> ?
If you don’t need for your template construction, then I don’t thinks so.
When I first made the suggestion (adding the id) to the div I thought mainly about having a selector to fully isolate any styling given to the content, but everything is now sandboxed and loads it’s own style block, so for styling reason that selector is not needed.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline