Leaderboard

This week the core dev branch version has been bumped to 3.0.231. There are about 15 commits in this version relative to the previous. In the dev branch commit log you'll find a good mix of issue fixes and improvements. If you are already using the dev branch, this version is worth the upgrade. If using the main/master branch then it should be a safe upgrade as well, though none of the updates are urgent. And it won't be long till they are also merged to the main/master branch soon too. This week I've also been working on 2 new related modules: FieldtypeDateRange and InputfieldDateRange. These modules allow selection of starting and ending dates to support a date range. It also calculates and stores the number of days and nights for querying and sorting purposes. The "date from" and "date to" can be independently queried from $pages->find(), as can the days or nights. The InputfieldDateRange module can be used independently of its companion Fieldtype module, making it possible to use the date range Inputfield in FormBuilder or other Inputfield forms. One context where the Inputfield might be useful is when selecting travel dates on a front-end form, such as one from FormBuilder. When used as a Fieldtype, you might use it to specify availability of something, start and end dates to publish content, event dates, or any number of other use cases. Below is a screenshot of the Inputfield as well as its configuration tab. The JS-based input widget comes from an existing package that I've made some modifications to, and it works really nicely, with a polished and easy-to-use UI. I originally found it booking some travel online, and really liked the way it worked. I was able to track it down on GitHub here and thought it would be useful to build an Inputfield module around it. It can be set up to work like the core date picker where it appears when you focus in the input, or it can be configured "inline" where it is alway s visible (and the related text input is hidden). In the following screenshot, I've specified that Sundays can't be used for start/end selections and that November 23 is not available. The selected range spans two months. If you want it to span more months, you could click the right arrow in the December calendar to find your desired month, leaving the first calendar in November. In this manner, you can select ranges that span multiple months, or even years: Here's the Inputfield configuration screen so far. All of these settings are hookable as well, as some of them are more likely to be useful dynamically, especially min/max start and end dates, non-selectable dates, etc. (Note the screenshot below does not necessarily reflect the settings in the screenshots above). More on this next week. Have a great weekend!

@d'HinnisdaëlI reworked my DefaultPage class and made the latte object a protected static member of the DefaultPage class to prevent multiple Latte instances as you suggested together with some other small improvements. Have added the updated DefaultPage class code to my initial post in this thread to keep things clean. Cheers cwsoft

Great to see people adopting Latte ? One potential issue with your example is that you're creating a new Latte instance for every single Page class instance that is created. And page class instances are created whenever they're pulled from the database. Meaning, when you're looping over a set of 100 pages, you're creating 100 Page instances and 100 Latte instances with it. That's rather costly for performance. The advantage when using existing modules like TemplateEngineFactory or RockFrontend is that they take care to only instantiate a single instance of whatever renderer they use for generating template views.

