szabesz

Even with AI-aided development processes, one only has 24 hours in a day, so sooner or later even @maximus will not be able to support that sheer number of modules of his. By paying for someone else's module one can (hopefully) save time, therefore in the end rendering the end result for the client cheaper. At least that is when it IS worth paying for a module, and AI will (hopefully) never read our mind, so we will always need to spend time to produce good quality results even when relying on AI-driven solutions. Plaid modules are welcome, when they bring good value for money. The just need to come with perpetual fallback licenses and surely NOT with a subscription lock.

On my end, it is 403 all the time.

Interesting discussion, let me add my own experiences. I asked Opus 4.8 to explain how "she" and I solved it. I have been using the following method for a few weeks now and found it to be a solid solution for AI-aided ProcessWire development. This is the exact problem we've spent months building around, and your one-liner ("the production database is not a deployable artifact") is almost word-for-word the sentence at the top of our own rules. Since Ivan asked for mechanics rather than concepts, here's the concrete shape of what we run. A word on what "our setup" actually is, since it isn't a module you install: it's a handful of small command-line tools, each doing one job, that a human and an AI agent drive exactly the same way. Two of them are ours: one stamps the local/production split onto a site (the environment flag, credentials, local mail rerouting), and one handles sync and deploy through a short list of verbs, check, snapshot, pull, restore-snapshot, baseline, deploy. The third we don't own at all, the migration and CLI layer is Ryan Cramer's AgentTools module, which applies our migrations and gives full command-line access to the PW API (--at-migrations-apply, --at-eval). They share three habits: every write is dry-run by default and needs an explicit --apply; all configuration lives in files, tracked policy kept separate from git-ignored secrets and connection details, never in the admin; and everything is referred to by name, never by database id. That last habit matters more than it looks: ids can differ between environments, names don't, so a change described by name means the same thing everywhere it's applied. Everything hangs off one idea: state has a direction, and each kind of state is only allowed to move one way. We wrote it as a fixed mapping and treat it as law: Content (pages, field values), copied by database clone, prod → local only Schema (templates, fields, roles, permissions), carried by a migration, local → prod only Module install state + config, carried by a migration, local → prod only Per-environment values + secrets, a git-ignored file, never transferred either way Once content only flows prod→local and structure only flows local→prod, "push the dev database to prod" stops being a mistake you have to remember not to make, it's simply a direction the system doesn't have. Three pieces implement it: 1. A clone-proof environment flag, file state, not DB state. Your incident is one half of the danger; the mirror image bit us too: a prod→local database copy can make local believe it's production, because "which environment am I?" is usually answered from the database. So we keep that flag in a git-ignored file, never in the DB, a database clone physically can't flip it. The same file holds the DB credentials and salts, and on local it reroutes all outgoing mail to a local catcher (MailHog), so a stray "email every user" from a script can't reach a real inbox. 2. Migrations as the only structural channel, and a git payload before they're a DB payload. We landed on nearly your contract independently: small, idempotent, versioned PHP migrations on the PW API, everything referenced by name never by database id, preview-then-apply. Two lessons I'd add to your list: Because we deploy over git (below), a migration is committed and pushed before it runs. $modules->install() on a module whose files arrived in that same push silently does nothing until you call $modules->refresh() first, and then saveConfig() dies with "Unable to find ID for Module" after the migration already printed success. So: refresh, install, then verify the install actually took instead of trusting the return value. This maps straight onto your "installed modules" guard: module install state lives in the modules table, it is database state. So every prod→local pull overwrites local's install states with production's, and you can't maintain different module sets per environment without fighting the core. Dev-only tools can't ride a migration either: the applied-migrations registry is itself in the database, so a migration marked "applied" on prod travels back down on the next pull and is then never re-applied locally. We re-activate dev-scope modules with a separate idempotent "baseline" step after every pull, and it never uninstalls anything. 3. docroot-as-repo deploy, with the two foot-guns bolted shut. Deploy is a git push into a non-bare repo whose working tree is the live web root (receive.denyCurrentBranch = updateInstead). Simple, and it has exactly two sharp edges, both turned into hard stops rather than reminders, because in the AI era the rule has to live in config and permissions, not in someone's head: A reflexive git push is a live deploy. So git config push.default nothing, a bare git push now exits 128. Deploy only happens through the explicit tool call. The error is the feature; we never "fix" it by removing the setting. A write from the production admin wedges every future deploy. Installing/upgrading a module or language pack from the live admin dirties the remote working tree, and updateInstead then refuses all pushes until it's clean, with an error pointing nowhere near the cause. So nothing is ever installed or upgraded on production, you do it on local, commit, deploy. A read-only preflight reports the remote's checked-out branch and working-tree dirtiness in about half a second, writing nothing. Why all of this makes operations deterministic. Put the three pieces together and the live site's state becomes a pure function of the committed history, the same commits plus the same migrations always produce the same site, regardless of who runs them or in what order. That property comes from four things stacking up: One source of truth per kind of state, one direction of travel. You never have to ask "is this fact in the database or in a file, and which environment's copy wins?", the mapping decides it in advance. Every change is a named, idempotent, versioned artifact, not a click. A migration that names its targets yields the same schema no matter the local database ids or the order things ran, and re-running it is a no-op. "Apply the migrations in commit X" has exactly one possible outcome. Preview-first. Because every write shows its effect before it commits, what you approve is what runs, there's no gap between intent and result. The guards close every side channel. This is what turns "predictable tools" into a "predictable system". The reflexive push fails, the production admin is off-limits for installs, a database clone can't flip the environment flag, so no unreviewed path is left open, and the live site's state is a function of the reviewed history and nothing else. In practice that's the difference between "deploy" being a delicate procedure you perform carefully and "deploy" being an operation with one knowable result, which is exactly what you want the moment an agent, rather than you, is the one performing it. On the questions the thread left open: Rollback, this is the piece I'd most push you to automate; it's the cheapest insurance you'll ever buy. Every write is dry-run by default and needs an explicit --apply; we snapshot before a deploy, and there's a one-command restore plus snapshot/* git tags to roll back to. When "undo" is a single command, you operate far more fearlessly. Staging / multi-developer, full honesty: we're single-developer-plus-agent on a handful of sites, close to Peter's context, so I won't pretend this is team-tested. The directional-state idea should scale; the "one flag file per machine" part clearly needs more thought once several developers share it. The meta-point, and I think the real lesson of your post: none of this is a module you install. It's guardrails placed where the agent, or the tired human, actually hits them: a git setting that makes the dangerous push fail outright, a flag a database copy can't corrupt, verbs that do nothing until you add --apply, and a permission layer that makes every git command stop and ask first. The distinction I'd underline: your AGENTS.md is prose, it tells the agent what not to do, then trusts it to honour that on every single run. A mechanism asks for no cooperation, it makes the wrong move fail on its own, whether or not anyone remembered the rule. "Don't push the dev database to prod" is prose; a system where that direction simply doesn't exist is a mechanism. We also started with prose and learned it isn't enough on its own. An agent acts on a confident-but-wrong assumption fast, faster than you can read the command and think "wait, no", so with only a written rule, the push has already landed by the time the rule would have caught it. So we keep the prose to explain the why, but put a hard mechanical stop behind every rule that can reach the live site.

