szabesz

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.

@ryan Upgrading from 3.0.266 to 3.0.267 resulted in `Class "ProcessWire\InputfieldSelectMultiple" not found`, see the screenshot:

Hello @maximus Thank you for the new version. I could not upgrade to it, so I uninstalled the module instead, but I guess you are interested in the error I got after upgrading from Context 1.1.9 to the latest. I am not sure if I will try to use Context 2 or not, as currently I am into Ryan's AI modules to learn how they can aid my workflow.

You can send one that you do need to me. My niece is coming this summer too, just post it to her address first please :D

It is from 2021. I do not see any trace of the new version having replaceable battery: https://www.logitech.com/en-us/shop/p/mx-keys-s As always, companies are so proud to be green: "15.87 kg CO2e carbon footprint." Yet they want to force me to buy a brand new unit if I want a better battery. Planned obsolescence: https://en.wikipedia.org/wiki/Planned_obsolescence at its finest. So we have less CO2 and more junk. But: https://www.nasa.gov/centers-and-facilities/goddard/carbon-dioxide-fertilization-greening-earth-study-finds/ "Studies have shown that plants acclimatize, or adjust, to rising carbon dioxide concentration and the fertilization effect diminishes over time." I must believe one study, but not the other one, and they will tell me which study to believe in. OK, I get that. So they want me to believe that while nature is recovering, that’s actually bad news, because their selected studies say so, and who am I to question their selected studies? I am just a dumb IT guy, and they know everything better, since they publish a lot of papers no one reads.