Admidio command-line interface

The Admidio command-line interface (CLI) provides a scriptable administrative interface to Admidio directly from a shell.

The executable is located in the top-level Admidio directory and is called admidio. It is executed from a shell in the Admidio installation directory:

www-data@server.example.com:~/html$ ./admidio status
Organization: TEST
Filesystem:   5.1.0 Beta 1
Database:     5.1.0-Beta.1
Update step:  620
Status:       OK

The CLI uses the same Admidio entities, services, permissions, organization context and database as the web application. It is therefore suitable both for interactive administration and for automation without duplicating Admidio business logic in external scripts.

Typical use cases include:

• checking the Admidio version, installation status and update availability;
• installing Admidio without using the browser-based installer;
• reading and changing organization preferences;
• creating, inspecting and maintaining users, groups, memberships, lists and permissions;
• maintaining registrations, user relations and profile fields;
• maintaining categories, menus, announcements, forums, links and messages;
• importing, exporting and maintaining inventory data;
• maintaining events and rooms;
• working with documents, files and photo albums;
• inspecting changelog and category-report data;
• administering plugins, SSO clients and SSO keys;
• invalidating and cleaning sessions and auto-login data;
• creating database backups and running maintenance operations;
• using Admidio from maintenance scripts, cron jobs and deployment systems;
• connecting other applications to Admidio through a scriptable administrative interface.

For the exact list of commands, arguments and command-specific options see the CLI command reference.

Developers who want to add CLI commands to an Admidio module should see Adding CLI commands to Admidio modules.

Most commands operate on an existing Admidio installation. For those commands you need:

• an installed Admidio instance;
• PHP CLI;
• the PHP extensions required by that Admidio installation;
• filesystem access to the Admidio directory and adm_my_files;
• access to the configured Admidio database.

The CLI does not start a browser session and does not require a web server request.

A small set of commands is deliberately available before Admidio has been installed. This allows a new installation to be inspected and created entirely from the command line:

./admidio help
./admidio list
./admidio completion
./admidio cli:selfcheck
./admidio install:check ...
./admidio install:run ...

The examples on this page assume that the current directory is the Admidio installation directory.

On Linux and other Unix-like systems the script can be made executable:

chmod +x admidio
./admidio version

It can also always be started explicitly through PHP:

php ./admidio version

On Windows, use the PHP executable:

php .\admidio version

The command can also be called using an absolute path. This is recommended for cron jobs and other automation:

/usr/bin/php /var/www/admidio/admidio status

The general syntax is:

admidio [global-options] COMMAND [arguments] [options]

For example:

./admidio user:show john.doe --as=administrator --format=json

A command consists either of a simple name such as:

version
status
help
list
completion

or a namespace and task:

user:add
group:adduser
inventory:export
sso:list

Global options can be placed before or after the command. Command-specific options must be placed after the command because the CLI cannot know them before it has identified the command.

Both of these forms are valid:

./admidio --organization=club user:list --as=administrator --format=json
./admidio user:list --organization=club --as=administrator --format=json

Long options that take a value accept both –name=value and –name value. The = form is usually clearer in scripts.

The separator – stops option parsing. This is useful when a positional argument itself begins with a hyphen.

To display the general usage, global options and exit codes:

./admidio help

The following are equivalent shortcuts:

./admidio --help
./admidio -h

To list all registered commands:

./admidio list

Commands of one namespace can be listed separately:

./admidio list user
./admidio list inventory
./admidio list sso

The list also shows whether a command is an alias and whether it is currently available.

To show the documentation for a specific command:

./admidio help group:adduser

You can also use:

./admidio group:adduser --help
./admidio group:adduser -h

To inspect the namespaces and tasks represented in the registry:

./admidio module:list
./admidio module:tasks
./admidio module:tasks inventory

The complete generated command documentation is available with:

./admidio help --all

It can be rendered directly as Markdown, DokuWiki or JSON:

./admidio help --all --format=md
./admidio help --all --format=dokuwiki
./admidio help --all --format=json

The CLI command reference is generated from the same registry metadata, for example:

./admidio help --all --format=dokuwiki --output=cli-commands.txt

Therefore the generated page should correspond to the installed Admidio version, including commands supplied by modules.

Current limitation: the generated command metadata and therefore the generated CLI command reference are currently available in English only. This is a known CLI limitation. Translated overview/developer pages should link to the English command reference until CLI help localization is implemented.

The following options control the CLI itself.