Thank you for the update Ryan. Take all the time you need and focus on yourself and your family, we are all with you.

Hello @maximus Thanks for adding the option to opt out: Seems to be working well. Should I find any issues with it, I will report. Another issue I had with the previous version of the module is that it kept creating "random backups" instead of following "the Every 1h Schedule" I set up. This seems to have been fixed with this new version, but if not I will come back with a proper issue report. Thanx once more!

Hello @maximus, I was just wondering if you have had time to consider my request.

@tcnet Thank you for the new version!

Hi @maximus, Thanks for ProcessDbBackup, it's a great module. I've hit a workflow gap I'm hoping you can help me out. My setup is a usual "two-tier" ProcessWire arrangement: a production site plus a local MAMP Pro dev copy. I frequently clone the production database down to local. Because ProcessWire stores module install-state and module config in the database, the clone brings production's ProcessDbBackup schedule settings (cron_interval / cron_weekly / cron_monthly) into my local environment, so LazyCron starts firing real backups on my dev machine, which I never want there. The issue is that there's no clean per-environment way to switch scheduled backups off on local: Editing the schedule to "never" in the DB gets overwritten by the very next clone, and uninstalling the module locally is disruptive and defeats keeping the environments in parity. What would solve this (for example) is a runtime opt-out that lives in config, not the database, so it survives DB clones and can differ per environment. Something like a `$config` flag honored in init(): // ProcessDbBackup::init() $noCron = (bool) $this->wire('config')->processDbBackupDisableCron; if (!$noCron && $this->cron_interval && $this->cron_interval !== 'never') { $this->addHook('LazyCron::' . $this->cron_interval, $this, 'cronBackup'); } // ...same guard for cron_weekly and cron_monthly Then on my MAMP Pro copy I'd just add to config-local.php (which I already have, BTW): $config->processDbBackupDisableCron = true; If a config flag doesn't fit your design, an equally workable alternative for me would be to make the cron entry points hookable (i.e. rename to `___cronBackup` / `___cronBackupWeekly` / `___cronBackupMonthly`) so I can change them with a hook, though the config flag above is cleaner since it prevents the LazyCron hooks from being registered at all. Would either of these be OK to add? I am happy to test the new module version against my setup. Thanks again for the module and for considering this.

