monollonom

I just pushed a new update for an issue that somehow went unnotice for a while (since v3.0.253 to be precise, back in end of last year): changes to the `options` argument of the PageRender::renderPage hook weren’t propagated to the new Page::renderPage one. I am using this in the module to allow users to remove prepended/appended files when rendering a page set to be converted by PageMjmlToHtml. It’s only now, after updating a local copy of a client’s website’s admin, that I noticed this. I’m surprised nobody came up with this issue before but at least it’s now fixed 🙂

Actually my example is a bit misleading, sorry about this. I added the field as the second argument in all three hookable methods so in your case it's perfectly fine but say you tried to change the `options` argument of FieldtypeQRCode::getQRText by getting it using `$event->arguments(1)`, then it would break. I hope it makes sense and I'll update my post above.

Hi everyone, I once again updated the module (v2.0.0) but this time with a potential breaking change for those hooking into one of the module’s methods. I had to change the hookable methods’ signature to provide the field generating a QR code so hooks can check against the field’s name. Since the field has been placed as the second argument of all hookable methods, if you were relying on indexes to access arguments in your hooks rather than names, e.g. $event->arguments(1) instead of $event->arguments("options") for FieldtypeQRCode::getQRText, then it will break. I should have added the field right at the beginning but it’s only now that I have the need for the following use-case: When generating multiple (and potentially large) QR codes it can be quite expensive and slow down the page rendering, so to speed things up consider adding the following hooks to cache the output: $wire->addHookBefore("FieldtypeQRCode::generateQRCodes", function(HookEvent $event) { /** @var Field $field */ $field = $event->arguments("field"); /** @var Page $page */ $page = $event->arguments("page"); $qrcodes = $page->meta()->get("qrcodes-{$field->name}"); if(!empty($qrcodes)) { $event->return = json_decode($qrcodes, true); $event->replace = true; } }); $wire->addHookAfter("FieldtypeQRCode::generateQRCodes", function(HookEvent $event) { /** @var Field $field */ $field = $event->arguments("field"); /** @var Page $page */ $page = $event->arguments("page"); $page->meta()->set("qrcodes-{$field->name}", json_encode($event->return)); }); $wire->addHookAfter("Page::saved", function(HookEvent $event) { /** @var Page $page */ $page = $event->object; foreach($page->fields->find("type=FieldtypeQRCode") as $field) { $page->meta()->remove("qrcodes-{$field->name}"); } });

I just published a new update (1.2.0) that allows to tweak the appearance of the QR code to your likings, with the ability to set a module’s (one of the small square) size in pixels, change the foreground and background colors, or even set the background to be transparent. I also updated the readme with more informations or you can have a look at the code to learn more.

(side note: you might be interesed by this module from @Robin S https://processwire.com/modules/limited-module-edit/)

When setting $config->advanced = true you can specify in a specific template whether you want the name field to appear in the content tab. Is it maybe your case?

It looks really nice and congrats on the (re-)launch! A small bug I noticed though on the homepage with the scroll animation (using Firefox on MacOS): konkat.mp4

If your CRON is directly calling your template’s php file then yes it won’t work because ProcessWire isn’t bootstrapped. For a client I’m also using a CRON job that calls: "wget -qO /dev/null https://myclient.com/path/to/page". It basically triggers a GET request and thus renders a page with my script in it (it also sends an email). But it seems OVH only allow to execute a php script so maybe you should look into bootstrapping PW, something like: <?php namespace ProcessWire; include("/path/to/your/pw/installation/index.php"); $pages->get("/your/mailer/")->renderPage(); Regarding your LazyCron PageRender::renderPage is not a static function so it wouldn’t work this way, you should instead do something like: <?php namespace ProcessWire; // in your init.php or ready.php $wire->addHookAfter('LazyCron::everyDay', function(HookEvent $event) { $event->wire()->pages->get("/your/mailer")->renderPage(); $event->log("mailer sent"); }; I’m only surprised by this, maybe they changed something in the meantime...

Did you check https://processwire.com/modules/webp-to-jpg/ ?

[deleted]

Do you mean your LazyCron hook is not triggered?

Like you said a TextFormatter formats on output and thus should leave the original data intact (otherwise this could lead to unexpected behaviours). Best would be to create a module and hook before Pages::save for example to sanitize and convert those safe links

It's because of the parenthesis in your pages’ title which, unescaped, act like OR groups. Actually it’s because of the commas 🙂 Try using IDs instead and then in your selector: "winner_name=$ids"

With a quick search it looks like this is an issue from OVH rather than from PW. Do you have enough traffic to consider using LazyCron instead?

Ah! My bad I misread your first post. I don't think I have a local setup with a non-namespaced TracyDebugger but if I do find one, I'll try to update and let you know if anything goes wrong.