Cache and Logs

QUIQQER uses runtime data for caches, sessions, temporary files, locks, logs, and generated data. Operators should know when to clear caches and where to look after updates or incidents.

Cache Commands

Run commands from the QUIQQER installation root.

./console clear-cache

Clears the QUIQQER cache.

./console clear-all-quiqqer-cache

Clears cache, temporary data, sessions, locks, and complete QUIQQER cache data. Use this when a normal cache clear is not enough or after larger maintenance work.

./console clear-cache-path --path="cache/path"

Clears one cache path. Use this only when the affected cache path is known.

See Console for the broader maintenance command overview.

When To Clear Cache

Clear cache after:

• package updates
• setup runs that change runtime definitions
• template or asset deployments
• permission or menu definition changes
• web server file regeneration
• moving a system between environments

Avoid clearing more than necessary during high traffic if the site depends on expensive cache warmup.

Cache Backends

Core cache settings are stored in etc/cache.ini.php and are also exposed in the administration cache settings. The selected cache handler is stored below the general section.

Common handler choices are:

Handler	Operational notes
filesystem	Default fallback. The runtime cache directory must be writable by the web server and CLI users.
apc	Uses APC/APCu-style local process cache. Useful only when the PHP runtime supports it.
memcache	Uses configured memcache servers. Requires matching PHP support and reachable servers.
redis	Uses Redis servers from the cache settings. Values can be comma-separated and may include host/port pairs.
mongo	Uses MongoDB through MongoDB\Client. Requires the PHP MongoDB extension and the mongodb/mongodb package.

If a configured handler cannot be initialized, QUIQQER falls back to another available handler and finally to filesystem cache. Treat cache driver errors in the logs as operational problems even when the system continues to run.

Redis Cache

Redis can be used for normal cache, long-term cache, and sessions. These are separate configuration areas:

Area	Setting
Normal cache	cache.ini.php, general.redis
Long-term cache	cache.ini.php, longtime.redis_server
Sessions	conf.ini.php, session_redis.server

Use the administration settings to test Redis connectivity when available. After switching a cache area to Redis, clear the affected cache and verify both frontend and administration requests.

MongoDB Cache

MongoDB can be used for normal cache and long-term cache. Core settings expose host, database, collection, username, and password for both areas.

Required runtime support:

• PHP MongoDB extension
• mongodb/mongodb Composer package
• reachable MongoDB server from PHP-FPM and CLI

MongoDB hosts without a protocol are treated as mongodb://... by the cache driver. Use separate collections for normal cache and long-term cache when both are enabled.

Long-Term Cache

Long-term cache is configured separately from the normal runtime cache. It can use file, Redis, or MongoDB storage.

Use long-term cache for data that should survive normal cache clears. When changing its backend, clear the long-term cache explicitly and verify features that depend on persisted cached data.

Logs To Check

After an update or deployment, check:

• QUIQQER system logs
• setup and update logs
• PHP error logs
• web server access and error logs
• package-specific logs when installed packages provide them

Use timestamps from the maintenance window to separate new errors from older log entries.

Runtime Directory Health

Runtime directories must stay writable by the web server and CLI user used for maintenance commands. Permission mismatches usually appear as failed cache writes, session problems, update failures, or missing generated files.

If a command works in the shell but the web interface fails, compare the CLI user with the web server user and review ownership of runtime data.

See Configuration for cache and runtime settings.

Troubleshooting Patterns

Use these checks for common operational failures:

Symptom	Check
Cache writes fail	Runtime directory ownership, selected cache handler, PHP extension availability, cache server reachability.
Login behaves inconsistently	Session backend, Redis/memcached/database availability, PHP-FPM and CLI using the same configuration.
Changes are not visible	Clear normal cache, template cache, and package-specific caches where applicable.
Update/setup fails after package changes	Check setup/update logs, run setup again, then inspect PHP and web server logs.
Cache server change has no effect	Verify etc/cache.ini.php, administration settings, and whether the correct cache area was changed.