@ryan Another Forum issue is this: I am getting more and more of this. Without this activity list, it is almost impossible to keep track of all posts. But something blocks me out of this forum page. Other pages load, but not this one. It seems to be quite random when the page loads fine and when I get the 403. Could you please look into this issue as well?

Thank you in advance! Nothing is urgent, of course :)

Hi @tcnet I have a fix request for Login Fail Notifier 1.0.4: fix Undefined array key "SERVER_NAME" under CLI getDefaultData() reads $_SERVER['SERVER_NAME'] unconditionally, and since the module is autoload, __construct() calls it on every bootstrap. On a web request that key always exists, but under CLI (php index.php …) there's no request, so it's undefined, hence I get a lot of PHP Warnings: Undefined array key "SERVER_NAME" on every CLI run. With display_errors on it also lands on stdout and breaks tools that parse CLI output (e.g. JSON). Fix for line 79: 'notification_subject' => 'Failed login attempt at '.($_SERVER['SERVER_NAME'] ?? ''), I applied that fix to the module on my sites, but could you please also apply it? Thanks in advance!

@ryan Thanks Ryan for the broader picture. Unfortunately, I do not have time to dig in further, but my issue is definitely solved, so thanks once more!

One more thing I forgot to add, is that for the first time "failed" upgrade, even the frontend of the site did not load (500 internal server...) and I guess an admin module should not load on the frontend, should it?

Thanks again! I think I tried to access other admin pages as well, but the issue persisted. But yeah, if the module does not need to be loaded, then sure I should be able to access the admin's module refresh page, too. Anyway, I have just tried the upgrade one more time and after the successful update page in the admin I tried to access the module refresh page (/module/?reset=1) by using the admin menu, and I got the error again, however, simply refreshing the page made the error go away and I was notified: "SystemUpdater: Detected core version change 3.0.266 → 3.0.267" Could there be a way during the upgrade process when using the Upgrades module to automatically have the modules refresh, so that issues like this can be prevented in the firs place, perhaps? Thanks for all the other troubleshooting tips too, I'll save them for later.

Thanks Ryan for the swift reply! The issue is that it was a 500 error, so I could no longer access the admin (I reverted to the last site backup). Is there a way to do a module refresh in any other way? This is the very first time a ProcessWire upgrade has ever brought down a site for me, so I am clueless.