Leaderboard

Page List Auto Expand Automatically expands the next adjacent page when moving a page in Page List. Usage As you are moving a page in Page List, if you position the yellow move placeholder above a Page List item for a configurable period of time (default is 1000 milliseconds) then that item will expand, allowing the moving page to be dropped as child page. Configuration In the module config you can set the delay before the Page List item adjacent to the move placeholder will be automatically expanded. Restricting the module to certain roles If you want to restrict the module functionality to only certain roles then create a new permission named page-list-auto-expand. If that permission exists then a user's role must have that permission or the module will not have an effect in Page List. https://github.com/Toutouwai/PageListAutoExpand https://processwire.com/modules/page-list-auto-expand/

@eelkenet Done. Try Version 1.1.8.

That would be good to know for RockMigrations so we could highlight all non-default values in the export code section ?

You can find here the release of wire-cli, successor to wire shell, a powerful command-line interface (CLI) tool designed specifically for ProcessWire developers. Optimize your workflow, automate repetitive tasks, and manage your ProcessWire projects with ease. Wire-cli leverages the Symfony Console Component to provide a robust CLI experience, offering a wide range of features and commands to enhance your development process. From creating new projects and managing fields, templates, roles, and users, to performing database backups and serving your ProcessWire projects with a built-in web-server. Still in development, there might be some glitch, I will continuously improve and expand its functionality based on the feedback and needs of the ProcessWire community. Also mentioning that we will be probably working towards merging the features of wire-cli and rockshell to provide a unified CLI solution for ProcessWire. To get started with wire-cli, check out the GitHub repository or simply install it now from your terminal using Composer: composer global require wirecli/wire-cli Contributions are welcome. If you encounter any issues or have suggestions for improvements, please submit an issue, a pull request or post it here.

Exactly why I asked. And there is a potential solution actually and I found it and started working on some things and forgot to come back to this. The getTableData() function for fields seems to pull just the configured settings in the database table. getExportData actually uses the data from the getTableData call and merges it. It's in wire/core/Field.php

Sometimes you need to execute a slow task after some event occurs in the PW admin, and normally you have to wait for this task to finish before you can continue using the admin. This is because PHP is "blocking", meaning that while one thing is executing nothing else can execute. There are potentially lots of different kinds of tasks that could be slow, but just as an example suppose you want to generate resized variations of images on a page, and there are a lot of images. You might have a hook like this so that any non-existing variations are created when the page is saved: $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Create an image variation for each image foreach($page->images as $image) { $image->size(1200, 1200); } } }); When you save a gallery page in the PW admin, the admin will be unresponsive and will only load again after all the variations have been created. I wanted to find a way for slow tasks to be triggered by events in the PW admin and for the website editor not to have to wait for the task to finish before continuing with other work in the admin. Inspired by this StackOverflow answer I came up with the following solution that seems to work well. Using the image variations task above as an example... First we make use of the URL hooks feature to set up a URL that can trigger tasks to run when it is loaded: // A URL that will trigger tasks when loaded $wire->addHook('/run-task/', function($event) { $input = $event->wire()->input; // A simple check to avoid unauthorised access // You could implement more advanced checks if needed if($input->post('key') !== 'cTdPMBQ7x8b7') return false; // Allow the script to keep running even though we have set a short WireHttp timeout ignore_user_abort(true); // The "create variations" task if($input->post('task') === 'create-variations') { $page_id = (int) $input->post('page'); $p = $event->wire()->pages->get($page_id); // Create an image variation for each image foreach($p->images as $image) { $image->size(1200, 1200); } return true; } return false; }); Then in the Pages::saveReady hook we use WireHttp to load that URL and post parameters that define what task to run and anything else needed for the task (in this case the ID of the page that has been saved). $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // When a gallery page is saved if($page->template == 'gallery') { // Load the /run-task/ URL using WireHttp $http = new WireHttp(); // Set a short timeout so we don't have to wait until the script finishes // Timeout values shorter than 1 second can be tried once a core issue is fixed // https://github.com/processwire/processwire-issues/issues/1773 $http->setTimeout(1); $url = $event->wire()->config->urls->httpRoot . 'run-task/'; $data = [ 'key' => 'cTdPMBQ7x8b7', 'task' => 'create-variations', 'page' => $page->id, ]; $http->post($url, $data, ['use' => 'curl']); } }); By doing it this way the task runs in a separate request and the website editor doesn't have to wait for it to finish before they can continue working in the PW admin.

There is a way to have pages returned by $pages->find(), $pages->findRaw(), etc, in the order of some supplied IDs. You use "id.sort" in the selector: https://processwire.com/blog/posts/pw-3.0.200/#pages-api-additions $data = $pages->findRaw('id.sort=1014|1|2', ['id', 'name', 'title', 'url']); You have to supply the IDs for all the pages you want to match: https://github.com/processwire/processwire-issues/issues/1581

This week the dev branch version remains at 3.0.222 but updates and issue resolutions continue as we work towards our next main/master version. I think we are quite close. Thanks for reporting issues in our processwire-issues repo. If there are older issues that I've missed, also feel free to reply to them and that'll bump it to the top when we sort by last-updated, ensuring it gets eyes on it. Thanks and have a great weekend!

@dotnetic The getByIDs method should do it: $items = $pages->getByIDs([ 4, 2, 1 ]);

The module is ready to be used (and is already used in several sites from several devs), just the site to sell it and also docs are not yet done. I'm working hard on that front. It will be 49€ for a single site for early birds. If anyone needs a copy already just write me a PM. Or signup for Rock-Monthly to get notified when I officially release it ? https://www.baumrock.com/rock-monthly/

@bernhard I don't think there's much crossover between Drupal and PW on the software side, but I think there are other similarities. I did develop in Drupal for awhile (before ProcessWire) and while I liked it, I don't think ProcessWire inherited many ideas from Drupal on the technical side, other than some of its directory names. I thought Drupal already did a good job of doing things its own way, and I saw no reason to follow a similar path. I wasn't going to be able to make a better Drupal than Drupal. Not to mention, some of my own preferences also made me not enjoy working in it as much as some others do. Instead, I'd say it helped to cement some of strategies in ProcessWire to be the opposite of those in Drupal, because it seemed like there was more opportunity there, and more consistent with the way I wanted to work with the tool. For instance, at least at the time, Drupal's output/markup was really mixed around in lots of different files and components, and it seemed very opinionated about how it should all work. While that's great for being able to plug in components and use things in a more turn-key and consistent fashion, I found it challenging for the way I wanted to use it, as much designer as developer at the time, and especially on an e-commerce site I had to build and maintain. So that's why ProcessWire is very non-opinionated about how you handle your output and markup, and why it's always been largely markup agnostic. That's just one example of many things. But what I really liked about Drupal was the community behind it and how passionate people were about using it. To them it was not just a software, but a timeless tool with many facets and uses, one that you could build anything in, at any scale, and that had a real following, positive reputation and quality community. I thought it would be great if ProcessWire was similar in those respects.

The ProcessPageList.js is pretty complex and there are things in it I don't understand. I had to do some some rather hacky stuff to get the module working, but the stakes are lower in a module because each person can decide if they want the functionality and are willing to install a beta module to get it. Whereas if I make changes to the core in a PR it might break something for everyone. So I'll wait a while to see if any issues crop up before considering a PR.

The new dev branch version 3.0.222 contains about 20 commits and 16 issue resolutions. In terms of new features, last week I mentioned some upgrades to WireHttp, and below are this week's additions: Multi-language month and day names The WireDateTime class (aka the $datetime API variable) has been updated to support multi-language month and day names. Now all month and days are translatable in the WireDateTime file (/wire/core/WireDateTime.php). So if you request any date in a format that uses month names or abbreviations, or day names or abbreviations, they now support multi-language, whether you requested it from the wireDate() function or the $datetime API variable. ProcessWire has long supported multi-language month and day names when using a PHP version prior to 8.1 and you've requested a strftime date format that uses them. But PHP 8.1 dropped the multi-language supporting strftime() function, without leaving a suitable replacement. PHP's IntlDateFormatter can't be relied upon since it's not always compiled with PHP. But as of PW 3.0.222, now we have a suitable replacement. Though it does require you to translate the 7 days and 12 months for file /wire/core/WireDateTime.php using ProcessWire's language translation tool. Note that unlike the previous strftime() solution, the new solution no longer requires you to use strftime() format codes and you can instead use regular date formats and they will be translated automatically. New conditional hooks that match by argument type Another new addition this week is support for conditional hooks that match by argument type. I think this is especially useful combined with ProcessWire's custom page class support. It enables you to make a hook apply only to methods containing arguments of a specific type. For instance, if you had a custom page class "ProductPage" for template "product" and you wanted to capture the "Pages::saved" event for pages of that type (ProductPage) you could do so like this: $wire->addHook('Pages::saved(<ProductPage>)', function($event) { $product = $event->arguments(0); /** @var ProductPage $product */ $event->message("ProductPage '$product->title' has been saved"); }); In addition to supporting class or interface names, you can also specify regular PHP types such as <array>, <string>, <int>, <object>, etc. For more details on this type of hook see the new Conditional hooks that match argument type section of the Hooks documentation. Thanks for reading and have a great weekend!

This is one of the rare things that are not instantly intuitive to I guess 99% of my clients! Have you considered adding a PR @Robin S ? Imho that's really an essential feature, thx for creating and sharing it! Just added it to RockMigrations default profile ?

Thanks, hope this module gets included in the PW-core.

Thank you - this will be very useful!

A few screenshots to demonstrate:

Thanks but unfortunately I don't see that happening, and it's not about the donations. I'm working with .NET for at least about 3 years now as the backend, and Angular/Next.js/etc for the frontend, all these on a corporate laptop. My own old laptop where I have PHP is now slow as hell, I boot it up only a few times a year. This "setup" makes it very inconvenient to maintain AOS, and I'm completely out of what's happening with PW and PHP lately, which complicates things even more.