Not every global output option has a meaningful effect for every command. Always use admidio help COMMAND when scripting a specific operation.

Many commands require an acting Admidio user:

--as=USER

USER can be a user UUID, numeric user ID or unique login name.

For example:

./admidio user:list --as=administrator

Important: –as is not a password login.

The CLI is a local administrative interface. A person or service account that can execute the CLI and read the Admidio configuration/database can select an Admidio account as the acting identity. Operating-system permissions around the Admidio installation are therefore an important security boundary.

The selected Admidio account must nevertheless be usable. An acting user must:

• be activated;
• be an active member of the current organization.

Admidio then applies the normal authorization model to the command. The exact check depends on the operation:

• read-only commands can require that the corresponding component is visible and then apply the normal record-level visibility rules;
• mutating commands normally require administration rights for the corresponding component;
• some commands use more specific group/member or object rights;
• some operations additionally require a full Admidio administrator.

The command-specific help states additional declared requirements where applicable.

The acting user also becomes the current Admidio user for normal entity and changelog processing. CLI changes are marked with an origin such as:

CLI: group:adduser

Do not use an administrator identity unnecessarily. For automated tasks, use an activated Admidio account with only the permissions required by the task.

For installations with several organizations, use:

./admidio --organization=club-a user:list --as=administrator

The value is the organization's Admidio short name.

The option changes the organization context before the CLI initializes organization-dependent Admidio objects and preferences.

The acting user selected with –as must be an active member of the selected organization.

Some installations use $_SERVER['HTTP_HOST'] in adm_my_files/config.php to select different database or environment settings.

There is no HTTP request when the CLI starts, so the desired host can be supplied explicitly:

./admidio --host=members.example.org status

The same value can be supplied through the environment variable ADMIDIO_HOST:

export ADMIDIO_HOST=members.example.org
./admidio status

The value must be a host name, optionally including a port, for example:

members.example.org
members.example.org:8080

Do not include a URL scheme or path.

This option selects the configuration environment. It is not the hostname of a phpMyAdmin installation or another database administration interface.

Different commands support different output formats. Use command-specific help to see the exact formats accepted by a command:

./admidio help sso:list

Formats used by CLI commands include:

Not every command supports every format.

A normal table is useful for short lists:

./admidio sso:list --format=table --as=administrator

For objects with many fields, the record format is easier to read:

./admidio sso:list --format=record --as=administrator

Example:

type: saml
id: 2
uuid: 2b8618d0-...
client_id: intranet
name: Intranet SAML
enabled: yes

type: oidc
id: 3
uuid: 90c9777a-...
client_id: wiki
name: Wiki
enabled: yes

For scripts, use JSON wherever possible:

./admidio user:list --format=json --as=administrator

If –format=json is present and the CLI fails, the error is also written as structured JSON to standard error. A failure contains the error message, exception type and exit code. This makes it possible for automation to handle errors without parsing human-readable text.

Mutating commands that only have a success confirmation also return a JSON object when –format=json is requested.

Commands using normal CLI output can write it directly to a file:

./admidio config:list --format=json --output=preferences.json --as=administrator

Commands that generate an export or backup also use –output. Depending on the command, the value can be an explicit filename or a destination directory for the command's natural filename.

For example:

./admidio database:backup \
    --output=/srv/backups/admidio.sql.gz \
    --as=administrator

Always check:

./admidio help COMMAND

before using output paths in an automated script.

Scripts should always inspect the process exit code.

Do not treat every non-zero code as the same type of failure. For example, exit code 4 from update:check is a successful check whose result is “an update is available”.

A new Admidio installation can be checked and created without opening the browser installer.

First validate the database connection, installation values and prerequisites:

./admidio install:check [options]

Then run the installation:

./admidio install:run [options] --yes

If values are missing and interaction is allowed, the CLI asks for them. With –no-interaction, every required value must be provided as an option.

A typical non-interactive invocation provides:

• database type, host, database name and database user;
• database password, preferably through stdin;
• Admidio root URL;
• organization short name, name and administrator email;
• administrator login, first name, last name, email and password;
• optional table prefix, language and timezone.

For example:

{
    printf '%s\n' "$ADMIDIO_DB_PASSWORD"
    printf '%s\n' "$ADMIDIO_ADMIN_PASSWORD"
} | ./admidio install:run \
    --db-type=mariadb \
    --db-host=localhost \
    --db-name=admidio \
    --db-user=admidio \
    --db-password-stdin \
    --root-url=https://www.example.org/admidio \
    --timezone=Europe/Berlin \
    --organization-shortname=EXAMPLE \
    --organization-name="Example Organization" \
    --organization-email=info@example.org \
    --admin-login=admin \
    --admin-first-name=Anna \
    --admin-last-name=Admin \
    --admin-email=anna@example.org \
    --admin-password-stdin \
    --no-interaction \
    --yes

