ryan

I hope you all have had a great week. Last week was the blog post for our newest main/master version 3.0.244. This week I've been catching up with some other projects, so no new core updates to report. But one thing I've been working on (and am still working on) is a module that lets you provide filters in the admin page list. In my case, a client wants to be able to filter by the first letter of page titles, so they can quickly jump to all pages that start with the letter "C", for example. It figures out all the starting first-characters for page titles and builds a kind of pagination-style list for it, like seen in the screenshot below. Clicking any of the single character filters to just those pages by sending an Ajax request to the server, grabbing just the relevant pages and listing them. I think it's pretty useful in many cases. And I think there's potential for predefined filters to go beyond just letters. There's more to work out with this, but I hope to release it in the near future. Thanks for reading and have a great weekend!

@FS72 I just did a ProcessWire 2.2 to 3.0.244 upgrade. You are right that you have to use 2.7 as the "intermediate" version when upgrading to a 3.x version (per the README). This is because 2.7.2 was the version that was prepared for the major 3.x changes. So you'll want to upgrade to 2.7.2 first. Once upgraded to 2.7, then you can upgrade to any 3.x version. In my case, some of the user accounts wouldn't transition over because 2.2 was from 13 years ago and used a different password system, so that's something to keep in mind. I ended up creating an admin account and then installed the profile exporter module, then did a fresh install with the newly created profile. That way I was starting with a fresh install, despite the site being from 2012.

ProcessWire 3.0.244 is our newest main/master/stable version. It’s been more than a year in the making and is packed with tons of new features, issue fixes, optimizations and more. This post covers all the details— https://processwire.com/blog/posts/pw-3.0.244/

Just a quick note to say that the new version blog post is coming tomorrow rather than today. Here in Atlanta, tomorrow it is supposed to rain, while today the weather is perfect. So I spent the day outside and am moving my work day to tomorrow instead.

I’m happy to report that today the dev branch has been merged to the main/master branch with our latest version: 3.0.244. This is after about a year on the dev branch. Relative to the previous main/master version (3.0.229) there’s a lot to cover. That’s what I’ll be working on this coming week, writing a new blog post outlining all that’s new and all that’s changed. Like with most ProcessWire versions, it should be an easy upgrade, swapping out the old /wire/ directory for the new one. Thanks for reading and stay tuned for more details next week!

The plan was to merge dev to the main branch today, but I’m still working through a couple of GitHub issues that I’d like to resolve or finish the conversation before finalizing the 3.0.244 main version. One example is this issue report where it was pointed out that there are some issues with UTF-8 page names. ProcessWire uses PHP’s IDN functions to manage conversion to and from the non UTF-8 version of the URL. PHP 7.4 changed the default arguments of the idn_* functions to settings that made them not work 100% for page names in a few cases, which I didn’t realize before this week. But this is not an issue that I can just fix and be done with it… There may already be page names in any given installation that are affected by the post PHP 7.4 behavior. If I were to just fix the issue, then some affected pages might no longer match when accessed directly by URL. So this had to be a carefully considered fix. What I ended up doing is fix it for any new PW installations that occur after this weekend. PW keeps track of its installation date, so can do this by way of its $config->installedAfter(“2025-01-05”) function. Existing installations will keep the imperfect behavior. Presumably it doesn’t affect that many installations since it only came to light last week and PHP 7.4 was released roughly 5 years ago. Nevertheless, existing installations that want the “fixed” behavior can get it by specifying this in /site/config.php: $config->pageNameWhitelist = 'v3' . $config->pageNameWhitelist; That essentially says to use version 3 of the page name conversion. Version 2 will also work fine, but may be slightly slower since it uses a dedicated Punycode library. And version 1 is the one that worked correctly until PHP 7.4, and still works mosts most of the time, but can produce imperfect results in some cases. Installations prior to 5 Jan 2025 use v1 by default and installations after 5 Jan 2025 use v3 by default. Chances are few (if any) will want to specify the version manually like above, but the option is there, just in case. That’s one example of why I’m waiting another few days before the dev branch merge to main. Another is that Adrian mentioned double-clicking on the “Move to Trash” button [in the page editor] makes it permanently delete the page rather than trash it. While I can’t duplicate that, despite multiple attempts, I just want to make sure there’s not something that needs fixing there. But unless any major new issues turn up, by this time next week we’ll merge to main and bump the version to 3.0.244. Thanks and Happy New Year!

