Garbage Collection & Data Retention
A common issue with legacy CMS platforms over time is "Data Bloat." Revisions pile up indefinitely and deleted images leave orphaned files on the server, eventually degrading I/O performance and increasing backup sizes.
Pragma CMS follows a Manual-First Garbage Collection (GC) philosophy. Instead of running unpredictable background tasks that could spike CPU usage during peak traffic, we provide administrators with explicit tools to prune the system via the Maintenance dashboard.
1. Controlled Revision Retention
Pragma CMS does not store infinite history by default. While content versioning is vital, keeping every minor save from three years ago is unnecessary. The architecture is designed to support a rolling retention window. Administrators can purge old revisions (typically older than 30 days) to keep the entry_revisions table lean and its indexes high-performing.
2. Orphaned Resource Scanning
When a media entry is deleted from the database, the physical file might remain if the process was interrupted or if the file was used across multiple extensions. Pragma includes a specialized Orphan Scanner that performs a differential analysis between the /media/source directory and the database state. This allows for safe, verified reclamation of disk space.
3. Log Rotation & Truncation
System performance is often throttled by massive, multi-gigabyte log files. Our architecture treats logs as ephemeral diagnostic data. Pragma allows for easy truncation of application.log and PHP error logs directly from the Admin panel, preventing the filesystem from reaching storage or inode limits.
4. Database Bloat Prevention (By Design)
Unlike legacy platforms that store every session or security token as a new row in the database (creating massive table fragmentation), Pragma CMS manages tokens within existing user records.
- Session Management: Handled by the native PHP session engine, keeping the database free of transient traffic data.
- Token Hygiene: Security tokens (Remember Me, Password Resets) are updated in-place. This architectural choice eliminates the need for complex session purging tasks and keeps the database footprint constant and predictable.