When both database and administrator passwords are read from stdin, the database password is the first line and the administrator password is the second line.

Run install:check with the same values first when provisioning a production installation.

The generated command reference is the authoritative list, but the CLI currently covers the following main areas:

• general help, command listing, version/status, shell completion and CLI self-check;
• installation, update checks, system information, database backup, email test, adm_my_files protection and maintenance;
• preferences and organizations;
• users, registrations, user relations, profile fields, groups, memberships, saved lists and permissions;
• categories and menu entries;
• announcements, forums, links and messages;
• documents/files and photo albums;
• inventory fields, items, imports, exports and checkout/return operations;
• events and rooms;
• category reports and changelog inspection;
• plugins, SSO clients/keys, sessions and auto-login cleanup;
• module/namespace inspection.

Use:

./admidio list NAMESPACE

to see the exact commands in one area.

./admidio version
./admidio status

status compares the Admidio source with the database core version and reports the current organization and database update state.

It returns exit code 3 if the state is not OK.

Example:

./admidio status --format=json > /tmp/admidio-status.json
code=$?
 
if [ "$code" -ne 0 ]; then
    echo "Admidio status requires attention (exit $code)." >&2
fi

Capture the exit code immediately after the command before running another shell command.

./admidio update:check --as=administrator

For automation:

./admidio update:check --format=json --as=administrator

Exit code 4 means that a newer release is available.

The CLI can validate its registry, generated help and internal CLI source consistency:

./admidio cli:selfcheck

For CI or other automation:

./admidio cli:selfcheck --format=json

A problem is reported with exit code 3.

This self-check validates the CLI infrastructure. It does not replace behavioral tests of the underlying Admidio domain operations.

Bash and Zsh completion scripts can be generated from the command registry:

./admidio completion bash > /etc/bash_completion.d/admidio

or:

./admidio completion zsh > "${fpath[1]}/_admidio"

Commands that are registered as unavailable are omitted from completion.

List all preferences:

./admidio config:list --as=administrator

Search preference names:

./admidio config:list --filter=events --as=administrator

Read one value:

./admidio config:get system_language --as=administrator

Change one value:

./admidio config:set events_module_enabled 1 --as=administrator

Before changing preferences through scripts, verify the setting name and accepted value in the normal Admidio configuration and command help.

./admidio user:list --as=administrator
./admidio user:show john.doe --as=administrator

Use the record format for a readable full object where that format is supported:

./admidio user:show john.doe --format=record --as=administrator

Use JSON for automation:

./admidio user:show john.doe --memberships --relations --format=json --as=administrator

Admidio profile fields are configurable. User data is therefore supplied using the internal profile-field names:

./admidio user:add \
    --login=john.doe \
    --field=FIRST_NAME=John \
    --field=LAST_NAME=Doe \
    --field=EMAIL=john@example.org \
    --as=administrator

The configured profile fields can be inspected with:

./admidio profile:fields --as=administrator

A user can immediately be assigned to groups:

./admidio user:add \
    --login=john.doe \
    --field=FIRST_NAME=John \
    --field=LAST_NAME=Doe \
    --group=Members \
    --as=administrator

If a command accepts a password or another secret, prefer its *-stdin option over putting the secret in shell history.

Assign an existing user:

./admidio group:adduser Members john.doe --as=administrator

Assign the user for a defined period:

./admidio group:adduser Board john.doe \
    --start=2026-09-01 \
    --end=2027-08-31 \
    --leader=yes \
    --as=administrator

End the current membership:

./admidio group:deluser Board john.doe --as=administrator

Update an existing membership:

./admidio group:updateuser Board john.doe \
    --leader=no \
    --as=administrator

Normal membership operations preserve Admidio's membership history.

Permanent deletion of a membership-history row is a separate operation:

./admidio group:deletemembership MEMBERSHIP_UUID --as=administrator

It requires confirmation and should only be used deliberately.

Create a database backup:

./admidio database:backup --as=administrator

Write it to a specific destination:

./admidio database:backup \
    --output=/srv/backups/admidio.sql.gz \
    --as=administrator

Database dumps contain the complete installation data and are protected as private files where the operating system permits it.