@artfulrobot I'm not really sure why it breaks the ability to type, it might be something with my JS that needs adjustment. But placing the icon before the label may still be an issue, so maybe an option to place it after would help for those cases. I also like what you mentioned about select and unselected optgroups, and am going to add this option. We'll lose the ability to use optgroups for their original purpose, but that seems like an acceptable tradeoff if that option is enabled. I might also add an option for separate selected and unselected selects (2 side-by-side selects), which would leave the original optgroup ability. The biggest issue I get when dealing with anything select related is how to keep it functional in iOS, since iOS Safari seems to be pretty inconsistent in how it recognizes changes to options are runtime. Android/Chrome seems to work more consistently.

@MarkE I don't think I've got any control over what text Softaculous uses, but I'll try to see if I can get them to change it. @bernhard Great, thanks for pointing me to it. I'll follow the thread and also pass along to the people working on it.

This week the dev branch version has been bumped up to 3.0.243. Relative to the previous, this has 30 commits, including a lot of minor issue fixes. The plan is to release the next main/master version of ProcessWire on or before New Years day. We’re down to very few new issues being reported, and even fewer resulting in code changes on the dev branch, which is a good sign the new version is ready, or very close to it. This week while working on a site I realized that the $config->maxUrlSegments setting was not working, and I don’t think it has since the PagesRequest and PagePathFinder classes were introduced into the core. So I fixed that, while also updating some of the logic around it, and adding a new $config->longUrlResponse setting that lets you specify how it should respond when it gets too many URL segments, too long of a URL, too much path depth, etc. Next week I’ll be working on updating materials related to the new version (README file, etc.) and keeping an eye out for any newly other reported issues. Thanks for reading and Merry Christmas / Happy Holidays!

There have been a few small bug fixes made to the core this week on the dev branch. I think we’re really close on the new version and hope to have that ready around the upcoming holidays. The module I mentioned last week (InputfieldSmallSelectMultiple) also got a new version this week with support for optgroups, support for “1 of 3 selected” type labels (Adrian’s suggestion) and a couple small fixes. Some fun news: The ProcessWire site is currently going through a redesign. This time there are a couple of professional designers and long time ProcessWire users collaborating on the design. I won’t mention who’s working on this just yet, as I’ve not asked them if I could, so want to respect their privacy. But I’ve been able to see some of the work in progress, and it’s really fantastic, a major upgrade for the look of the site. Along with this will be some visual improvements to the admin theme as well, which will accompany or come after the site redesign. There’s no launch date for the site redesign just yet, I wanted to let you know it was in progress and looking great, something to look forward to for sure. Thanks and have a great weekend!

@adrian Good idea, I will add that option.

This week I got wrapped up in unexpected client work, but it did lead to development of a new Inputfield module, which I think I’ll be using a lot, and hoping some others might find it useful too. It’s called Small Select Multiple, and the purpose of it is to provide a multi-selection input that is as simple as a single-selection input, and that didn't introduce new UI elements, sticking just to native browser controls. It came about because a client has a large front-end form that has a lot of multi-selection inputs, which we handled with checkboxes. It started to become too much for users, so we tried changing to AsmSelect. That helped a lot, but it still became overwhelming once a lot of options were selected. We needed something that looked simple from the start, and stayed simple even after a lot of selections had been made. The Small Select Multiple input seems to do the trick. You can use this input type with Options fields or Page fields, or anywhere else you might us ProcessWire’s SelectMultiple, Checkboxes, or AsmSelect input types. Like the other Inputfield types, it’s not always going to be the right fit, and has it’s own unique set of benefits and drawbacks, but for the times where it suits the need, I hope you find it useful. Rather than writing more about it, I’ll link you to the module page for it. There’s more details and screenshots there. While you are in the modules directory, see the 3 other new modules posted this week too, they look great. Core updates coming next week. Thanks for reading and have a great weekend.

@adrian I'm okay with it, but still not really getting it. Null is directly stated as an allowed option by the presence of "= null" in (array $value = null). Or at least that's what I always thought were were doing. If we didn't allow null, we wouldn't declare it as null. I guess what the PHP error states is implicit seems explicit to me. I would think where the "?" might make more sense [to me] is if the function declaration were without a default assignment like (?array $value) as an equivalent of (array|null $value) for PHP versions prior to the union type support. That would give us a new enforced limit that we couldn't easily enforce before, at least for PHP versions 7.1 to 8.3. Is there something that "?" adds that "= null" doesn't already? Some new ability or enforced limitation that we couldn't easily achieve without it? Even after reading all I can about it, I can't seem to identify what it is. My best guess is it comes from a desire to change the meaning of the language construct to only "optional argument" out of someone's idea of how things should be, maybe influence from another language. Kiwi mentioned C# above, maybe that's where it comes from. I much prefer that as well. Though the "|null" still seems redundant here, but cleaner and with less head scratching, no complaints. It's too bad they didn't just go directly to this in PHP 7.1 as "?" seems like a kludge.

