Leaderboard

RockDaemon simplifies running long-running background tasks (daemons) with automatic lifecycle management. Ideal for tasks like PDF generation, email processing, or data synchronization that need to run continuously via cron jobs. Why RockDaemon? Running long-running tasks in PHP can be challenging: Preventing multiple instances from running simultaneously Manual restart capabilities Automatic restart after deployments Signal handling and graceful shutdown Debug output control Command-line argument parsing Hosting environment compatibility RockDaemon solves these problems with a simple, cron-based approach. Example <?php // pdf-daemon.php namespace ProcessWire; use RockDaemon\Daemon; require_once __DIR__ . '/public/index.php'; $rockdaemon = wire()->modules->get('RockDaemon'); $daemon = $rockdaemon->new('pdf-daemon'); $daemon ->run(function (Daemon $daemon) { // get a newspaper page that has the "createPdf" checkbox enabled $p = wire()->pages->get([ 'template' => 'newspaper', 'createPdf' => 1, ]); if (!$p->id) return $daemon->echo('Nothing to do'); $timer = Debug::startTimer(); $p->createPdf(); $ms = Debug::stopTimer($timer) * 1000; $daemon->log( message: "created PDF for $p in {$ms}ms", logname: "pdf-create", pruneDays: 30, ); $daemon->run(); }); Docs + Download: baumrock.com/RockDaemon Showcase in PW Weekly: https://weekly.pw/issue/590/

I am assuming you are talking about something like <?php $page->pageReferenceField->has(...) If so, then it depends on how you have setup the field. Your assumption is correct that there is a difference depending on if the field allows for single or multiple values. For single values, you are actually talking to a Page and are calling it's has() method. For multiple values, you are actually talking to a PageArray and are calling it's has() method. It does not make a difference if you are looking for User though. Apart from that their properties are different from a Page's. If you have setup your field to return a single value, has() will look for page properties, as in https://processwire.com/api/ref/wire-data/has/ And if you're setup for multiple values, has() will look for pages matching a selector, as in https://processwire.com/api/ref/wire-array/has/ I think based on the examples you will want to look at multiple values. Only there can you pass a Page and see if it's actually in the PageArray.

Random errors are the worst! 😉 If you have TracyDebugger installed already you might also want to look into the folder /site/assets/logs/tracy You might find some tracy bluescreen html files there which you could copy to your computer and open in a browser and see something like this: You can click on each item of the trace and you'll see where the problem occurred (top arrow) and also which arguments have been sent to the method (bottom arrow). Good luck 🤞

My debugging solution depends on the PW and PHP version I am one. In your case I would first try to upgrade the PW core with the latest version from the master or dev branch. For that I upload/copy latest wire/ folder with all files and subfolders to my site as wire.new/. Than I rename wire/ to wire.old/ and wire.new/ to wire/ and reload the page. Then I login to the backend and reload the admin and modules 2-3 times. Next I would check the logs and see if that already solved the issue. https://processwire.com/docs/start/install/upgrade/ If that doesn‘t solve the issues, I would install Tracy module and dive deeper into the issues. But before I do this, I always ensure I am on latest PW core with the recommended PHP version for the core version.

Needed the exact same thing today and came up with this solution that allows using regular page selectors: public function getSheetToCreatePdf(): SheetPage|NullPage { // make sure to only find pages that have been modified since creation wire()->addHookAfter("PageFinder::getQuery", function (HookEvent $event) { $query = $event->return; $query->where("pages.modified > pages.created"); $event->removeHook(null); }); // find the oldest page that has no PDF and make sure to flush the cache return wire()->pages->getFresh([ 'template' => 'sheet', 'pdf.count' => 0, 'has_parent' => '/papers', 'sort' => 'id', ]); } This is called from an endless reactPHP loop that automatically creates PDFs when new pages are modified 🙂

@ryan just opened a PR on Github that should resolve the issues above. Module appears to be working as expected now.