Take a backup before larger scripted changes or migrations.

Before importing, preview the resolved mapping without writing data:

./admidio inventory:import-check ./inventory.xlsx \
    --format=json \
    --as=administrator

Import an inventory file:

./admidio inventory:import ./inventory.xlsx --as=administrator

The importer supports explicit mapping when source columns do not correspond to the configured Admidio inventory fields:

./admidio inventory:import ./inventory.csv \
    --input-format=CSV \
    --separator=semicolon \
    --map=ITEMNAME=1 \
    --map=CATEGORY=2 \
    --map=SERIAL_NUMBER=3 \
    --as=administrator

Export inventory data:

./admidio inventory:export \
    --format=xlsx \
    --output=inventory.xlsx \
    --as=administrator

Always use admidio help inventory:import or admidio help inventory:export for the exact file formats and options supported by your installed Admidio version.

Events and rooms can be administered through their CLI command families.

For example, creating an event:

./admidio event:add \
    --headline="Annual meeting" \
    --calendar=General \
    --from="2026-09-14T18:00" \
    --to="2026-09-14T20:00" \
    --location="Club house" \
    --as=administrator

Use:

./admidio list event
./admidio list room

and admidio help COMMAND for the exact event and room operations and options of the installed version.

List all SSO clients:

./admidio sso:list --format=record --as=administrator

Show only SAML clients:

./admidio sso:list --type=saml --format=record --as=administrator

Inspect one client:

./admidio sso:show CLIENT_UUID --as=administrator

SSO keys, SAML metadata, OIDC discovery information and token cleanup can also be administered through the corresponding sso:* commands.

See the command reference for the full list.

The maintenance switch can be queried even when the database is unavailable:

./admidio maintenance:mode
./admidio maintenance:mode status

Enable it interactively:

./admidio maintenance:mode enable \
    --message="Maintenance in progress" \
    --retry-after=300

For deliberate non-interactive use:

./admidio maintenance:mode enable \
    --message="Maintenance in progress" \
    --retry-after=300 \
    --no-interaction \
    --yes

Disable maintenance mode:

./admidio maintenance:mode disable

Maintenance mode has an owner identifier so independent maintenance operations do not silently take over each other's state. Use command help before using –owner or –force in automation.

The CLI is designed to be scriptable.

For reliable automation:

• use absolute paths;
• select the organization explicitly when an installation contains several organizations;
• use a dedicated activated Admidio actor with only the required rights;
• use –no-interaction;
• use –yes only when a destructive or confirmed action is deliberately accepted by the script;
• use UUIDs for long-lived object references where possible;
• use –format=json for machine-readable output;
• parse standard output for data and standard error for errors;
• inspect the process exit code;
• use *-stdin options for passwords and secrets when available;
• avoid parsing table/text output in integrations.

#!/bin/sh
 
ADMIDIO=/var/www/admidio/admidio
ACTOR=automation-admin
 
"$ADMIDIO" status --format=json --output=/tmp/admidio-status.json
status_code=$?
 
if [ "$status_code" -ne 0 ]; then
    echo "Admidio installation requires attention (exit $status_code)." >&2
    exit "$status_code"
fi
 
"$ADMIDIO" group:members Members \
    --format=json \
    --as="$ACTOR" \
    --no-interaction \
    --output=/tmp/admidio-members.json

$Admidio = "C:\inetpub\wwwroot\admidio\admidio"
 
$statusJson = php $Admidio status --format=json
$statusCode = $LASTEXITCODE
 
if ($statusCode -ne 0) {
    Write-Error "Admidio installation requires attention (exit $statusCode)."
    exit $statusCode
}
 
$status = $statusJson | ConvertFrom-Json
 
$users = php $Admidio user:list `
    --format=json `
    --as=automation-admin | ConvertFrom-Json
 
$users | ForEach-Object {
    Write-Host $_.login
}

For cron jobs, call the CLI by absolute path and disable interaction.

Example:

15 2 * * * /usr/bin/php /var/www/admidio/admidio database:backup --output=/srv/backups/admidio.sql.gz --as=backup-admin --no-interaction

Make sure that the operating-system user running the scheduled task has access to:

• the Admidio installation;
• adm_my_files;
• any input/output files used by the task;
• the configured database.

Also make sure that the Admidio account used with –as remains activated and an active member of the selected organization.

The CLI can be used as an administrative boundary between another application or migration script and Admidio.

Instead of writing directly to the Admidio database, an integration can invoke the relevant Admidio command.

