Leaderboard

RockGatekeeper A lightweight ProcessWire module that provides simple password protection for your website using a configurable gatekeeper password. Overview RockGatekeeper adds a basic authentication layer to your ProcessWire site. When enabled, it blocks access to all pages for guest users unless they provide the correct password via URL parameter. Features Minimal footprint: Only runs when gatekeeper is configured Session-based: Once authenticated, users stay logged in for the session IP tracking: Remembers the IP address of authenticated users Clean URLs: Automatically removes the password parameter from URLs after authentication CLI safe: Won't interfere with command-line operations Installation Copy the RockGatekeeper folder to your site/modules/ directory Install the module in ProcessWire admin Configure the gatekeeper password in your site config Configuration Add the gatekeeper password to your site configuration: // In site/config.php $config->gatekeeper = 'your-secret-password'; Usage Basic Authentication To access the protected site, users need to append the password as a URL parameter: https://yoursite.com/?gatekeeper=your-secret-password After successful authentication, users will be redirected to the same page without the password parameter, and they'll have access to the entire site for the duration of their session. Download & Docs: baumrock.com/RockGatekeeper

New thread from this original comment in the main RM thread. So I have WireCache Filesystem installed and it's a critical part of the back end of the ProcessWire application. This is a drop-in replacement by Ryan for the core database cache system. @bernhard from your original response: So the benefits of a filesystem cache are that it's lightning fast. It's really preferable in a lot of situations to database caches which require DB queries. It would be difficult to quantify in hard numbers but the simple fact is that filesystem reads are much faster that MySQL queries. This is negligible on local environments but in production is has a significant impact. The compatibility issue is that RM is getting the lastrun value in the __construct() before the filesystem cache has a chance to boot. Is it possible to move that to init or ready?

Hey @FireWire thx sounds good! I can't remember any reason for having it in __construct I have just added this to the dev branch so we have a month of testing before it's merged to main 🙂

I think the latte docs here should answer your question: https://latte.nette.org/en/template-inheritance

I want to share another function-alias (.bash_aliases) I use quite often when dealing with DDEV and composer on my Windows WSL2 setup. I usually install PW via GIT and add 3rd party composer packages into site/vendor instead of PW root. function ddcomp() { if [ -e "$PWD/composer.json" ]; then WORKDIR=$(basename $PWD) ddev composer --working-dir="$WORKDIR" "$@" else ddev composer --working-dir="." "$@" fi } The alias-function ddcomp checks if the actual directory you enter the command contains a composer.json file. If it does, it assumes the base folder (e.g. site) as --working-dir for composer. If there is no composer.json file, the actual dir is used instead. This way you can type e.g. ddcomp config --list inside the PW site folder containing the composer.json file instead of using ddev composer --working-dir=site config --list. For setting up PW from scratch you can use ddcomp create-project processwire/processwire.

@bernhard I made the following change to the code and it appears to work correctly. <?php public function __construct() { parent::__construct(); $this->path = $this->wire->config->paths($this); $this->wire->classLoader->addNamespace("RockMigrations", __DIR__ . "/classes"); $this->lastRunLogfile = wire()->config->paths->logs . 'rockmigrations-lastrun.txt'; // load all constant-traits in /site/modules/*/ $file = wire()->config->paths->site . "RockMigrationsConstants.php"; if (is_file($file)) require_once $file; $dir = wire()->config->paths->siteModules; foreach (glob($dir . '*/RockMigrationsConstants.php') as $file) { require_once $file; } $this->watchlist = $this->wire(new WireArray()); // $this->lastrun = (int)$this->wire->cache->get(self::cachename); <- Move this from here } public function init() { $this->lastrun = (int)$this->wire->cache->get(self::cachename); // <- To here $this->wire->classLoader->addNamespace("RockMigrations", __DIR__ . "/classes"); $this->wire->classLoader->addNamespace("ProcessWire", wire()->config->paths->assets . 'RockMigrations'); $config = $this->wire->config; $this->wire('rockmigrations', $this); if (!wire()->modules->isInstalled('MagicPages')) $this->installModule('MagicPages'); if ($config->debug) $this->setOutputLevel(self::outputLevelVerbose); // ...etc I'm not sure if there is a need to have the last run timestamp checked in __construct() that you know of and I am not familiar with but this change seems to work for migrations and resolves the issue.

You can add the class InputfieldIgnoreChanges to your field then the warning will not appear. Check out inputfields.js:

Great video by the DDEV creator that shows how to troubleshoot problems in your codebase by using DDEV with xdebug and breakpoints in his PHP editor. Then he shows how to go deeper by using DDEV and git bisect with a known good git point in the past when everything was working correctly and the current git commit where everything is broken. Then he shows how to take it further and automate all the manual steps he took and instead use a bash script that does the same thing but much faster.