ForgeKit v1.7: Big Chungus

When a bug report becomes a workflow

Early on, a user named Derek started testing ForgeKit against real legacy projects rather than clean demo sites. That surfaced problems a fresh install never would. He emailed me at forgekit.tools@gmail.com, and we went back and forth for a bit, working through each issue he ran into as he found it.

Large SQL imports through phpMyAdmin were failing with a maximum execution time error. The phpMyAdmin runtime's own configuration and logs were hard to reach. The database server's my.ini and error log weren't visible from anywhere near the phpMyAdmin workflow. Clicking Download twice in the updates modal could start two downloads at once. And old Apache 2.2 .htaccess rules, the allow from and deny from syntax that a lot of older WordPress installs still carry, were throwing HTTP 500 errors under Apache 2.4.

None of these stayed as small, isolated patches. Fixing the timeout on large imports raised an obvious follow-up question: even with a longer timeout, uploading a multi-hundred-megabyte SQL file through a browser form is the wrong workflow. So phpMyAdmin got a server-side Large Imports folder instead: drop a file in directly, then pick it from the Import tab.

That single fix pulled the rest of the panel along with it. phpMyAdmin now has its own runtime controls (start, stop, restart), quick-open access to its configuration and log files, and visibility into the connected database server's my.ini and error log, all from the same place. The database panel picked up a Logs dropdown next to Config for quick access to mysql-error.log. MySQL and MariaDB settings got tuned for faster imports and exports. The updates modal now blocks duplicate downloads outright. And Apache instances enable mod_access_compat by default, so that legacy .htaccess syntax works instead of failing.

The redesigned phpMyAdmin panel: runtime controls, quick-open config and log files, and a Large Imports folder for multi-gigabyte SQL dumps.

I've probably thanked Derek a dozen times in our emails. Well here's another one. Thanks man!

Making the foundation ready for automation

ForgeKit's UI mostly serialises what you do. You start an action, a loader blocks anything else, the backend finishes or fails, the loader clears. That pattern makes it unlikely an ordinary user would ever trigger two competing configuration writes through the interface as it exists today.

But while expanding the automated test suite this release, a deterministic test proved that the backend itself wasn't safe if two operations ever did overlap. The unsafe mechanism, in ForgeKit's binary bookkeeping, looked like this:

Operation A reads binaries.yaml
Operation B reads binaries.yaml
Operation A adds an entry and saves
Operation B saves its older copy
Operation A's entry is gone from the final file

The actual binary files would still be sitting on disk. The state file just wouldn't know about one of them any more. That's a real, provable flaw in the persistence code, not something I'd traced to a widespread incident in the wild. It needed a mutex, but only around the fast bookkeeping step, not the slow download and extraction happening beside it:

Download and extract                     run concurrently
Load, merge or remove, save bookkeeping  protected by a mutex

That test prompted a wider look at ForgeKit.yaml itself, the file holding sites, web server and database instances, ports, preferences, and most other application state. Over time the codebase had accumulated several different ways of reading and writing it: sites had their own load-change-save path, instances had another, preferences had a third, and other parts of the app mutated a cached copy and called a plain Save() directly. Nobody set out to build four ways to save the same file. It happened because each feature was added at a different time, and each one had its own reasonable-looking local solution.

Every write now goes through one function:

config.Mutate()
lock, load fresh, apply one change, save, sync cache, unlock

Reads use a matching config.Snapshot(). More than a dozen call sites were migrated across sites, instances, preferences, web server control, database control, editor settings, and terminal settings.

The current UI already prevents most of the dangerous overlap. Future entry points, MCP tool calls, a direct API, background diagnostics, automated recovery, won't necessarily be as polite about it. This work moves the guarantee down into the persistence layer itself, rather than leaving it dependent on every caller, present and future, behaving one at a time.