For example, an external provisioning script can:

1. create a user with user:add;
2. update profile fields with user:update;
3. assign the user to a group with group:adduser;
4. end a membership with group:deluser;
5. inspect the resulting object through user:show –format=json.

This approach has an important advantage over direct SQL: the command uses Admidio's normal entities, services, permissions, changelog and related update logic.

A typical migration from another membership system could proceed as follows:

1. create a database backup;
2. create or map the required Admidio groups;
3. inspect the configured profile fields with profile:fields;
4. transform source data into the required internal field names;
5. call user:add or user:update for each person;
6. use group:adduser to recreate memberships and their start/end dates;
7. compare the resulting data using user:list, group:members and JSON exports.

For large migrations, first test the complete process against a copy of the production installation.

Many commands allow an object to be referenced by more than one identifier, for example:

• UUID;
• numeric database ID;
• login name;
• group or category name.

Interactive administration can conveniently use names:

./admidio group:adduser Board john.doe --as=administrator

For long-lived integrations, prefer UUIDs where the command accepts them.

Names may be changed and can sometimes be ambiguous. When a selector is ambiguous, the CLI fails rather than silently selecting one object.

Commands that require confirmation ask interactively by default.

For example:

./admidio group:delete OldGroup --as=administrator

For a deliberately automated operation:

./admidio group:delete OldGroup \
    --as=administrator \
    --no-interaction \
    --yes

If a confirmation would be required and –no-interaction is present without –yes, the command fails instead of silently continuing.

Do not add –yes indiscriminately to every automated command. It should show that the script intentionally accepts that operation.

A command can be present in the registry but marked as unavailable when the corresponding web functionality does not yet have a reusable headless operation.

admidio list shows this state, and admidio help COMMAND includes an availability notice.

Shell completion omits commands that are marked unavailable.

Do not work around an unavailable command by manipulating the Admidio database directly. Use the corresponding supported web functionality or wait until the required reusable core operation is available.

The CLI loads adm_my_files/config.php from the Admidio installation.

If that configuration selects an environment based on HTTP_HOST, specify the expected host:

./admidio --host=members.example.org status

or set:

ADMIDIO_HOST=members.example.org

The selected command needs an acting Admidio identity.

Supply an activated user that is an active member of the current organization:

./admidio COMMAND --as=administrator

Remember that –as selects an identity; it does not perform password authentication.

An account used with –as must be activated and currently belong to the selected organization.

Activate/assign the account using normal Admidio administration before using it as an automation actor.

The CLI does not bypass Admidio permissions.

Check:

• the selected organization;
• the acting user;
• whether the relevant component is visible/administrable to that user;
• any object-specific or group/member rights required by the operation;
• whether the command requires a full administrator.

Use the UUID shown by the corresponding list or show command.

Not every format is valid for every command.

Use:

./admidio help COMMAND

to see the exact allowed values.

Read the availability explanation in:

./admidio help COMMAND

The registry intentionally exposes the reason rather than silently offering an incomplete headless implementation.

Module commands are loaded from:

modules/<module>/cli.php

If loading a module's CLI registration fails, the CLI writes a warning to standard error and continues loading the remaining commands. Inspect the warning and then run:

./admidio module:tasks

to see what was registered successfully.

The CLI should be treated as an administrative server interface.

• Restrict shell access to trusted users and service accounts.
• Protect the Admidio source tree and adm_my_files with appropriate filesystem permissions.
• Do not expose the CLI through a web-accessible wrapper.
• Remember that –as is impersonation, not authentication.
• Use a dedicated activated Admidio actor for automated tasks where appropriate.
• Give that actor only the permissions required by the automation.
• Use backups before bulk changes.
• Prefer stdin-based secret input where a command supports it.
• Avoid storing passwords, private keys or other secrets directly in shell scripts or shell history.
• Protect generated backups and secret exports.
• Prefer UUIDs in long-lived integration scripts.
• Use JSON rather than parsing human-readable table output.
• Check exit codes and do not ignore stderr.

The complete command reference is generated directly from the installed CLI:

./admidio help --all --format=dokuwiki

To generate a file suitable for the DokuWiki page:

./admidio help --all --format=dokuwiki --output=cli-commands.txt

See CLI command reference.

Because that page is generated directly from the command registry, it should be considered the authoritative description of command arguments, options, aliases, declared rights and availability for a particular Admidio version.

The generated command reference is currently English-only because CLI help metadata is not yet localized.