Leaderboard

This week continued the addition of new feature requests and PRs, and the version number has been bumped to 3.0.236. In fact, the addition of feature requests is the theme of version 3.0.236. My favorite addition for this week is probably feature request #474 which adds support for opening and collapsing family groups of repeater items together as one. To enable, see the field "Details" tab setting in "Repeater depths/indents" > "Open/close items as a family?". The same commit also made it possible to disable the automatic scrolling to new repeater items when you click the "Add" button, should that suit your need. Both of these updates also apply to Repeater Matrix as well, but don't require a Repeater Matrix upgrade. More updates can be found in the dev branch commit log, and ProcessWire Weekly has great coverage of what's new with version 3.0.236 in issues #507, #508 and #509. Thanks for reading and have a great weekend!

This module fulfills a need that's perhaps not common but there have been some requests for it in the past. There's an open request in the requests repo so the features might get added to the core at some point but for now here's a module for anyone who needs it. PageFinder Depth Adds the ability to find and sort pages by the depth of the page relative to the home page. The module requires that the core PagePaths module is installed. Depth of a page in this case means the same thing as "number of parents", so a page that is directly under the home page has a depth of 1, and a child of that page has a depth of 2, and so on. If you already have a Page object you can get its depth with $page->numParents() but the result of this isn't searchable in a PageFinder selector. Installing this module allows you to use selectors like this: $items = $pages->find("depth=2"); $items = $pages->find("template=basic-page, depth>1, depth<4"); $items = $pages->find("template=product, sort=depth"); The keyword "depth" is configurable in the module settings so you can change it to something different if you already have a field named "depth" that the default keyword would clash with. Limitations OR-group selectors are not supported for depth. Searching by depth in an existing PageArray This module only adds features for PageFinder selectors and doesn't automatically add any depth property to Page objects in memory, but you can search within a PageArray using numParents to achieve the same thing, e.g. $items = $my_pagearray->find("template=basic-page, numParents>1, numParents<4"); https://github.com/Toutouwai/PageFinderDepth

I find that the "number" input type is an enhancement for fields that are only to contain whole numbers. It lets you use the spinner arrows at the right of the input or your keyboard arrow keys to increment the number up and down, and it avoids invalid decimal or text values from being entered into the field. The PW admin uses number inputs for InputfieldInteger in some places but these are not used consistently and I regularly find myself trying and failing to increment values in an integer field that isn't using input type number. For example, in the "Rows" setting of a textarea field. With a simple hook in /site/ready.php you can ensure that all integer fields use input type number: $wire->addHookAfter('InputfieldInteger::renderReadyHook', function(HookEvent $event) { $event->return->type = 'number'; });

Inspired by this reading? https://htmx.org/essays/template-fragments/#known-template-fragment-implementations

Hello folks! ? First of all... I'm not a PHP developer, so this project is quite challenging. Please don't be too hard on me. ? Over the last weeks i was working on my very first module, which should provide an appointment booking function including a calendar in the frontend and create all the necessary pages. You can manage locations, employees, services and bookings. Currently the dependencies for the frontend are jQuery, jQuery validate, Bootstrap 5 (only design and error toast) and twig template. This is how it currently looks like. Frontend: Backend: It's actually only meant to be a fun project and i am not sure if i will ever finish it. However maybe at some point i will just make a public github repository. As far as I know, there is no such module yet and I think it could be very helpful for some. If i have the time and motivation... this is still on my to do list: Frontend: Functionality to select "any" employee and show free timeslots accordingly Day not selectable / blocked if no timeslots available Check if timeslot is still free on form submit (to avoid double bookings) Backend: Add working times in backend (currently static array in the code) Add selection for holidays (for location or in general and for employees, currently as static array in the code) Functionality to send email to the user if the booking is rejected or accepted Selection of weekdays that should always be blocked

Hey @bernhard, RPB is so great I decided to migrate from RepeaterMatrix for a site I'm working on ? However, I came across a snag with a page reference field not saving to the DB. I have a fairly basic 'RichText' block which in addition to the basic title/textarea fields has a checkbox to show a page reference page (single page) via a showIf condition. If the checkbox is checked, the page reference field is shown: But when the block (or parent page) is saved, the chosen option doesn't get saved. I know the page reference field works, because this is exactly the same logic (using the same fields) I've ported across from my RepeaterMatrix field. Furthermore, if I disable the "showIf" condition in the RPB block, the page reference once again works correctly. In the example above, I'm using a select dropdown, but I get the same behaviour if it's a Radio Buttons list. Any thoughts? Much appreciated, Ian.

