Exact archive contents and validation
A full archive includes design, content, uploads, installed modules and their templates, imported data, page structure, module instances, settings without the MySQL password, and an export of every table in the current database. manifest.json records format, version, sizes, and SHA-256 checksums. Sessions, Git, nested backups, secrets.json, and the old administrator file are excluded.
The ZIP is created in storage/backups, which must not be reachable over HTTP. Before restoring, the system checks format and version compatibility, a 512 MB ZIP limit and 1 GB expanded-data limit, a maximum of 30,000 files, no absolute paths or .. segments, permitted destination directories, file sizes and SHA-256 checksums, and the MySQL export checksum. A rollback archive is created automatically before changes. The current MySQL credentials and site URL are preserved.
Additional safeguards
Do not grant the MySQL user WITH GRANT OPTION; limit it to the CMS database. Deny web access to storage, src, modules, database, tools, and tests. On nginx, reproduce the deny rules from .htaccess manually. Recommended Apache virtual-host settings are TraceEnable Off, ServerTokens Prod, and ServerSignature Off. The administration panel uses strict PHP sessions, HttpOnly, SameSite=Strict, an ID refresh after login, idle and absolute timeouts, and login-attempt limits. Over HTTPS, the cookie receives Secure.
After an incident, enable maintenance mode, preserve logs and a current archive for investigation, rotate administrator, MySQL, and integration credentials, and update PHP and the server. Then deploy a clean CMS, restore a verified pre-incident backup, and inspect users, roles, templates, and code injections.
Archive contents
A portable FoxCoreCMS backup includes the design, content, uploads, installed modules and templates, page tree, settings, and a MySQL export. Its manifest records the format version, sizes, and SHA-256 checksums. Credentials for the new database are supplied separately during restoration.
Create and restore
Create a full archive in the backup section. Keep at least one copy away from the website server and test restoration in an isolated environment. To restore, upload the ZIP, wait for validation, confirm the action, then check pages, languages, forms, and media.
The system checks the archive format, size and file-count limits, paths within the ZIP, and checksums. Never restore an unverified or manually modified archive.
Secure the installation
- Use HTTPS and a currently supported PHP version.
- Hide errors from visitors and use server logs for diagnostics.
- Use unique administrator and MySQL passwords; restrict database privileges.
- Block direct HTTP access to storage, src, modules, database, and other service directories.
- Do not remove installed.lock, .htaccess, or .user.ini without understanding the effect.
After an incident, preserve logs, rotate passwords and keys, update the server, and restore a clean installation from a verified pre-incident backup.

← Documentation