Delayed Image Variations Delays the creation of image variations until their individual URLs are loaded. Image variations being generated one-by-one: Background Normally when you create new image variations in a template file using any of the ProcessWire image resizing methods, all the new variations that are needed on a page will be created from the original Pageimage the next time the page is loaded in a browser. If there are a lot of images on the page then this could take a while, and in some cases the page rendering might exceed your max_execution_time setting for PHP. So you might like to have image variations be generated individually when they are requested rather than all at once. That way the page will render more quickly and the risk of a timeout is all but eliminated. But there can be problems with some implementations of this approach, such as with the (in)famous TimThumb script: It's not ideal to have PHP be involved in serving every image as this is needlessly inefficient compared to serving static assets. It's not good to allow arbitrary image sizes to be generated by varying URL parameters because you might want to restrict the maximum resolution an image is available at (e.g. for copyrighted images). If images are generated from URL parameters a malicious user could potentially generate thousands of images of slightly different dimensions and fill up all your disk space. The Delayed Image Variations module avoids these problems - it creates variations when their URLs are loaded but only allows the specific dimensions you have defined in your code. It does this by saving the settings (width, height and ImageSizer options) of every new Pageimage::size() call to a queue. The module intercepts 404s and if the request is to an image variation that doesn't exist yet but is in the queue it generates the variation and returns the image data. This only happens the first time the image is requested - after that the image exists on disk and gets loaded statically without PHP. Usage In most cases usage is as simple as installing the module, and you don't need to change anything in your existing code. However, there might be some cases where you don't want the creation of a particular image variation to be delayed. For example, if you created a variation in your code and then immediately afterwards you wanted to get information about the variation such as dimensions or filesize. $resized = $page->image->width(600); echo $resized->height; echo $resized->filesize; This wouldn't work because the actual creation of the resized image hasn't happened yet and so that information won't be available. So in these cases you can set a noDelay option to true in your ImageSizer options and Delayed Image Variations will skip over that particular resizing operation. $resized = $page->image->width(600, ['noDelay' => true]); echo $resized->height; echo $resized->filesize; For advanced cases there is also a hookable method that you can return false for if you don't want a delayed variation for any particular resizing operation. Example: $wire->addHookAfter('DelayedImageVariations::allowDelayedVariation', function(HookEvent $event) { /** @var Pageimage $pageimage */ $pageimage = $event->arguments(0); // The Pageimage to be resized $width = $event->arguments(1); // The width supplied to Pageimage::size() $height = $event->arguments(2); // The height supplied to Pageimage::size() $options = $event->arguments(3); // The options supplied to Pageimage::size() // Don't delay variations if the Pageimage belongs to a page with the product template if($pageimage->page->template == 'product') $event->return = false; }); 404 handling For Delayed Image Variations to work your .htaccess file needs to be configured so that ProcessWire handles 404s. This is the default configuration so for most sites no change will be needed. # ----------------------------------------------------------------------------------------------- # 2. ErrorDocument settings: Have ProcessWire handle 404s # # For options and optimizations (O) see: # https://processwire.com/blog/posts/optimizing-404s-in-processwire/ # ----------------------------------------------------------------------------------------------- ErrorDocument 404 /index.php ProCache If you are using ProCache then make sure it is not configured to cache the 404 page or else PHP will not execute on 404s and queued image variations will not be generated. Generate queued variations Before launching a new website you might want to pre-generate all needed image variations, so no visitor will have to experience a delay while a variation is generated. To queue up the image variations needed for your site you will need to visit each page of the website one way or another. You could do this manually for a small site but for larger sites you'll probably want to use a site crawler tool such as Xenu's Link Sleuth. This may generate some image variations but it's likely that some other variations (e.g. within srcset attributes) will not be requested and so will remain queued. To generate all currently queued variations there is a button in the module config: This will search the /site/assets/files/ directory for queue files and render the variations. https://github.com/Toutouwai/DelayedImageVariations https://processwire.com/modules/delayed-image-variations/

Hey @bernhard, me again! When developing a new block, I was adding it to a page repeatedly, but not saving the page. Instead I would cancel editing and ignore the 'changes not saved' popup, to add more features to the block and try it again. I then realised that this was creating pages under the RockPageBuilderBlocks tree that seemed to be orphaned, containing just my default settings. Of course I can delete these pages, but do you think there might be a way to identify any such orphaned blocks and remove them automatically? Thx, Ian.

