RenewCMS/docs/releases/v3.0.0-beta.md

This release adds an activity log that records who did what on your site, and lets RenewCMS run on MySQL, MariaDB or PostgreSQL and keep uploaded images in an S3-compatible bucket.

New

Activity log

• The new Activity page lists every important action as a plain sentence, newest first, grouped by day: articles created, edited, published or deleted, images uploaded, renamed, merged or purged, accounts and invitations, and the system tasks (scheduled purge, update checks and downloads, restarts).
• Filter by search text, person, category, outcome and date range, with Today, 7 days, 30 days and a custom range. Click a summary card to apply its filter. Open any row to see its details, including what changed.
• Failed actions are recorded with a plain reason, and failed logins and similar events are flagged as security events.
• Owners and admins see everyone's activity, a summary strip (total, active people, failed actions, security events) and can export the filtered list as a CSV file. Any other role would only see its own activity.
• Article bodies are never recorded, only the change in size. Passwords, codes, file contents and storage paths are never recorded either.
• The Home page has a new Recent activity card with the last five events.
• Owners choose how long events are kept in the new Retention card in Settings: 30 days, 90 days (the default), 365 days or forever. Shortening the period asks for confirmation first. Older events are removed automatically once a day, and Settings shows the last cleanup and the next one.
• The new screens are available in English and French.

More ways to run RenewCMS

• Use MySQL 8, MariaDB 11 or PostgreSQL 16 and 17 instead of the local SQLite file by setting DB_DRIVER to mysql or postgres and the DB_* connection variables. SQLite stays the default.
• Keep uploaded images in an S3-compatible bucket (AWS S3, MinIO, Ceph, Cloudflare R2, Backblaze B2 and similar) by setting STORAGE_DRIVER=s3. Image URLs do not change and the bucket stays private.
• The update backup taken before a download now works with every database: SQLite as before, and a logical dump for MySQL, MariaDB and PostgreSQL. The newest 3 backups are kept.
• Docker Compose files for each setup are included: docker-compose.mysql.yml, docker-compose.postgres.yml and docker-compose.s3.yml.

API

• GET /v1/activity returns the filtered, paged events as { items, total, page, size }, newest first. It accepts q, actor, category, outcome, security, range, from, to, page and size, and any invalid value answers 400. Owners and admins see every event. Any other role only sees its own, and asking for another actor answers 403.
• GET /v1/activity/summary returns the counts for the range, the previous period, the active people and a seven-bucket series. Owners and admins only.
• GET /v1/activity/export returns the same filters as a CSV attachment (when,actor,action,target,outcome,source,ip). Owners and admins only. Cells that start with =, +, - or @ get a leading quote.
• The three routes accept a session only: an API key answers 403 with "This action needs a real session."
• There is no POST, PUT, PATCH or DELETE under /v1/activity. Events can only be removed by the retention period.
• GET /v1/settings now also returns activity_retention_days, activity_last_cleanup_at, activity_last_cleanup_removed and activity_next_cleanup_at.
• PATCH /v1/settings accepts activity_retention_days with 0 (forever), 30, 90 or 365. Session and owner only, with 403 "Only the owner can do this." for anyone else. Any other value answers 400.

Under the hood

• Decouple persistence and image storage behind driver registries: persistence/database for the SQL drivers and internal/infrastructure/storage for the image adapters, with the domain image.Storage port. Repositories no longer touch files.
• Add the audit domain, an append-only repository, a recorder that never fails or blocks the caller, and the use cases that record events from inside each action.
• Add a scheduler for the activity cleanup, which runs once a day at or after 03:00 server time, alongside the media purge scheduler.
• Add the activity, Home card and Retention card specifications and QA procedures to features/, the new screens to docs/design/, and Go and Vitest suites for each part.
• Document the new variables in docs/configuration.md, and the new setups in docs/deployment.md and docs/docker.md.

Upgrading

• Replace the binary, or pull the new image. The activity tables are created automatically at startup.
• New environment variables are all optional and default to the previous behaviour: DB_DRIVER (sqlite), STORAGE_DRIVER (local), DATA_DIR (the directory of DB_FILE), and the DB_* and S3_* variables listed in docs/configuration.md. An existing install needs no change.
• Activity starts recording after the upgrade, and nothing earlier is added. The first cleanup applies the default retention of 90 days, so owners who want a longer history should change it in Settings.
• There is no automatic migration between databases or from the upload directory to a bucket. To move, follow the steps in docs/configuration.md and docs/deployment.md.
• Backups taken before an update cover the database only. With S3, back the bucket up with your provider.