Magnolia 5.6 reached end of life on June 25, 2020. This branch is no longer supported, see End-of-life policy.
Magnolia uses commands to publish and unpublish content, send email, flush cache, take backups, import and export data and for many other tasks. Commands can perform duties within the system or connect to external resources. Commands are typically executed by actions or scheduled for execution by the Scheduler module.
Characteristics of commands:
You can write your own custom commands and execute them on-demand or scheduled.
Commands consist of a command definition and Java business logic. Since the business logic is written in Java, you can perform basically any task that Java allows.
A command definition makes the command available to the system.
Here are the command definitions for the basic commands that are used throughout Magnolia, configured in Configuration > /modules/ui-admincentral/commands/default
.
Node name | Value |
---|---|
ui-admincentral | |
commands | |
default | |
markAsDeleted | |
class | info.magnolia.commands.impl.MarkNodeAsDeletedCommand |
enabled | true |
export | |
class | info.magnolia.importexport.command.JcrExportCommand |
import | |
class | info.magnolia.importexport.command.JcrImportCommand |
delete | |
deactivate | |
class | info.magnolia.module.activation.commands.DeactivationCommand |
enabled | true |
delete | |
class | info.magnolia.commands.impl.DeleteCommand |
enabled | true |
restorePreviousVersion | |
class | info.magnolia.commands.impl.RestorePreviousVersionCommand |
enabled | true |
exportYaml | |
class | info.magnolia.commands.ExportJcrNodeToYamlCommand |
Commands are organized into catalogs. A catalog is an intermediate folder in the configuration hierarchy. It resides under the commands
folder and contains commands. Catalogs are used to distinguish multiple commands with the same name. For example, the activation
module has two command catalogs: default
and versioned
. This configuration is in the Configuration app > /modules/activation/commands
.
Node name | Value |
---|---|
activation | |
commands | |
default | |
activate | |
versioned | |
activate | |
deactivate |
The advantage of using a catalog is that you can have identically named commands. You might want two activate
commands – one for pages and another for assets. To call a command that resides in a catalog, use the catalog name followed by a hyphen, then the command name. For example, you would distinguish the two activate commands by calling one with workflow-activate
and the other with default-activate
.
Catalog names have to be unique across the system. Magnolia will not merge commands with same name from various catalogs. It will load commands only from one of them. Since the ui-admininterface
module has a default
catalog, the name is already taken. If you created a default
catalog the names would conflict and the system would not load your command. Choose a catalog name that characterizes its commands, such as "messaging
" for commands that send emails and notifications. See Querying for catalogs and commands how to check for currently used names.
Commands can be grouped and executed as a chain. When you call the parent node its child commands are executed one-by-one in the node order from top down.
The activate
command in the versioned
catalog is an example of this.This configuration is in the Configuration app > /modules/activation/commands/versioned
.
It is a group of two commands that are executed one after the other
version
creates a new version of the node.activate
delegates to the activate
command configured in the default
catalog. commandName
property in the <catalog>-<command name>
format.Node name | Value |
---|---|
activation | |
commands | |
default | |
activate | |
class | info.magnolia.module.activation.commands.ActivationCommand |
deactivate | |
versioned | |
activate | |
version | |
class | info.magnolia.commands.impl.VersionCommand |
enabled | true |
activate | |
class | info.magnolia.commands.DelegateCommand |
commandName | default-activate |
deactivate |
Executing commands with actions
In the UI commands are executed by actions. Here's an example action definition for the activate
action in the Pages app. You can find it in Configuration -> /modules/pages/apps/pages/subApps/browser/actions/activate
. See Dialog action definition for the properties and their values.
Node name | Value |
---|---|
modules | |
pages | |
apps | |
pages | |
subApps | |
browser | |
actions | |
activate | |
catalog | website |
class | info.magnolia.ui.framework.action.ActivationActionDefinition |
command | activate |
icon | icon-publish |
You can use the Scheduler module to execute commands at a given time. You could for example activate a press release on a certain day, take a weekly backup of content, or synchronize a taxonomy of terms with an external source. There is an example configuration in the Configuration app > /modules/scheduler/config/jobs/demo
that you can adapt to suit your needs
params
: Parameters passed to the command. Depends on the command. For example, the activate
command expects to receive a repository
name and a content path
as parameters.catalog
: Name of the catalog where your command resides.command
: Name of the command.description
: Describes the job, for example "Send an email message on the hour"cron
: Schedule that indicates the execution time, written as a CRON expression. For example 0 0 1 5 11 ? 2010
means "run on November 5 at 01:00 am". Cronmaker is a useful tool for building expressions.active
: Set value to true
to activate the job.Node name | Value |
---|---|
scheduler | |
config | |
jobs | |
demo | |
params | |
path | /news |
repository | website |
active | false |
catalog | website |
command | activate |
cron | 0 0 * * * * |
description | activate each hour the page news.html |
You can use the Observation module to listen to events in the repository and execute a command in reaction.
Use observation to automate tasks such as publishing newly added assets or sending an email notification when a comment is added.
See Observation module for usage examples.
To query for existing commands:
config
workspace, sql
query language and nt:base
result item type.select * from nt:base where jcr:path like '%/commands/%'
".The result looks like this. Path notation: /modules/moduleName/commands/catalog/command
.
101 nodes returned in 24ms /modules/publishing-core/commands/default /modules/publishing-core/commands/default/publish /modules/publishing-core/commands/default/unpublish /modules/publishing-core/commands/default/activate /modules/publishing-core/commands/default/deactivate /modules/publishing-core/commands/versioned /modules/publishing-core/commands/versioned/publish /modules/publishing-core/commands/versioned/publish/version /modules/publishing-core/commands/versioned/publish/publish /modules/publishing-core/commands/versioned/unpublish /modules/publishing-core/commands/versioned/unpublish/version /modules/publishing-core/commands/versioned/unpublish/unpublish /modules/publishing-core/commands/versioned/activate /modules/publishing-core/commands/versioned/deactivate /modules/rest-services/rest-endpoints/commands/enabledCommands /modules/rest-services/rest-endpoints/commands/enabledCommands/activate /modules/rest-services/rest-endpoints/commands/enabledCommands/activate/access /modules/rest-services/rest-endpoints/commands/enabledCommands/activate/access/roles /modules/rest-services/rest-endpoints/commands/enabledCommands/markAsDeleted /modules/rest-services/rest-endpoints/commands/enabledCommands/markAsDeleted/access /modules/rest-services/rest-endpoints/commands/enabledCommands/markAsDeleted/access/roles /modules/rest-services/rest-endpoints/commands/enabledCommands/backup /modules/rest-services/rest-endpoints/commands/enabledCommands/backup/access /modules/rest-services/rest-endpoints/commands/enabledCommands/backup/access/roles /modules/ui-framework/commands/default /modules/ui-framework/commands/default/importZip ....
Use the Groovy console to execute command business logic manually, in ad hoc fashion. This is a quick way to test a custom command before you compile it as a Java class. Both of the two options below publish the page /travel/about/careers
. You can test it by making a small change on the careers page, executing the Groovy commands, and viewing the modified history page on the public instance.
Issue the following commands in the console:
Option A - Calling the info.magnolia.commands.CommandsManager.executeCommand()
:
map = new java.util.LinkedHashMap<String, String>() map.put("path", "/travel/about/careers") map.put("repository", "website") cm = info.magnolia.commands.CommandsManager.getInstance() cm.executeCommand('default','publish',map)
Option B - Passing a SimpleContextobject
to the execute()
method:
cm = info.magnolia.commands.CommandsManager.getInstance() command = cm.getCommand('activate') command.setRepository('website') command.setPath('/travel/about/careers') command.setRecursive(true) command.execute(new info.magnolia.context.SimpleContext())
You can also save a command as a Groovy script. This is more comfortable than writing and executing one line at a time in the console. Groovy scripts can be run from the dialog used to edit them.
You can write your own custom commands and execute them either on demand or scheduled. For example, you could execute the standard Magnolia sendMail
command when a page is activated. This way you can send an email notification to a user who needs to review the page.
To create a command definition:
Create a commands
folder in the configuration hierarchy of your module.
Create a catalog
subfolder under the commands
folder. Choose a catalog name that characterizes its commands, such as messaging
for commands that send emails and notifications.
class
property. Set its value to the fully-qualified name of the Java class that contains the command logic such as info.magnolia.module.mail.commands.MailCommand
. The Java class should reside inside the module JAR.Node name | Value |
---|---|
modules | |
myModule | |
commands | |
myCatalog | |
myCommand | |
class | com.example.modules.acme.commands.MyCommand |
You don't necessarily need to create a new module if you just want to add a command. You can put the command definition into any existing module and copy the class file to WEB-INF/classes
under the Magnolia webapp. However, it is easier to maintain your own classes, templates and configuration when you organize them in a module rather than leaving them scattered around.
A command is typically implemented as a Java class. You probably want to extend
public class MyCommand extends BaseRepositoryCommand { public boolean execute(Context context) { // Your command logic goes here. } }
See the commands in the
info.magnolia.commands.impl
package for examples.
2 Comments
Rogan Jo
JCR SQL of "
select * from nt:base where jcr:path like '%/commands/%'
" can not be executed.Richard Gange
Make sure to set the query language to sql. It did work for me on our latest demo.
HTH