I was in the need to add a "log-out" shortcut to the RockFrontend topbar. The motivation behind this is that I am using @bernhard's RockPageBuilder module and when you are logged in and do some frontend-editing you want to have a quick look on the page without the RockPageBuilder markup (all the edit-icons, etc.) . You just want to check how the the page looks like to the user. Yeah, you coooould open the page on a separate browser but I like this solution: In the topbar.php file in the RockFrontend module folder go to line 58 and append this code: <a href="<?=$config->urls->admin?>login/logout/"> <svg width="512" height="512" viewBox="0 0 512 512" fill="none" xmlns="http://www.w3.org/2000/svg"> <path d="M502.6 278.6C515.1 266.1 515.1 245.8 502.6 233.3L374.6 105.3C362.1 92.8 341.8 92.8 329.3 105.3C316.8 117.8 316.8 138.1 329.3 150.6L402.7 224H192C174.3 224 160 238.3 160 256C160 273.7 174.3 288 192 288H402.7L329.3 361.4C316.8 373.9 316.8 394.2 329.3 406.7C341.8 419.2 362.1 419.2 374.6 406.7L502.6 278.7V278.6ZM160 96C177.7 96 192 81.7 192 64C192 46.3 177.7 32 160 32H96C43 32 0 75 0 128V384C0 437 43 480 96 480H160C177.7 480 192 465.7 192 448C192 430.3 177.7 416 160 416H96C78.3 416 64 401.7 64 384V128C64 110.3 78.3 96 96 96H160Z" fill="black"/> </svg> </a> This will render a new "log-out" button in the top bar: I just inserted a random svg code here, so the styling does not 100% fit the look of the other icons. After clicking you will be logged out and redirected to the login-mask. BUT: What I want to achieve was: "Log me out but instead of redirecting me to the login mask, I want to stay on the same page that I logged out from!" 1. We alter the code from above to include a redirect parameter that includes the current page URL: <a href="<?=$config->urls->admin?>login/logout/?redirect=<?=urlencode($page->url)?>"> <svg width="512" height="512" viewBox="0 0 512 512" fill="none" xmlns="http://www.w3.org/2000/svg"> <path d="M502.6 278.6C515.1 266.1 515.1 245.8 502.6 233.3L374.6 105.3C362.1 92.8 341.8 92.8 329.3 105.3C316.8 117.8 316.8 138.1 329.3 150.6L402.7 224H192C174.3 224 160 238.3 160 256C160 273.7 174.3 288 192 288H402.7L329.3 361.4C316.8 373.9 316.8 394.2 329.3 406.7C341.8 419.2 362.1 419.2 374.6 406.7L502.6 278.7V278.6ZM160 96C177.7 96 192 81.7 192 64C192 46.3 177.7 32 160 32H96C43 32 0 75 0 128V384C0 437 43 480 96 480H160C177.7 480 192 465.7 192 448C192 430.3 177.7 416 160 416H96C78.3 416 64 401.7 64 384V128C64 110.3 78.3 96 96 96H160Z" fill="black"/> </svg> </a> 2. For the redirect you have to put this hook function inside your ready.php file: $wire->addHookBefore("ProcessLogin::executeLogout", null, "setRedirect"); function setRedirect(HookEvent $event) { $input = wire('input'); // Check if the 'redirect' query parameter is present if ($input->get->redirect) { // Get the redirect URL from the query parameter $redirectURL = $input->get->redirect; // Set the logout URL to the specified redirect URL $event->object->setLogoutURL($redirectURL); } } After doing that the log-out button will log you out BUT keep you staying on the same page.

Thanks for your feedback. I am aware of this issue. As my normal PW installations deal with 5-10 template files, I didn't run into performance or memory issues so far. However I am working on some code improvements right now, which will address your concerns.

I have found the solution inside the FieldtypeComments.module from Ryan: * Unlike $pages->find(), pagination of comments is not automatically tied to * $input->pageNum(). As a result, if you paginate, you should specify both * “start=n” and “limit=n” in your selector: * * ~~~~~~ * $limit = 20; * $start = ($input->pageNum() - 1) * $limit; So adding setStart() and setLimit() method will solve the problem. I have only added setLimit() before. $commentPerPage = 20; // how much comments should be displayed $pageNum = wire('input')->pageNum(); $start = ($pageNum - 1) * $commentPerPage; $allComments->setStart($start); Page 1: Page 2:

I've never used that myself but searching the core for "->renderPager(" returns 3 results, so if you look at one of those you should see how Ryan did it and that should work for you as well ?

Hello, Don't consider my answer as the good answer, but I made a quick test to check if an idea could work ("reponses" should be named "answer", and "nouveau" => "add new"): So I created this fields: answer: type=Text isGoodAnswer: type=Checkbox quizzAnswer: type=Repeater, content fields=answer, isGoodAnswer question: type=Text quizzEntry: Type=Repeater, content fields=question, quizzAnswer Added the field quizzEntry to a template, and it looks it's working.

Hahaha- those are great. This is what I'm putting on the invoice line item. That's it. Also, new DJ name.

Okay, colleague, I'm writing the report for the boss. Let me know if I've summarized it well: Then I asked ChatGPT to improve it in a more funny way:

