- - - By CrazyStat - - -

15. November 2016

Typo3 Mask – Javascript and CSS includes of extensions missing

Filed under: JavaScript,Typo3 — Tags: , , , , , , — Christopher Kramer @ 11:36

I was using Mask 2.1.1 with Typo3 7.6.11 for a site as described in the Mask manual with this typoscript:

page <
page.10.file.stdWrap.cObject.default.value = fileadmin/templates/index.html
page {
        includeCSS.styles = fileadmin/templates/style.css

The problem with this was that the CSS and JS files includes from extensions where missing, even though the static templates of this where included. The reason is that this typoscript overwrites the page.include* stuff defined by the templates.

A workaround

To solve this, I copied the page.include* stuff defined by the extensions in a temporary variable and restored it after loading the mask object into page:

tempJSFooterlibs < page.includeJSFooterlibs
tempJSFooter < page.includeJSFooter
tempCSS < page.includeCSS

page <
page.10.file.stdWrap.cObject.default.value = fileadmin/templates/index.html
page {
        includeJSFooterlibs < tempJSFooterlibs
        includeJSFooter < tempJSFooter
        includeCSS < tempCSS

        includeCSS.styles = fileadmin/templates/style.css

There are more includes you might need to consider if your extensions use these:


Hope this helps someone with the same problem! Please let me know if there is an easier solution.

Update 06.07.2017: The clean way

So the workaround described above works, but it has a disadvantage: You might install a plugin that defines some other page.* property that gets lost. For example, I just had this problem with mindshape_cookie_hint: It defines page.9877 which gets lost when you overwrite page with It took quite some time until I found the reason for this problem. And then I found another way which is much simpler than the one described before:

page = PAGE
page.10 <

Just don’t copy the whole, only This will preserve all the stuff defined by plugins. The solution is so simple and easy!

So I think this is not really a bug in mask, it is rather a mistake in the documentation.

Please let me know in the comments if this saved your day or if you have suggestions.


Try my Open Source PHP visitor analytics script CrazyStat.

26. September 2013

jQuery: check whether an element exists

Filed under: JavaScript — Tags: , , , — Christopher Kramer @ 13:47

In traditional JavaScript, to check if some element exists, you’d have done something like this:


Of course this still works but what about using JQuery? So you might try this:


But this will always be true as jQuery always returns an object, no matter whether the selector matched or not.So what you can do is the following:

if($('#someID').length > 0)

This will do the trick. You can even leave out “> 0”:


The cool thing is you can use this also to check more complex stuff, like whether #someID has an <img> child-element:

if($('#someID img').length)

And this is where jQuery really makes life a lot easier because with traditional JavaScript, this would be a bit lengthy for what it does.

Have fun!

13. March 2012

sqlite.js: SQLite for Javascript!

Filed under: DBMS,JavaScript — Tags: , , , , , — Christopher Kramer @ 12:01

I just found something quite cool which I thought might be interesting to some of you.

Alon Zaka created emskripten, a LLVM-to-JavaScript converter. It can convert LLVM-bytecode such as provided by compilation from C/C++ code into JavaScript. This approach seems quite cool and it already proved to produce some cool results:

He converted the SQLite-library, which is written in C, into JavaScript. You can find (and fork) the project on github or just try the demo.

The first thing that I was curious about was: How does it store the database file? Well, it creates a new database when you do But you can pass data to to start with a pre-filled database. So I think using this library would normally look like this:

  1. fetch the initial database from the server (e.g using AJAX). At least DB schema and some important data.
  2. open the database with SQL.js
  3. do some operations on the database, mostly SELECTs probably
  4. maybe fetch some more data using AJAX from the server when needed
  5. maybe send some data to the server to save changes using form or ajax

So this would mean we move some more stuff to the client. It would allow us to use SQL on the client side just like we do on the server-side. So we could use the same queries for javascript-based clients on the client and for html-only-clients on the server. (But exposing SQL-queries used in the server might make SQL injection as easy as never before…)

I see two other interesting ways of using this:

  1. In combination with HTML5 local storage – this would allow to store a persistent client-side database that could be accessed using SQL. Sounds pretty cool and the main usage scenario of SQL.js for me.
  2. On the server using node.js – but when I think about it: There are better ways to access a database within node.js, so this is probably only showing that it works, but no real usage scenario.

Tell me what you think about it.