Posts by: juergen

Posts: 1480
Post: 11795
Topic: Consent to set cookies

We do not yet have a cookie/tracker opt-in solution but this plugin will probably become one when I have time (and more pressure) to finalize it ;)

I will then most likely disassociate from it's original fork and rename it to 'ScriptManager'

Edited: 6 months ago
Post: 11791
Topic: js in subtheme

If you want that effect only in the main navbar, use

$('#navbarResponsive ul:nth-child(2)').addClass('animated rotateIn');

This will leave all other <ul>s alone.

… :not(p) { color: #ff0000; } - what can that be good for

e.g. .sidebar > *:not(p) { color: #ff0000; }

…would select all direct child elements in .sidebar, which are not paragraphs
Not exactly the best way to get such things done but sometimes we can't get around.

Such rulesets usually take revenge very soon.

I still miss li:only([class]) { background: gray } ...

I don't quite understand. You can select almost anything using more specific attribute selectors (MDN)

Edited: 6 months ago
Post: 11789
Topic: js in subtheme

$('ul:nth-child(2)').addClass('animated rotateIn');

Where on earth does that come from?
Nobody should ever do anything like this (selecting generic elements without a class, id or context)!

6 months ago
Post: 11786
Topic: js in subtheme

Instead of


better use


But $page->head_js[] = rawurldecode($page->theme_dir) …

$page->theme_dir is a filesystem path. To load a static asset you need the relative path mentioned above.


And $page->head_js[] = $themeDir .'/assets/js/bootstrap.min.js';    ...functions !

$themeDir is not a Typesetter variable. Wherever it comes from in your case, others will not be able to use it.


Edited: 7 months ago
Post: 11784
Topic: js in subtheme

 $page->theme_path  already contains the layout (or color) subdirectory. You don't need to append  /blue 

On the other hand,  $page->theme_dir  only points to the (filesystem) theme directory and requires   . '/' . $page->theme_color  to be added to get the layout directory.

Admittedly, this is not exactly logical. And you can't just change it later when themes are already using it.

7 months ago
Post: 11778
Topic: gpOutput::Get('Extra....


That's the correct way to do it.

Another way is to add a simple

<?php gpOutput::Get(); ?>

to template.php

This will create an 'empty Slot' you then can use to add extra content areas or menus via Layout Editor.

Edited: 7 months ago
Post: 11776
Topic: Typesetter hacked (File permissions changed)

Perimeters should be written to a writable config file that can never be executed

I'm just curious: such a config or content file (be it xml, json, ini, txt, you name it) that potentially contains sensitive information - which technique would you use to protect it from direct access?

Edited: 7 months ago
Post: 11775
Topic: Typesetter hacked (File permissions changed)

No modern operating system with secure installation will ever allow a file that is executable to be writable by the web server… This can be done…

A noble approach but far from reality. A simple example: How should a remote update, the installation of plugins or themes work in such an environment you describe? With strong crypto, code signing and mandatory security audits for all community plugins and themes? Hardly feasible. And even then, the updater would have to write executable code (namely PHP in our case.)

Another example: let's take Wordpress. IMO it's a good measure simply because it is by far the most successful CMS.

Take a look at Worpress' Theme Editor (many other web CMS have similar features). We do not allow such editing of PHP files because we would call that an authenticated RCE.

In contrast to Wordpress, Typesetter will never allow direct access to PHP files from the admin user interface (regardless of set admin permissions). None of the PHP files that Typesetter writes to the /data directory is an entry point. They all instantly die if not loaded by a running Typesetter instance. This sets Typesetter significantly apart from WordPress in terms of security IMO.

If Typesetter was (re)written today, it would probably go a different path.
There is an experimental setting in /gpconfig.php to use JSON files instead of PHP. It's experimental for several reasons - worth a different topic.

To sum it up: Typesetter had extremely few serious security vulnerabilities in its history. Way less than most other CMS I know.
I personally had no security incidents in the past 8 years. Over 100 websites, no incidents.
The most recent WordPress hack I've been dealing with was just 2 weeks ago.

So Typesetter can't be that bad.



edit: Have to correct myself - seems as if the JSON option was removed again from gpconfig. Some remains here and here

Edited: 7 months ago
Post: 11772
Topic: Typesetter hacked (File permissions changed)

For those interested: This is the code block that leads to the error message mentioned.
Pretty simple stuff, actually.

If someone has suggestions for improvement, go ahead.

Edited: 7 months ago
Post: 11771
Topic: Responsive image
Yep, thanks. Will be in the next update.
7 months ago


elFinder 2.1.50 in Upcoming Release

A new release for Typesetter is in the works with a lot of improvements including the ... Read More

Typesetter 5.1

Typesetter 5.1 is now available for download. 5.1 includes bug fixes, UI/UX improvements, ... Read More

More News


Company located in T├│rshavn, Faroe Islands. * Webpage Design * Consultant & Provider of a wide range of programs for visually impaired and dyslextics.

Find out more about our Provider Spotlight

Log In