Bonumark Stream v0.7.2

Bonumark Stream v0.7.2

Hosting Portability & Upgrade Workflow

Bonumark Stream v0.7.2 is the next public release after v0.6.0.

v0.6.0 was a major product pass. It added first-class Profiles, Theme Architecture 2.0, the rebuilt Midnight Ledger theme, stronger Profile media delivery, and tighter rendering and SEO boundaries.

v0.7.2 focuses on a different part of the product: what it takes to actually run Bonumark Stream safely on real hosting.

The biggest change is that Bonumark no longer assumes the PHP/web process should own or replace application code. Shared hosting is still supported, but a VPS or other locked-down installation can now keep the application tree protected while giving PHP write access only to the runtime paths Bonumark actually needs.

That change led to a larger deployment and upgrade overhaul: owner-run CLI upgrades, a shared upgrade engine, read-only deployment verification, explicit database compatibility targets, maintained Nginx guidance, safer migration recovery, and a real GitHub Actions compatibility matrix.

What changed since v0.6.0

Locked-down hosting is now a first-class deployment model

Bonumark Stream now separates runtime writability from application-code replacement.

The application can continue publishing posts, uploading media, importing content, running scheduled work, storing revisions, and using its normal runtime directories even when PHP is intentionally unable to modify package-managed application files.

That matters on a properly configured VPS. You should not have to make the entire application writable by the web server just so an updater can replace code.

Bonumark now supports both models:

• Managed or shared hosting where PHP can safely perform application upgrades.
• Locked-down hosting where application code remains owned by the site owner or deployment account and PHP only receives the runtime permissions it needs.

Two upgrade paths now use one upgrade engine

The familiar Admin → Upgrade workflow remains available on hosts where PHP can safely replace application files.

For locked-down servers with shell access, v0.7.2 adds the owner-run CLI workflow:

php scripts/deploy-update.php /path/to/bonumark-stream-release.zip

Both paths now use the same core upgrade engine. That means the browser-based and CLI workflows share the same rules for:

• Release-manifest and package validation
• Owner-data preservation
• Private software backups
• Obsolete package-file cleanup
• Pre-migration rollback boundaries
• Migration locking and recovery
• Upgrade-history recording

The CLI updater does not call sudo, install a privileged service, use setuid behavior, or make the PHP process more powerful. It runs as the application owner and keeps the existing permission boundary intact.

For older locked-down installations that do not yet contain deploy-update.php, the helper can also be run from an extracted newer release with --site-root=/path/to/live/site for the first transition.

Upgrade failure and recovery behavior is safer

The upgrade system now tracks what it actually changed instead of treating rollback as a broad copy-back operation.

Before migrations begin, Bonumark can restore or remove only the package-managed software changed by that upgrade attempt. Once migration work may have started, recovery stays forward-oriented toward the target release instead of casually rolling application code backward against a newer database state.

The owner-run CLI workflow also requires explicit database-backup confirmation when pending migrations are part of an upgrade and rechecks the validated release ZIP before installation so the package cannot be silently swapped during the confirmation window.

Bonumark can verify an installed deployment

v0.7.2 adds scripts/deployment-check.php, a read-only CLI verification tool for installed sites.

It can check:

• Application version markers
• Package-managed file integrity
• Obsolete package files left behind by overlays
• Required runtime directories
• Database family and compatibility
• Pending migrations
• Migration-recovery state

The owner-run updater automatically runs deployment verification after a successful upgrade.

Admin → System Check remains the authority for checks that depend on the actual web/PHP identity, such as live writability, automatic-upgrade capability, theme ZIP installation capability, and HTTP protection.

Diagnostics are safer and more useful

Several checks were reworked so diagnostics do not need to mutate the installation just to determine whether it is healthy.

Private-path verification now uses a known private marker instead of creating a temporary probe file. Public URL testing performs a real read-only request to Bonumark's /api/v1/status route instead of reporting success without proving clean routing actually works.

Top-level PHP utilities under /scripts are also protected as CLI-only tools.

Nginx is now a documented deployment target