It’s been a fairly quiet week here at the ProcessWire HQ as it’s a Thanksgiving week where the kids don’t have school, which means less time in the office. This is the time of year when we think about what we’re thankful for, and I’m especially thankful for all of you and the ProcessWire community. Even with the holiday week, work continues on our next main/master version of ProcessWire. This week Bernhard and Adrian identified that ProcessWire doesn’t work well with PHP 8.4 due to some new deprecations introduced by this version of PHP. It’s a technical detail, but PHP 8.4+ wants a question mark before function/method arguments of named types that have a default value of null. So if the function arguments were (PageArray $items = null) PHP 8.4 wants it to be (?PageArray $items = null). Why? Who knows, perhaps not even PHP does, as “?” points directly to it being a question, one with no obvious answer. Perhaps it wants to make sure we really meant what we wrote, so the “?” is an “are you sure?”. Without question, the “= null” part is a pretty clear statement about what the intention is, no? I question the question mark, doesn’t this turn arguments into questions? Questionable arguments? Being so close to a new master/main version, there’s no question that we want to make sure it works with the latest available PHP version, questionable or not. So that meant adding new questions to 72 different core files, which you’ll find on the dev branch this week. There may be more questions yet to answer, but those are the instances I was able to find so far. There’s a tradeoff in that the questions were introduced by PHP 7.1, so it’ll produce a parse error on any prior versions of PHP. Meaning, our minimum required PHP version is now 7.1. Prior to today, it was 7.0 (actually, PW still even worked even on PHP 5.6, not that it matters). Similar questions will have to be added to modules before they are PHP 8.4 compatible to not throw deprecation notices, so I’ll be making some questionable updates to Pro and public modules in the coming weeks as well. Thanks for putting up with all my questions and have a great weekend! Please reply with your questions below.

We’re moving along with trying to cover as many small issue fixes as possible for the next main/master version. So that’s what all the commits this week are for. There’s not much more to report than that, making good progress! If you spot any new issues on the dev branch be sure to report them in the processwire-issues repository. Thanks and have a great weekend!

This week most of the core dev branch commits are related to minor fixes and improvements. While last week we added a new $page->preload() method, I’m going to avoid more major additions or features so that we’re not creating more things that need lots of testing. For that reason, the commits over the next weeks or month will be similar to those from this week, so that we can get a new main/master version out as soon as possible. I was just looking at the date of our last master version (3.0.229) and see that it’s been more than a year! It feels like it’s been 3 months to me — time sure does fly! Seeing how long it’s been definitely motivates me to not wait too much longer on this next main version. The current dev branch fixes and adds quite a few things relative to 3.0.229 as well, so I think of it as being the more stable version at this point… a good sign it’s about time for a new release version. Thanks for reading and have a great weekend!

This week on the dev branch, we have a new $page->preload() method that enables you to preload multiple fields in one query (in this GitHub commit). This is kind of like what the autojoin option does (when configured with a field), or what the $pages->findJoin() method does, but with one big difference. Those options happen as part of the page loading process. Whereas $page->preload() can be applied to a page that has already loaded. Here’s one example where you might find this useful. Say you have a page living at /products/product/ and it has a hundred fields. At the top of your template file that renders the page, you could have a $page->preload(‘field1’, ‘field2’, ‘field3’); to preload all those fields before outputting them. This enables you to load field1, field2 and field3 in 1 query rather than 3. On your first call to $page->field1 it won’t trigger a load from the database and instead will return the value that has already been preloaded. You can also call $page->preload(); without any arguments, and it will preload ALL the supported fields for the page. In reality, ProcessWire is already pretty quick with loading fields, so you probably won’t benefit from preloading until the scale is quite large. While developing this, I was testing by iterating 500 pages and accessing 50 different fields from each. Without preload this took 12 seconds. With preload it took 6 seconds. So for this particular case, preloading cut the time in half. I’m not a query counter, as very often lots of simple DB queries are faster than a single big query, but I’ll mention that it also reduced the quantity of database queries by more than a factor of 10. For this large scale case, that meant more than 20000 queries down to well under 2000. Like with autojoin, there are some limitations with preloading. It supports primarily Fieldtypes that use the core loading mechanism. Some Fieldtypes (especially non-core) override this, and preload() skips over those fields. It also skips over most FieldtypeMulti (multi-row fields), but FieldtypePage is supported when used with Page fields that carry one value. Multi-value can be enabled for testing with an option you’ll find in the function $options, but like autojoin, is limited by MySQL’s group_concat limit. By default that limit is 1024, which supports 140-170 page reference values in a given page field. That's quite a lot, but I don't want to assume folks won't go over that, so it's disabled by default. I’m guessing that most won’t need the preload() function, but a few might really benefit from it, especially at larger scale. So I think it’s a worthwhile addition to the core, and another method that answers a need that may arise as an installation grows, further supporting ProcessWire’s ability to scale up as needs do. Though consider it experimental and "work in progress" at the moment, as we’ll need to do more testing to make sure it is fully stable in a broader range of situations, and further improvements are likely. Special thanks to @tuomassalo at Avoine who came up with the idea for preload() and helped me to get started developing it. Last week I told you how Pete, Jan and I met up in Holland. I also wanted to mention, a couple weeks ago, right before I left for Amsterdam, Oliver from @update AG (update.ch) in Zürich, Switzerland sent me a DM saying that he was in my neighborhood, so we got together for coffee near my house. They’ve been using ProcessWire at Update AG almost as long as PW has been open source, so it was good to meet another long time ProcessWire user, and a nice coincidence that he was in the neighborhood. It’s always great to meet ProcessWire users in person and I hope to meet more of you in the future as well. Thank you for reading and have a great weekend!

