Examples Templates Store Pricing Docs Turbo CSS Blog Introducing Turbo UI Named buckets Turbo CSS is Tailwind CSS on steroids Introducing Turbo CSS, the most advanced web-design language Calculate how much storage you use Better login system Collaboration settings Filesystem and Database are not cutting the problem space right What I'm working on 64bit File node IDs New how-to videos Creating buttons gets easier Introducing reusable components HTTPS by default Introducing the Boomla Theme CDN for faster pageloads Write your own website builder on top of Boomla On On composition Shared admin access A fresh config editor Building a multi-purpose theme A filesystem to replace your CMS New file link type: scope Mobile editing support Inline file wrapping changed Package sandboxing New PHP-like JavaScript engine [sjs-4e] Send emails to the website owner New JavaScript engine [sjs-4] A better editing experience New email service provider Glossary and other changes New panel changes Improved registration flow Boomla goes multiplayer Using local dev tools Why Boomla doesn't need Git File Panel Let's build a community Automatic updates Improved sjs-3 API New Frontend CSS modules Work offline with Boomla Faster page loads via caching Drag & drop supercharged Supporting CommonJS modules  Paranoid about loosing data IDE usability improvements Simple App install flow Meetups in Budapest Goodbye broken links Flow control from user space Customizing apps Contextmenu support for apps Deprecating the .Class file Hello Changelog Embedding 3rd party plugins Introducing Tools Installing apps just got amazing Public beta Host on our servers Simple deploy with push/pull Version Control for the Web 350M files on a 1TB disk 2 weeks in review
Control Panel

Glossary and other changes


We have released a Glossary of terms built with two use cases in mind:

  • to look up unknown words as you bump into them, and

  • to read the Glossary in one go to get a better understanding of the system.

We rolled out some related (and some unrelated) changes as well, you can learn about them below.



Changes to our vocabulary had to be reflected in our codebase. Here is an overview of the major changes.


Placeholder -> placeholder, bucket, bucketId

As the system evolved, so did the meaning of some terms. The term placeholder was used to refer to both drop-zones on pages and the corresponding containers which are organizing a file’s children. It became obvious that the two are different things, so we needed two separate words to reflect the subtle differences in meaning.

On the filesystem, we now have buckets. The numeric IDs identifying buckets are now called bucketIds.

The term placeholder will continue to be used for content drop-zones on pages.

This change was rolled out system wide with no breaking changes.

  • The sjs-3 engine now supports the File.prototype.bucketId() method in addition to the File.prototype.placeholder() method which became deprecated but remains supported.

  • The accept-1 built-in type used attribute names containing the term placeholder. We introduced an accept-2 type that uses attribute names containing the term bucket instead.


App -> app, package, source

The term app refers to an application. As we rolled out the package management system for Boomla, I made the mistake to assume that each website will contain a single app, so I named them app webstes.

In practice, multiple apps are often packaged together in a single website, so instead of using the term app website, we will use the term package website, or simply package.

The default install location for such dependencies was the /sys/apps file, which has now been changed to /sys/packages. To have no breaking changes, the system will first look for packages in the /sys/packages file, then in /sys/apps.

In the sjs-3 engine, we also had a variable named app which referred to the source file holding the JavaScript code. The history of this variable dates back to the early days when Boomla had a completely different runtime. From now on, the variable app is deprecated, you should use source instead. Again, both variables will live on, this is not a breaking change.


.Trust -> .ContentSecurityPolicy

Instead of using a file named .Trust for storing Content-Security-Policy rules, we will from now on use a file named .ContentSecurityPolicy.

This is not a breaking change, as the .Trust. file will continue to be supported.

To dynamically set Content-Security-Policy headers on the HTTP response, you can decorate the content-security-policy attribute of the response file.


Content-Type now optional in .Request methods

Up until now, one had to always set the content-type attribute of response files. Let’s face it, most of the time when writing code, we use text/html. So from now on, Boomla will default to this setting - but you can always override it.


Removed support

The following changes did not affect the current version of any website in the Boomla Cloud, but I’m documenting them anyway for reference:

  • the sjs-2 engine was removed,

  • .Class and .Style file support was removed.

These were deprecated about 2.5 years ago and all websites have been migrated back then. This means not only are current website versions not broken by this change, but each has a 2.5 year long fully functional version history. Versions prior to that would have to be updated to work again.


Migration scrips

Here are some helper scripts to help your migration if you decide to upgrade your website to use the new terminology:


you can follow me on Twitter