Apache and LiteSpeed remain supported through the included .htaccess rules, but v0.7.2 adds maintained Nginx documentation and a reference configuration covering:

• Bonumark clean-route rewrites
• Private _bonumark_stream/ and /scripts protection
• Authorization header forwarding
• Prevention of PHP execution from media paths
• Upload request sizing

Manual software and theme deployment are also documented for installations where PHP cannot replace application or theme files.

Hosting capabilities are detected instead of assumed

Bonumark now reports optional hosting capabilities individually instead of treating every missing convenience as a broken installation.

System Check and installation diagnostics can report:

• Web server family
• cURL availability
• ZipArchive availability
• GD/Imagick image-processing support
• Theme ZIP installation capability
• Automatic application-upgrade capability
• Effective upload ceilings

The project also removed fatal assumptions around mbstring by routing affected text operations through guarded fallbacks.

The result is a clearer distinction between what Bonumark requires to run and which optional features the current host can support.

Database compatibility is explicit and tested

Bonumark Stream now documents these compatibility floors:

• PHP 8.1+
• MySQL 8.0+
• MariaDB 10.6+

Fresh installation checks the detected database family and version before site creation. Existing installations can see that compatibility information through System Check and deployment verification.

The repository now includes a GitHub Actions compatibility matrix that tests:

• PHP 8.1 / MySQL 8.0
• PHP 8.1 / MariaDB 10.6
• PHP 8.3 / MySQL 8.4
• PHP 8.3 / MariaDB 11.4

Each job runs PHP lint, the clean-package smoke test, database schema and migration verification, and the Remote Posting API database smoke test.

The final v0.7.2 source passed all four combinations before release preparation was completed.

Fresh installs and historical upgrades are now tested separately

The release-candidate process exposed an important flaw in the original database smoke test.

The old test treated Bonumark's current cumulative fresh-install schema like a historical installation, then replayed every older migration on top of it. That eventually tried to create database structures that already existed in the current schema.

v0.7.2 fixes the test model instead of hiding those duplicate-column errors.

Database verification now exercises two real paths independently:

1. A current fresh installation using Bonumark's real current schema installer.
2. A historical supported upgrade starting from a verified v0.4.x schema fixture and applying the migrations that follow it.

That makes the compatibility matrix a better test of how Bonumark is actually installed and upgraded.

What this means in practice

The visible publishing experience is intentionally not the focus of this release. Profiles, Theme Architecture 2.0, Midnight Ledger, publishing, comments, likes, media, Pages, and the existing database content model continue from v0.6.0.

What changed is the operational foundation underneath them.

Bonumark Stream can now live comfortably on a conventional shared host or a more tightly controlled VPS without forcing both environments into the same permission model. The application can tell the difference between a missing optional capability and a real deployment problem. Upgrades have a supported owner-run path. Deployment state can be verified before and after changes. Database compatibility is documented and exercised automatically instead of being assumed.

For a self-hosted publishing system, that is an important step forward.

Upgrade impact

v0.7.2 adds no new database migration compared with v0.6.0. The migration set still ends at 0017_profile_photos.php.

The supported upgrade floor remains v0.4.0. Installations older than v0.6.0 may still have earlier migrations to apply when upgrading directly to v0.7.2.

Owner data remains outside normal package replacement, including configuration, database content, posts, Pages, drafts, scheduled posts, revisions, comments, accounts, media, uploads, settings, analytics, API state, scheduled-task history, Local Places, custom themes, imports, backups, and content versions.

As always, back up the database and site files before upgrading a production installation.

Release summary

Bonumark Stream v0.7.2 takes the project from "it can run on different hosts" to a much more deliberate self-hosting model.

It keeps the convenience of browser-based upgrades where they make sense, adds an owner-run path where they do not, strengthens the permission boundary around application code, improves deployment verification and recovery, adds maintained Nginx guidance, formalizes database compatibility, and continuously tests those assumptions against MySQL and MariaDB.

The goal is simple: Bonumark Stream should be portable without requiring sloppy permissions, and maintainable without giving the web process more control than it needs.