The traveling over the last month or so is finally finished. In late September/early October my family traveled to Spain, France, and Italy for the first time. And the last couple weeks my wife and I were in Holland on a bike trip where we lived on a boat for a week and biked all over the Netherlands (~150 miles of biking), and got to see a large portion of it. Our forum administrator @Pete was also there, as was Jan, who maintains our website on AWS, so sometimes it felt like a mini ProcessWire meetup too. The trip was one from Tripsite, a company using ProcessWire for more than 15 years, and this trip was their 25th anniversary. There were about 30 other people there as well, several whom also work ProcessWire as editors. It was an amazing trip, and now I'm completely sold on bike and boat trips being the best way to experience a country. I felt like I was a resident rather than a tourist. I’m sorry there have not been a lot of updates here lately due to all of the travel, but now that it’s done, it’s time to get back to work on our next main/master version, which I’m greatly looking forward to. While there have only been 3 commits this week, there have been 25 commits since 3.0.241, so I’m bumping the dev branch version up to 3.0.242, to get the momentum going again. Thanks for reading, and for your patience while I catch up with communications and such, and have a great weekend! Below is a photo of Pete, Jan and Ryan on the boat in Amsterdam.

@cpx3 Thanks! It should be fixed now, but let me know if you still can't access.

@cpx3 Sorry about that, I got back two days ago, and I've been battling the flu or something since, so I've not caught up with my messages yet. I'll be getting caught up over the next week and will fix that access issue right now. Thanks.

This week there’s new $pages->saveFields() and $page->saveFields() methods on the core dev branch. You might already be familiar with the $pages->saveField($page, $field); method which lets you save one field from a page, or $page->save($field); which does the same. This is useful when you only need to save one field from a page, rather than the entire page. Now we have a plural version of that method, which lets you specify multiple fields on a page to save: $pages->saveFields($page, [ 'title', 'body', 'summary' ]); Below is the same thing, but on a $page object, so you don't need to specify a $page argument: $page->saveFields([ 'title', 'body', 'summary' ]); You can also use a string if you prefer: $page->saveFields('title,body,summary'); In my case, I needed this method for a project I'm working on, and I also needed it to save without updating the 'modified' time or user, which you can achieve by specifying the 'quiet' argument. Though note, the 'quiet' argument is available for all the page saving methods and has been around a long time. But I'm not sure how widely used it is, so I'll mention it. $page->saveFields('title,body,summary', [ 'quiet' => true ]); This week the API methods for Select Options fields have also been updated to add more convenience for getting, adding and removing options to an existing selection. Let's say we have an Options field of checkboxes named "colors". Each selectable option has an ID, optional value, and title. Now you can get, add, or remove by any of those properties. Previously you had to work directly with SelectableOption instances, which wasn't as convenient. // add by title of option 'Blue' $page->colors->addByTitle('Blue'); // remove the option with value 'orange' from colors field $page->colors->removeByValue('orange'); // get SelectableOption instance of option with title 'Red' $red = $page->colors->getByTitle('Red'); echo "ID, value, title: $red->id, $red->value, $red->title"; // check if colors has an option with value 'purple' if($page->colors->hasValue('purple')) { // it has purple } The methods added to SelectableOptionArray (not yet reflected in linked docs page) include: getByID($id) getByValue($value) getByTitle($title) addByID($id) addByValue($value) addByTitle($title) removeByID($id) removeByValue($value) removeByTitle($title) That's all for this week. There likely won't be any core updates next week, as I'll be out of town again. Thanks for reading and I hope that you all have a great weekend and great week ahead.

