How to make a conditional header for loading JS/CSS files?

[jonscrut]

Hi
I am trying to load some custom js & css files to support data visualisations.

I have used the extension approach, modeled on "Helloworld" extension and have got as far as being able to load a css file into the header.

However, there are a lot of css & jss files to add, and so I only want these to load into the header on a condition, either that the shortcut "dataviz" is used on a page or some other trick so that the files don't load into headers on every single page and blog post.

I have read some other posts related to this but have not managed to understand if this is actually possible or not and am relative noob in php.

Here is my code for what I have done so far:

<?php
// Dataviz extension

class YellowDataviz {
    const VERSION = "0.8.15";
    public $yellow;         // access to API
    
    // Handle initialisation
    public function onLoad($yellow) {
        $this->yellow = $yellow;
    }
    
    /* Handle page content of shortcut
	
    public function onParseContentShortcut($page, $name, $text, $type) {
        $output = null;
        if $name=="dataviz" 
		
		NOTE: WOULD LIKE TO USE THE SHORTCUT TO BE THE CONDITION FOR THE ACTIVATION OF onParsePageExtra
	*/
    
    // Handle page extra data

    public function onParsePageExtra($page, $name) {
        $output = null;
        if ($name=="header") {
			$output .= "<link rel=\"stylesheet\" type=\"text/css\" href=\"media/dataviz-js/dcjs/css/dc.css\" />";    
        }
        return $output;
    }
}

[jonscrut]

Hi. I realise now that this is not really going to help me as markdown doesn't seem to interpret script tags at all in the body, I thought it would. The datavisualisation packages I am using require pretty complicated blocks of javascript code in the body.

I tried this below but it neither loaded a javascript file or interpreted a simple javascript command. I guess I should have understood this from the other similar comments, but unless anyone has a solution that I have completely missed I will have to find another tool or keep the datavisualisations as separate html files loaded in an iframe or simply referred to as separate but complete pages if I continue with Yellow.

---
Title: Test JS script in body
Published: 2021-03-09
Author: Scrut
Layout: blog
Tag: Data visualisation
---
Introduction blah blah blah.

<script src="https://unpkg.com/react@15.6.1/dist/react.js"></script>

<script type="text/javascript"> 

	document.write("JavaScript is a language"); 

</script> 

[markseuffert]

I think you can solve this in two ways:

1. Use a different layout, put inline JavaScript into a HTML layout file.
2. Use a different parser, put inline JavaScript wherever you want.

Give number two a try If you want to use inline JavaScript with all its glory and pitfalls. Usually the Markdown parser removes unsafe elements/attributes from the body, this plays a central role in making secure websites, but nothing keep you from using a different parser. Here's an example tested with Datenstrom Yellow 0.8.17:

---
Title: Example page with raw HTML and inline JavaScript
Parser: html
---
<p>Hello world in HTML.</p>

<script type="text/javascript"> 
document.write("Hello world in JavaScript."); 
</script> 

Save the following file as system/extensions/html.php:

<?php
// Html extension, experimental

class YellowHtml {
   const VERSION = "0.8.17";

   // Handle page content in raw format
   public function onParseContentRaw($page, $text) {
       return $text;
   }
}

[textplusdata]

I tried the recommendation above about using html parser. This worked fine when using Yellow in normal state.

However, when generating static website it created a folder for every chunk of javascript in a page (see screenshot) both in the main yellow folder itself and in the public folder.

As I understand that this is an experimental workaround I am not expecting a fix, but if there is a simple solution then that would be great.
Otherwise (since I am only interested in generating static websites) the workaround is to allow "script" in core.php as described #617 (comment) or to simply delete the folders after they are generated.

Thanks!

[markseuffert]

Looks like a bug in the static generator. I am happy to investigate and would be grateful if you could give an example to reproduce the bug. Want to open a new discussion?

[markseuffert]

The bug has been fixed in #629.

[GiovanniSalmeri]

The question about <script> in body was raised some time ago, see #515 The bottom line is that this is not allowed in Yellow for security reasons. No one prevents you from manually editing the whitelist (adding "script" in $elementsHtml in core.php), but obvioulsy the modification will be overwritten in case of update. In addition: 1. you can use the <script> tag in the layout 2. there are always ways for inserting a script in the body by modifying the DOM with a script loaded in the head.

[GiovanniSalmeri]

Well, after a moment of serendipity I came up with the following solution:

1. Write the script in a tag <div class="script">, for example <div class="script">alert('Hello there!')</div>
2. Add div.script {display: none} to the style sheet
3. Add the following script in the header:

<script>
"use strict";
window.addEventListener("load", function() {
	document.write = function (text) { // redefine document.write, for good measure
		document.currentScript.insertAdjacentHTML('beforebegin', text);
	};
	var divScripts = document.querySelectorAll('div.script');
	for (var i = 0; i < divScripts.length ; i++) {
		var script = document.createElement('script');
		script.text = divScripts[i].textContent;
		script.defer = true;
		divScripts[i].replaceWith(script);
	}
});
</script>

I do not know if @markseu is happy with this 😇, because this hack (if it really works well) effectively circumvents the security measure of preventing scripts in body...

(For <script src="..."> the solution can be similar.)

[markseuffert]

Conditional headers are not a good design pattern, in my view, they make bundling/caching harder. If the goal is to minimise the amount of data on your website, then l would suggest the following:

First look for a PHP visualisation library that works server-side and generates SVG files. This might be a better starting point for your own extension and you might be able to avoid the whole JavaScript overhead in the first place. That's how the highlight extension works, the rendering can be done on the web server and no JavaScript will be sent to the web browser.

Second look for a JavaScript visualisation library that works client-side and doesn't need big frameworks. If the chosen JavaScript library is not within your size limit, or you use it only in one place, then I would use a tiny loader code that loads the big JavaScript library on demand, also known as "lazy-loading". The one for the Instagram extension has less than 1 KB.

Third put the put the code for "lazy-loading" JavaScript into a new extension or into the bundler.

[GiovanniSalmeri]

Perhaps the problem is that people are finding obsolete JavaScript examples and design patterns, which don't make sense in our time. Any thoughts @GiovanniSalmeri?

@markseu First of all: I fully agree with you about the fact that a script does not belong in the body, exactly like css style should/must not be inlined etc. The "separation of concerns" is always a very good principle, I myself try to follow it very strictly. But... unfortunately the reality is different. I remember the case in #499: here the instructions by Google tell to insert a tiny script fragment in the body in order to display an ad. I imagine the following dialogue: "Dear Google, please change the code of Adsense and move every script in the head". "Why should I? It works, it spares some lines of code and some microseconds, HTML specs neither prohibit nor deprecate nor advice against it". "Yes, but it's bad style!" "And who cares? People see the page, not its source code". "But nowadays there are different ways, this solution is obsolete!" "I am Google, I decide what's obsolete and what's not". But this dialogue woudn't be very different if it wasn't Google.

Let's take https://www.chartjs.org/docs/latest/ Here almost all the JS code is a big json variable which describes the chart. At first glance, it makes little sense to move this variable in the head, because these data refer to the canvas and are different for every chart; moreover there are no trivial alternatives since HTML unfortunately has no native way to represent a structured variable. I myself would anyway try hard to keep the body free from Javascript, I would write an extension that allows writing the data in another format even simpler than Json, but the code would be more complicated, not simpler.

Anyway: I'm afraid that the common webmaster who has chosen Yellow because it is wonderfully clear and easy, who knows HTML and a bit of CSS and a bit of Javascript, is not capable of (or doesn't feel like) finding a solution in these and similar scenarios. For them the easier solution is to add manually "script" to the whitelist. Or to use my criminal little extension 😄 not yet published which I have just improved (now one can directly insert a script tag in the body: it is before all disguised in div class="script" 😎, and later changed back in a script).

[markseuffert]

Thanks @GiovanniSalmeri for your long reply. I fully agree with the situation that you describe. Good design starts with the user first. Not the creator, developer, maintainer, framework or technology involved. I want to help people with their problems on one side. I care about good design on the other side. It's not easy to find a balance, but if in doubt I will always choose the side of the user. To be honest it often feels like I have to step into many wet puddles before I can find a direction that looks promising. Let's take a minute, think about the long term vision and where we would like to go with Datenstrom Yellow.

There are many content management systems. Perhaps there is not much point of making another one that works the same way as all the others? My long-term vision is not to make a Wordpress clone, copy the existing design-patterns and repackage everything in a different colour. We have the chance to look forward, use design-patterns that emerge from our understanding of things, user interfaces that feel good for us, products that adjust to our workflow. This is where I want to spent my time. Developers are of course welcome to experiment and do their own thing. That's one reason why everything is open source. However this could also mean, you might be the one that has to claim responsibility and drive things forward.