Hi @gornycreative, I have been away so just picking up messages now. Thanks for your interest in Dynamic Selects. I'll respond to your questions ASAP. There might be a delay as I settle in after a long absence, thanks.

TL:DR I've updated a PW page we've built 9 years ago for the first time and it's still a solid experience. Backstory Back in May I was on a crowded train somewhere in the middle of Germany. Now working as a "Consultant" who builds slidedecks instead of websites, I happily noticed the men next to me talking about responsive webdesign with his friend. During the obligatory "This train is late" announcement we started to chat. My seatmate, a geography teacher, recently attended a web workshop at a large Hamburg agency. He told me he now understands the value of a CMS for updating their site and he wonders how to build a responsive layout. They don't get paid for this and work on their homepage in their spare time. And they have a Typo3 installation ? Back in 2013, together with my friend Marvin, we've rebuild our school website with ProcessWire optimized for mobile devices. Launched in 2014 this was quite an impressive feat including online time tables, a working event calendar (with import feature) and many small nice touches. After my encounter on the train, I checked the page and yes, It's still online and updated daily! The next day I wrote my old teacher a short email if we should have a closer look into the underlying tech and within minutes I got a super happy reply that he is so glad that somebody would help (again). So let's dive into what we've done. Situation First some details about this ProcessWire installation that is updated by a few teacher on a regular basis. Over the 9 years they've wrote nearly 900 news articles and kept more than 250 pages up to date. The asset folder is over 11GB. Build with Processwire 2.4 (?) and lots of janky code we've updated the page once to 3.0.15 somewhere in 2016 quick and dirty. They even used the old admin layout. ProCache, CroppableImages3 and a few other plugins were used. Every single one of them required an update It's used the classical append-template approach with a single big "function.php" included file. It's running on PHP 5.6 and for whatever reason no PHP update was enforced by the hoster (But the admin panel screamed at me) A privacy nightmare: Google fonts embedded directly, no cookie banner and a no longer working Google Analytics tag included The old ProcessDatabaseModule made a database backup every week as planned over all these years. Nice. No hacks, no attacks and all teachers are using their own account with assigned permissions Changelog I've updated the page with a focus on making it stable and reliable for the next 9 years. After making a development copy of the page, I've started working on the following changes: Updated ProcessWire and all modules to the latest stable version. After reloading a few times, no errors encountered Updated the whole templates to make it work with PHP 8.2 Removed all externally hosted scripts, disabled cookies for all regular visitors and introduced a 2-click-solution for external content Reworked a few frontend style issues around the responsive layout, made slight visual changes for 2023 (e.g. no double black and white 1px borders) Ported the image gallery feature to more templates (Big wish of the people updating the site, they've used a workaround) Cleaned up folder and structures, removed a few smaller plugins and admin helpers no longer needed All this was done back in May and - with a big break - completed now in October. It took a few days and most of the time was spent figuring out our old code. Learnings ProcessWire is robust as f*ck. I just clicked "Update" and it mostly worked instantly I nearly removed features for the PHP update. A custom written importer for the proprietary XML schedule was hard to debug and understand (5-dimensional-arrays...). Gladly I've tossed a coin and just gave ChatGPT the php function source and error message and within a single iteration it updated the code for PHP8. The "responsive" CSS framework aged badly. The used 960gs skeleton uses fixed widths for the responsive layout. I couldn't get it be wider than 320px on mobile screens. So the site is responsive but with a slim profile for now. Replacing it would be a complete layout rewrite Result and looking forward The Werkgymnasium site is now updated and live again. It still loads superfast and looks great after all these years. We have a few more features planned to help our editors input new content but overall it just works. Looking forward a few issues remain. ProCache would require the paid update but it still works fine. The layout needs improvement on mobile screens. There is still an error with the pagination. We'll cleanup the code more and then make the whole template public on Github so that maybe a few students after us can continue with the updates. Maybe even rebuild the frontend one day. I hope I can give you an update in a few years again. As a closing note: I'm still grateful for the amazing community here and all the features ProcessWire has to offer. My daily work no longer resolves around websites but PW has a permanent spot in my heart. Thanks Ryan and all the contributors.