In the last couple of weeks I’ve been to several cities in Spain, France and Italy. I’d never been to any of those countries before (or Europe for that matter), so it was an exciting trip. Though the goal was for my kids to broaden their horizons and experience other parts of the world, as well as spend time with my parents and family. We got back this week and have been recovering from jet lag (another thing I’d not experienced before). The 6 hour difference was no problem getting there, but coming back, it’s a little harder to adjust! Next week I turn 50 years old (ugh), and then the following week I’m back in Europe again, except this time in the Netherlands on a bike trip with a client, and without my kids and parents. I’m not sure I’ll be able to do many core updates during the 10 day trip but do expect to have internet access this time, so will at least be online regularly and hope to be here in the forums. After that trip, I won’t be traveling again for a long time, and the focus will be on getting our next main/master version out. I noticed this week that @Robin S is now beating me as our most prolific module developer, with 72 modules! Great job and thanks for all the great modules Robin S.!

I mentioned a couple of weeks ago that I’ve got to do a lot of traveling in September and October, and so that means not a lot of core updates in the short term. Core activity may be a little quiet till the end of October. Sorry about that, I feel especially bad I’m not providing any good material for ProcessWire Weekly. But I’ll make up for it later, I promise! I’ve been reluctant to push any significant updates to the core because it is quite stable right now. So I’ll hold off on anything major till the traveling is done. I did just push one update to the dev branch that I think is a good addition though. I noticed recently that on a couple sites I work with, there was some markup cached with $cache that never seemed to expire. I tracked it down to an issue in WireCacheDatabase where some caches had ended up with invalid MySQL dates somehow or another. WireCacheDatabase now implements its own cache maintenance that ensures these never-expiring caches get deleted. In doing that, the cache maintenance process became more efficient as well, as it’s all handled with a single delete query, rather than multiple select and delete queries. If you’ve been noticing anything cached by $cache that doesn’t seem to be expiring when it should, it’s worth grabbing the current dev branch, or at least the updated /wire/core/WireCacheDatabase.php file from the current dev branch. One way you can tell if you have any caches that shouldn’t be sticking around are if you find any with dates prior to the year 1971, or any with a zero’d out date like 0000-00-00. Maybe there is still a bug to track down that is causing the occasional invalid dates, but at least now those caches won’t last more than 10 minutes. There likely won’t be an update here next week, as I’m anticipating no internet access, but there should be the week after next. Thanks for reading, have a great week and weekend!

@FireWire Apologies, I still don't completely follow what you are trying to do in the code above, but wanted to comment about a couple of things. This is because at this point in your code, you've only dealt with the Field object (or in this case a CustomField object), and no $page has been involved. Since values are stored with pages, all you've got here is a set of blank Inputfields, which probably isn't useful for anything. In this case you are iterating that Field object, which I don't think has any value. What you want to iterate is the value from the page. So if your CustomField is named "custom_field": foreach($page->custom_field as $property => $value) { echo "<li>$property: $value</li>"; } Are you setting an 'addClass' property to your Inputfield definitions in your /site/templates/custom-fields/field_name.php file? And you want to use the value of that property somehow on the front-end of your site? That property is for adding a class to the Inputfield in the admin, but if you want to have access to it on the front-end of your site, I suppose you could do this: $defs = $fields->get('custom_field')->defs(); /** @var CustomFieldDefs $defs */ foreach($page->custom_field as $property => $value) { $f = $defs->getPropertyInputfield($property); echo "<li>addClass for $property is: $f->addClass</li>"; } But you might also just consider going straight to the source, by including your field definitions php file directly: $defs = include('./custom-fields/field_name.php'); /** @var array $defs */ foreach($page->custom_field as $property => $value) { $def = $defs[$property]; if(isset($def['addClass'])) { echo "<li>addClass for $property is: $def[addClass]</li>"; } } Note this will only work if you don't have your properties nested within fieldsets. If they are nested in fieldsets, you can still do it, but you'd just need to account for that in the code. You wouldn't need to account for it in the example above this one.

Looks interesting! I just created an account https://pinkary.com/@processwire. I'm not sure what happened to Twitter but seems like it's gone downhill. I don't have an appetite for it. I've only kept the ProcessWire account on Twitter to post links to new blog posts, but not sure I'll keep doing that. Threads seems a lot better, but I don't think there's much of a webdev community there, that I've found anyway. This forum is my favorite social network. I look forward to trying out Pinkary more.