We have released a Glossary of terms built with two use cases in mind:
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.
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.
sjs-3engine now supports the
File.prototype.bucketId()method in addition to the
File.prototype.placeholder()method which became deprecated but remains supported.
accept-1built-in type used attribute names containing the term placeholder. We introduced an
accept-2type that uses attribute names containing the term bucket instead.
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
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
sjs-3 engine, we also had a variable named
app which referred to the
back to the early days when Boomla had a completely different runtime.
From now on, the variable
app is deprecated, you should use
Again, both variables will live on, this is not a breaking change.
Instead of using a file named
.Trust for storing Content-Security-Policy
rules, we will from now on use a file named
This is not a breaking change, as the
.Trust. file will continue to be
To dynamically set Content-Security-Policy headers on the HTTP response, you
can decorate the
content-security-policy attribute of the
Up until now, one had to always set the
content-type attribute of
files. Let’s face it, most of the time when writing code, we use
So from now on, Boomla will default to this setting - but you can always
The following changes did not affect the current version of any website in the Boomla Cloud, but I’m documenting them anyway for reference:
sjs-2engine was removed,
.Stylefile 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.
Here are some helper scripts to help your migration if you decide to upgrade your website to use the new terminology: