Jan Romero

Interesting! Unfortunately it doesn’t seem like this can be used with $page->render(), because it’s built outside of TemplateFile::render(), but I’ve only taken a quick look at the code on my phone, so I may be wrong… I have a lot of places where I wrap stuff like this in cache()->get().

Interesting. I think I’ve figured out why this happens and I opened an issue here: https://github.com/processwire/processwire-issues/issues/2074

Idk, it works as expected for me. The only thing I changed from your code was removing $field->attr('required', true), so the browser would let me send without checking the box. And making everything into plain functions so I could just put them in a template. The required-check happens in InputfieldWrapper and there is no special logic for checkboxes (InputfieldCheckbox::processInput() will find no errors, leaving it to InputfieldWrapper). You can check it out here: https://github.com/processwire/processwire/blob/44fcf13ea2d7f14a04eed54c29afcc79eb46ec45/wire/core/InputfieldWrapper.php#L1304 // check if a value is required and field is empty, trigger an error if so if($child->attr('name') && $child->getSetting('required') && $child->isEmpty()) { $requiredLabel = $child->getSetting('requiredLabel'); if(empty($requiredLabel)) $requiredLabel = $this->requiredLabel; $child->error($requiredLabel); } The error value will be “%consent_label% - Missing required value”. As we can see, this depends on InputfieldCheckbox::isEmpty(), which simply negates InputfieldCheckbox::checked(). The rest is a little weird, but suffice it to say that the posted form data is examined using PHP’s empty(), so if any value at all has been sent for the checkbox (“newsletter_consent”), it’ll pass the required check. By default the value would be the string '1', and if unchecked, as we know, no mention of the checkbox would be sent at all.

+1. This may not sound very shiny and impressive, but you see a lot of systems where URLs are somehow divorced from the data structure and it’s a big turn-off for me. PW’s more manual routing features (urlsegments, path hooks) are also awesome.

Neat. FWIW Tracy also shows hooks that were triggered during the request (in the debug panel). If you, like me, usually define your hook methods as closures, it’ll just say “{closure}”, but it does link to the source, so that’s nice! On the other hand it seems to show all hooks that were defined and doesn’t say whether they actually ran.

I feel like it should be supported, since PW itself uses two modules directories, core and site, and they’re not hardcoded. When ProcessWire instantiates itself, it calls addPath() for /site/modules/ here (the core modules path is added in Modules::__construct): // from ProcessWire::load(Config $config) $modules = $this->wire('modules', new Modules($config->paths->modules), true); $modules->addPath($config->paths->siteModules); $modules->setSubstitutes($config->substituteModules); $modules->init(); https://github.com/processwire/processwire/blob/3cc76cc886a49313b4bfb9a1a904bd88d11b7cb7/wire/core/ProcessWire.php#L557 The problem is that addPath() needs to be called between the instantiation of Modules and the init() call and there’s no way for us to get in there. Unfortunately there don’t appear to be any hookable methods during this process (I don’t think hooks can be attached before this point anyway?). But I think you can get away with just adding your path after the fact and calling Modules::refresh(): // seems to work in init.php wire('modules')->addPath(__DIR__ . '/modules-2/'); wire('modules')->refresh(); Of course this adds a lot of unnecessary cost to every request, because it basically loads all modules again. And I don’t think it’ll work for preload modules. If this is important to you maybe ask Ryan to make this a config setting? ProcessWire already uses an array for module directories, only the assumption that the first two entries are core/modules and site/modules seems to be baked in.

Does wire('modules')->addPath('/site/modules-2/') work?

Chill 😅 You could post little travel logs instead next time 😉

May want to pass ['noHooks' => true] to the save() call to prevent the hook from being called recursively: https://processwire.com/api/ref/pages/save/ (I also like the 'quiet' option).

I have a local copy that uploads changes via FTP on every save because it’s easy. If I’m just trying stuff out in production I slap “if (user()->isSuperuser())” on it 🤣

This seems to be because the XHR request that gets the live results as JSON requests the same URL and headers as a normal visit to the search page, so the browser gives you its cached version. You can also observe it the other way around: If you head to https://processwire.com/search/?q=hello and then use the search box for the same keyword, the browser console will show a JSON parse error because the live search got the full page instead of JSON. I imagine this could be fixed by sending the ol’ X-Requested-With: XMLHttpRequest header. Or by using the appropriate content negotiation header (I think “Accept: application/json”?).

Interesting, I hadn’t heard of Mollie. You seem to have something misconfigured, might want to adjust the page name: It’s currently ”rockmollie-1“, but your short url forwards to “rockmollie” 🙂

Adding all pages and then saving is the way to go. ProcessWire’s arrays have change tracking so they’ll know which items were added or removed. You can dump the field before saving and you should see a property called "added" or some such that lists them. Try TracyDebugger’s bd() method (recommended!) or just var_dump().

Any particular reason for this curly brackets syntax? I’m far from a PHP pro but I’ve never seen that and $assetPage->content_tags->add($tagPage) should suffice. I might look at your code again later when I’m on desktop. Also, might be obvious, but make sure you save the tagPages before adding them 😅

The difference between the two snippets you posted is that $pages->find() will make a database query and $page->event_locations->find() filters the repeater items already in memory (a PageArray). Confusingly, there are some features that are only available in one or the other. My guess is probably the “today” condition doesn’t work with in-memory selectors, because it doesn’t know you’re comparing dates at that point. So under the hood it’ll be something like 1726956531 >= 'today' (or maybe '09/22/2024 00:08' >= 'today' due to output formatting, I’m not sure). As @da² suggested, try this: $pages->find('template=repeater_event_locations, event_date>=today, include=all, event_locations.owner.id=' . $page->id . ', sort=event_date, sort=location.location_city') That should get all repeater items from the database which belong to $page. If you want to use $page->event_locations instead, I would suggest just foreaching them and skipping the ones you don’t want. You’re going to foreach them anyway, so you might as well do filtering and output in a single loop. But the other option should be more performant, because you’re never loading the ones you don’t need.