Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/webjetcms/webjetcms/llms.txt

Use this file to discover all available pages before exploring further.

The administration provides two main areas for system-level configuration:
  • Configuration (under the Setup section) — manage key-value configuration variables that control system behaviour.
  • Settings — manage automated tasks, HTTP response headers, and translation keys.

Configuration variables

The Configuration section displays and manages individual configuration variables that differ from their preset (default) values. Variables not yet modified are not shown in the table but can still be referenced and set.
A full reference of commonly used configuration variables is available in the installation documentation.

Adding a configuration variable

The Configuration name field has autocomplete. As you type, it suggests existing variable names — including variables that are not yet in the table (i.e., still using their default value). Three outcomes are possible when adding:
The existing record is updated. No new row is created.
A new row is added. No new configuration variable is defined; you are overriding the preset default value.
A new row is added and a brand-new configuration variable is defined.
When you select an autocomplete suggestion, the current or default value of that variable is pre-filled in the editor. Most changes take effect immediately after saving. Some configuration variables require an application server restart.

Editing a configuration variable

  • If you keep the Configuration name unchanged, the existing variable is updated.
  • If you change the name to an existing variable’s name, that variable is updated instead.
  • If you change the name to one that does not exist, a new variable is created.

Deleting a configuration variable

Deleting a variable sets it to a blank value immediately. If the variable has a preset default value, the default only takes effect after an application server restart.
Two outcomes when deleting:
  • If there is a preset value, the variable reverts to that preset after a restart.
  • If there is no preset value, the variable ceases to exist.

HTTP response headers

The HTTP Headers application (in the Settings section) lets you define HTTP response headers (HTTP Response Header) applied to pages based on their URLs. Headers are configured per domain. If multiple headers have the same name, the one with the longest matching URL prefix is used.

Header editor fields

Specifies which URLs the header applies to. Supported formats:
  • /folder/subfolder/ — applies to all URLs starting with this value.
  • ^/path/subpath/$ — applies to an exact URL match.
  • /path/subpath/*.pdf or /path/subpath/*.pdf,*.jpg — applies to URLs starting with the path and ending with the specified extensions.
The name of the HTTP header to set.
The value for the header. Supports the following macros that are replaced at runtime:
  • {HTTP_PROTOCOL} — the request protocol.
  • {SERVER_NAME} / {DOMAIN_NAME} / {DOMAIN_ALIAS} — domain-related values.
  • {HTTP_PORT} — the server port.
  • {INSTALL_NAME} — the installation name.
  • {HEADER_ORIGIN} — the value of the HTTP origin header.
Optional internal note, visible only in administration (for example, recording who requested the header and when).

Automatic headers

  • For web pages, Content-Language is set automatically based on the folder or template language. If you define this header in the application, your value takes precedence.
  • For URLs starting with /files, /images, or /shared, Content-Language is set based on the defaultLanguage configuration variable, with language-specific overrides for paths containing /en/, /de/, /cz/, or /sk/.
Some headers (such as x-robots-tag for pages with crawling disabled) are set by configuration variables and may override values you set here. See the security tests documentation for details.

Automated tasks

The Automated tasks section (found under Settings) lets you define scheduled background tasks that run automatically on the server.

Task editor fields

A descriptive name you assign to the task.
The fully qualified Java class name that implements the main method to execute. For example: sk.iway.iwcm.system.cron.DownloadURL.
Parameters passed to the task, separated by |. For DownloadURL, the format is URL|fromEmail|toEmail|subject. The URL is required and must include http:// or https://.
Controls when the task runs, using cron-style notation:
  • * — always (every unit).
  • */10 — every 10 units (or any other number).
  • 20 — when the unit equals 20.
  • 3-5 — when the unit is 3, 4, or 5 (counted from zero).
Example: to run every 10 minutes, set Minute to */10 and all other fields to *.
Whether to run the task automatically when WebJET starts (useful for initial data loading).
Whether the task is currently enabled. Disabled tasks do not run regardless of their schedule.
Whether task executions are recorded in the audit log.
In a multi-node cluster, specifies which node should execute the task.
Changes to task timing apply immediately. Tasks that have already started will run to completion.

Standard built-in tasks

Diagnostic task — prints its first parameter to the console.Parameters: the text to print.
Downloads a URL and optionally sends the result to an email address.Parameters: URL (required) | senderEmail | recipientEmail | subject
Executes SQL statements provided as parameters, separated by |.
Scans a directory for indexed files that are no longer referenced by any page and unpublishes them. Only meaningful when automatic file indexing is enabled via fileIndexerIndexAllFiles.Parameters: directory | notificationEmail | true/false (if true, files are unpublished; if false, only a notification is sent).
Publishes scheduled changes to web page folders. No parameters.
Sends email notifications about upcoming calendar events. No parameters.
Publishes scheduled changes to configuration variables. No parameters.
Updates active session data across cluster nodes and purges records older than 60 minutes. Use this task (e.g., every 10 minutes) to keep the active logins panel on the dashboard current.
Flushes in-memory web page traffic statistics to the database. No parameters.
Deletes generated click heatmap images from statistics. No parameters.
Publishes scheduled changes to the file archive. No parameters.
Detects a page’s ranking in search engines based on configured keywords. No parameters.
Records data for server monitoring. No parameters.

Translation keys

The Settings section includes two areas for managing UI translation strings.

List of keys

The Translation keys section lets you create, edit, duplicate, and delete translation keys, as well as import and export them. Each record shows all language values for the key and the original values from the translation file (before any modifications). Key types:
TypeDescription
Original keyLoaded from a translation file; never modified. Cannot be deleted.
Modified keyAn original key whose value has been changed. The modified value is stored in the database; the original remains visible for reference.
New keyCreated in the editor, not from a file. Stored entirely in the database and can be deleted.
When creating a new key, give it a unique name and include the application or module name as a prefix to avoid collisions (for example, myapp.button.save).
Deleting keys:
  • A new (database-only) key is fully deleted.
  • A modified original key reverts to its file value when deleted from the database.
  • An original (file-based) key cannot be deleted — you will receive a notification.
Importing keys: During import you can choose to import only new (non-existing) keys. Existence is checked per language, so an existing key’s value is not overwritten during import.

Missing keys

The Missing keys section lists translation keys that were requested but not found. No editing is allowed here — records are read-only (export only). The table shows the key name, language, the time the translation was last requested, and the last URL where it was called. Click Delete all to clear the missing-keys list and start collecting fresh data. This is useful for verifying whether a page has any missing translations.
Clicking on a key in the Missing keys table opens an editor where you can complete the translation and save it immediately, without switching to the List of keys section.

Build docs developers (and LLMs) love