If a user wants to use raw HTML instead of Markdown, why not give him/her a different parser? 😀

[markseuffert]

If there's enough interest we can investigate dynamic loading of JS/CSS in the bundler. It might not be possible to handle every use case, however an automatic lazy-loading might be better than bundling everything into one file. It's on my personal wish list. See also #289 and #591.

[nzyeehaa]

@markseuffert love what you have done already with yellow, the bundler has given a huge performance boost IMO and I think optional scripts would be a good next step to lower overheads.

bundlers achieve what image sprites do - reduce requests. 1 x 100kb file would likely be faster than 2 x 40kb files so every reduction in page requests is great.

At the end of the day - we are still scrapping over small morsels of data, when some people still load a handful of 5+Mb images on the page. This is where I spend the most time educating - an image says a thousand words - and it takes more space than a thousand words.
I have seen 8kb pages (including 2kb JS/ + noscript + analytics) 10kb css - weighed down with 6Mb images
thats 1.7sec in 2 requests for html/css/js and 33 sec in 18req for images on a live site.

My direction, in relation to page loading speed(which helps rank in google)...
my css is organised, I focus on css for layout first, then css style then html source ordered content, then scripts which do something with that content, then print style sheets etc.

this all helps for first content paint, eliminates FOUC, gets the user on the page sooner, and anything not required on the page is not loaded.

I aim for no scripts wherever possible, no fonts(or minimal), and focus on html and some css.
Any scripts are vanilla and minified, and if they are required on every page, I have them at the bottom of the html (no page request there, and they are tiny) {this is the reason I dont use the bundler}

and then i conditionally load any additional scripts if required for that page or user or function or conditon, and I normally do that through the great template system I.E: {if home page has a slider, use the homepage template which loads the additional html and script(goes in the head) that is required for the slider.(and the js/code is negligible) with max 4 images on slideshow. All images reduced under 50kb.

I know there has been debate about header, footer, body for scripts, but that is normally in relation to loading huge bulky librarys or bloated code that drag down page requests. My slowest script is analytics, and i will even replace that when I get a chance. (any suggestions welcome)

Summary:
dynamic loading of js would work well and bring better results
likewise, no/smaller js, no fonts, smaller css would bring results
likewise image management, image compression under 10kb would bring greatest result

[nzyeehaa]

@jonscrut

i use my own layouts (so they aren't affected by updates)
and i display slides on the home page only...
I use a layout for the home page and use php to include the slides layout

<?php if(($this->yellow->page->get("Layout")) == "home") : echo $this->yellow->layout("slides"); endif; ?>

and the slides "layout" has its own HTML PHP and inline javascript

While this is not adding it to the head as requested, you may be able to experiment with using the "layout" check in the "head"
So that when you want the CSS and JS added to the page you may be able to add...

Layout: blog-dataviz

to your page,

this solution would keep the code out of the mark-down

[nzyeehaa]

@jonscrut
Sometimes explaining things gets pretty convoluted here, but using yellows feature of "layouts" works well for this...

a page with "layout: blog-normal"
and a page with "layout: blog-with-other-stuff-added"

can give you two totally different templates(layouts) and is useful...
OR can give exactly the same layout and give indication to php that something is different and include other 'bits'

first my end...

from your use case

• I have pages that are normal...
• I have pages that need javascript added (in my case I am adding inline - you need it in the head)
• php identifies when that is required and adds it

The reason I use this method is to avoid loading scripts when they are not required.
yellow has a great slider extension, but theres around 55kb JS / 2.5kb CSS which would be bundled/cached and loaded for every page of my website, even when I am not using it.

All my css is always in 'less' folders, then compiled into a single file which is around 20kb, then yellow does its bundle/caching... (it does mean it is a bit heavier than it needs to be as it includes all css, but it is simpler for my management/updating) and the CSS for my slider is only around 190 bytes uncompressed anyway

I dont like javascript hanging around when not required... and I dont use libraries as the over-heads are way to big, and clashes occur too often.

The page I am importing for my slides brings in vanilla javascript of about 350 bytes and i know inline javascript is not best practice, but it doesnt warrant a separate file to be bundled/cached and included in every page - i dont want it there when it is not required. i still need to add the HTML for the slides, so adding the vanilla JS isnt a problem, and the CSS is already bundled. (note: I could add the vanilla javascript to a file and put it in the head - but it is not worth the time delay for 350 bytes ~ additional note: for only 350 bytes - I could also add it to a file and have yellow bundle it - but then it would be loaded/included in every page)

Therefore my slider is about 540 bytes(0.52kb) of CSS / JS and the bulk is only loaded when I need it. VS: Yellow slider which is 58880 bytes (57.5kb) of CSS / JS - and it is loaded all the time.(i am sure someone will correct me if I am wrong)

SO...
to extend my example to your case

my default layout looks like this...
<?php $this->yellow->layout("header") ?>
<h1><?php echo $this->yellow->page->getHtml("titleContent") ?></h1>
<?php echo $this->yellow->page->getContent() ?>
<?php $this->yellow->layout("footer") ?>

that header can have a conditional check in it...
IF layout = blog-with-other-stuff-added
THEN include script / CSS / other stuff

then if you have a page that has data visualisation stuff on it - change the layout markdown tag
from layout: blog-normal
to layout: blog-with-other-stuff-added

the two layouts could actually be identical code - you just need the php IF statement to identify when it is time to load all the jargon - and it can do that when it sees the layout has changed.

I have learnt to keep the markdown pages simple, and do any changes in my custom HTML layouts so it is not affected by updates

hope that helps explain more

[textplusdata]

@nzyeehaa
How do you manage the blogpages.html layout which is needed to give an overview of the list of blog entries?

Do you alter this code so that it
<?php foreach ($this->yellow->page->getPages("blog") as $page): ?>

includes an "OR" condition so that it would load both pages with layouts "blog" and "blog-other"?

If so, can you post an example of your code to achieve this?

Or is your use-case just individual pages and you don't use the blogpages.html page in the layout folder?

[nzyeehaa]

@textplusdata
yellow is my favourite website software, and of course, the best advice is to stick with what yellow already does...
...or make an extension...

my use case is a little bit different., but here is an easier example/modification which will affect any full pages with graphs...

...from here, I have to assume you know your way around yellow, php, html, css and javascript,
...and that you are aware of site security and the overheads of including .js, libraries and files... (performance ),
...and you realise that if you make modifications and the core files change - your modifications may disappear or need updating also...

with a fresh install of 0.8.17 edit the files as below

system>layouts>header.html
just before the closing head tag, add...

<?php if(($this->yellow->page->getHtml("plus")) == "graph") : echo $this->yellow->layout("addSTUFF"); endif; ?>

add a new file...
system>layouts>addSTUFF.html
and add...

<link rel="stylesheet" type="text/css" media="all" href="myExternal.css" />
<script src="myExternal.js" defer="defer"></script>

...of course you will need to modify the paths and details to suit (and that may need some extra work for relative paths and security)

then in every page you want the addSTUFF details added...
add this in the pages front matter...

Plus: graph

so it would look something like this...

---
Title: Blog page
Published: 2021-03-29 09:57:06
Layout: blog
Tag: Example
Plus: graph
---
This is a new blog page.  
[--more--]  
WITH STUFF ADDED  
graph goes here...

and then your source code would look something like this on each of those pages...

<link rel="stylesheet" type="text/css" media="all" href="media/extensions/bundle-123a4fd567.min.css" />
<link rel="stylesheet" type="text/css" media="all" href="myExternal.css" />
<script src="myExternal.js" defer="defer"></script>
</head>

** note: yellow will not be bundling and minifying your additions, and you will slow down your page loading
** note: I said full pages: I wouldn't want to load anything heavy in the blogpages summary, so my modifications are "below the read more"
** note: I keep valid text/markdown "only" in the yellow editor
** note: I keep any of my code in a custom layout for smoother updates
** note: if yellow core code changes - yours may need updating also

P.S: hopefully I have covered all the details for you. my use case is only for a very tiny piece of custom .js and .html which is only loaded for one page on the whole site.
If you want the code on more than a couple of pages - consider having Yellow minimise and load it, or as @markseu mentioned use glue code to load the library from a remote site, but be aware it will slow your page load

[textplusdata]

Thanks! I didn't realise that you can make your own front matter category like that and then access it from getHtml. That has solved most of my issues :-)

[nzyeehaa]

@jonscrut PS: if it helped - mark it as answered as it may help others.