Lets say you have an multi-image field named 'images' and you want to be able to mark one or more images as disabled as well as make it visually appear as disabled in the admin. Currently, ProcessWire does not support this natively (requested here), however we can still easily achieve this with using custom fields for files/images, introduced in PW 3.0.142, as well as a hook to achieve the visual effect. Follow these steps (modify as needed): create a checkbox field called 'disabled' create a template called 'field-images' which will ProcessWire will detect as a custom template for the 'images' field add the 'disabled' field to that template add the following code to /site/templates/admin.php $wire->addHookAfter('InputfieldImage::renderItem', function(HookEvent $event) { if($event->object->name!='images') return; if(!$event->arguments('pagefile')->disabled) return; $event->return = "<div style='opacity:.2'>{$event->return}</div>"; }); Of course, if you don't want to display disabled images on your frontend, make sure to update your selector on your 'images' field, like so: // before (will still select disabled images) foreach($page->images as $image) { ... } // after (will ignore disabled images) foreach($page->images->find("disabled=0") as $image) { ... }

Have a few Module on the site:- Formbuilder Hanna Code Jumplinks Persistent Login Redirects Tracy Debugger Video Markup ProFields MarkupXML MarkupSimpleNavigation 404 Logger Upgrades Video or Social Post Embed

A module that adds support for finding and sorting pages by depth in a PageFinder selector:

Edit: OK, I think we can ignore the dependent field types involved (page reference, Fieldset (page)) - a simple example with just a checkbox and a textarea exhibits the same problem. It definitely looks to be something related to the "showIf" condition rather than the underlying fields: ----------------- Hi @bernhard, sorry to be a pain. In fact, I have the same problem if the dependent field is a FieldtypeFieldsetPage, as in this example: This example is part of a Call to Action block. The 'Action' field is a Select Options field, and the 'Link to Page' field is the Fieldset (Page) field containing the three nested fields you can see. None of those three fields are saved when the block or page is saved. I think it must be something to do with the 'showIf' logic. Again this logic is just moved over from a RepeaterMatrix field where it worked just fine. Thx, Ian.

Thanks for this cool explanation! I converted an existing website to a multilanguage site with DE and EN. After finishing all steps, I noticed, that in all fields the english tab was the active one. But it had to be the opposite way. So I deactivated / uninstalled the Core -> Language -> Languages Support - Tabs module. Logged out and in and reinstalled the Languages Support - Tabs module. And voilà, now all DE tabs are the active ones.

I've made the same experiences as @teppo. In the world of frontend development - nobody would use jQuery for a new project since now vanilla JS can handle most of jQuery's advantages from back in the 00's. For some specific things you would use libraries which not depend jQuery. Main reasons are also JS-Bundle size and performance. I think if jQuery continues development/maintenance Processwire can still use jQuery in the Admin Panel. Otherwise I would recommend to migrate frontend modules like FormBuilder away from jQuery to vanilla or smaller js libraries.

Thanks, Ryan; I see your point. I don't necessarily agree with all of it (apart from the front-end facing modules part, that I fully agree with), but I appreciate you taking the time to explain your view! Also, I'm clearly in the minority here with my opinions ? One last point, though: When I hear someone describe vanilla JS as not fun or inconsistent, I do wonder if they might be, perhaps, remembering JS as it was a long time ago. Modern JS is at least as far apart from JS of 2006 (when jQuery was released) as PHP 8 is from PHP 4 (also from 2006). After being a heavy jQuery user for years I've been getting more into vanilla JS these past few years, and I must say that my impression of it has changed a lot. Anyway, just saying that if you've been on the jQuery side of things for a long time, giving vanilla JS a try may be a positive surprise. Of course if you're super into the jQuery syntax any difference may be a dealbreaker — and that's fine too ?

I’ve never tried myself, but I assume you could achieve this using the “PagefileSecure” option in your template holding the files: Which would then allow you to hook into ProcessPageView::sendFile: $wire->addHookAfter("ProcessPageView::sendFile", function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments("page"); if($page->template == 'admin') return; /** @var Pagefile $file */ $file = $page->filesManager()->getFile($event->arguments("basename")); $page->of(false); $count = (int) $file->filedata("downloadsCount"); $file->filedata("downloadsCount", ++$count); $page->save(); }); And then later on retrieve and display the downloads count.

No, conditional hooks are great. I just tried to show that this: Pages(template=foo)::saved is wrong and this is the correct version: Pages::saved(template=foo) See https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/#comment-158164 and

It took some investigating and it would be great to have this made more obvious in any documentation for $config->pagefileSecure... Behind the scenes pagefileSecure is using $files->send(): And $config->fileContentTypes forces download for certain extensions based on whether the content type is preceded by a + sign. You can override the default for the pdf extension in your /site/config.php and then the files should display in the browser: $config->fileContentTypes('pdf', 'application/pdf'); // No plus sign before the content type