Setup

Update

To update configuratorware it is necessary to have a valid licence installed.

The update is a 2-step process:

• Update the api and database

• Update or rebuild the frontendgui and admingui

Api and Database

For each update, it is recommended to first backup the database before upgrading. To update the api and the database run via shell from the project directory: composer update-configuratorware

Make sure to read the upgrade notes for the version you’re about to install. Deprecations, breaking changes, updated dependencies and other version specific changes are documented there:

• Version 1.15

• Version 1.16

• Version 1.17

• Version 1.18

• Version 1.19

• Version 1.20

• Version 1.21

• Version 1.22

• Version 1.24

• Version 1.25

• Version 1.27

• Version 1.28

• Version 1.29

• Version 1.31

• Version 1.32

• Version 1.33

• Version 1.35

• Version 1.38

• Version 1.42

• Version 1.45

• Version 1.49

• Version 1.50

• Version 1.51

• Version 1.52

• Version 1.54

• Version 1.56

• Version 1.57

• Version 1.58

The latest upgrade notes can also be found in the vendor folder in your configuratorware based project: vendor/configuratorware/configurator-api/UPGRADE-<VersionNumber>.md

frontendgui and admingui

If there is no customizing in frontend projects it’s possible to use prebundled frontends by running: bin/console configuratorware:download-frontend-apps [argument]

This command downloads a ready to use version of the configuratorware frontendgui and admingui and can be run with the following different arguments:

• frontendgui to update only the frontendgui

• admingui to update only the admingui

• frontendgui+admingui to update both

For customized frontends it is necessary to setup a build process to create bundled versions.

Server check

Checks whether the server can run configuratorware, e.g. after an update or a server change.

Open /admin/server-check in the admin area, logged in as a user with the settings credential. The page is not linked in the menu. It shows the report of GET /api/system-check as JSON:

• ready: false if a required check failed, the API then answers with HTTP 503

• checks: one entry per check with status (ok, warning, failed or skipped) and message

Query parameters, for the admin page and the API:

• mode: creator, designer or creator+designer (default); the designer checks only run when the designer is part of the mode

• features: optional checks, comma-separated: vectorize, printfile, weasyprint, s3, openai

Invalid values for mode or features are answered with HTTP 400, users without the settings credential get HTTP 401.

Example: /admin/server-check?mode=designer&features=vectorize,s3

Without the admin area:

TOKEN=$(curl -s -X POST 'https://<host>/api/login_check' -H 'Content-Type: application/json' \
  -d '{"username":"<admin>","password":"<password>"}' | jq -r .token)
curl -s -H "Authorization: Bearer $TOKEN" 'https://<host>/api/system-check?mode=designer&features=vectorize' | jq

A run can take a few minutes, mainly in designer mode and with s3 or openai. The endpoint allows itself 10 minutes; shorter timeouts of the web server, proxy or PHP-FPM (e.g. fastcgi_read_timeout, request_terminate_timeout) abort it with a gateway error.

Before the application is installed, tools/server-check.php runs the checks that don’t need the application, see the comment at the top of that file.