There’s a new modules directory on the ProcessWire site now up and running. In this post we’ll cover a few details about what’s changed and what’s new. More
Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021?
Admittedly, 3.0.170 has a lot of technical updates and I’m not sure it makes for very interesting reading, but I do think it’s all stuff that you’ll notice (sooner or later) and might appreciate when using ProcessWire going forward. Though because there are so many changes and additions, this dev branch version might also be a little more beta than others, so please let me know if you run into any issues. I’ll do my best to cover the most significant updates in this post. But first, I’d like to know what you would like to see added to ProcessWire in 2021…
What would you like to see in ProcessWire for 2021?
It’s been a year or so now that ProcessWire has been at a point where it does everything I ever wanted it to, and it’s got everything it was originally set out to do, and it's got the nicest and most skilled community in the world. When I develop a new site, no longer do I find myself needing to develop new features along the way because everything I need is already there. In my mind at least, it’s become the timeless tool that it set out to be, the best open source project of its kind, and with the absolute best community. Yet we’re still just getting started, the project’s biggest years are ahead, and I have a real sense of excitement about it in this new year.
While I still develop websites and applications, I spend more time developing ProcessWire and modules than I do developing websites. This focus on building features that worked best for my own client projects has worked well in the past. It was also by necessity, as I couldn’t afford to fund developing stuff that I wasn’t going to use in my own projects. But thanks to your support of the project by way of Pro modules, ProcessWire is now my full time job for the most part. The needs of my client projects are largely met. I want to gain more insight and apply more focus to the needs of your client projects. Many of you are now building sites in ProcessWire that absolutely blow me away and go far beyond what I could have imagined when this project started. In 2021, I’d like us to venture into some new features territory and take ProcessWire to the next level. But what is the next level? I have some ideas, but I want to hear from you. If you could add one or two (or more) things to ProcessWire that would really help in your projects, what would they be? Let’s start talking about it, work on a roadmap and do great things in 2021!
What’s new in ProcessWire 3.0.170
Improvement to configuration of file and image fields
Back in ProcessWire 3.0.142 we added the ability to define custom fields for file and image fields. But unless you read the blog post about it, you might never know that the option was there, as it’s well hidden. Well, it’s not hidden anymore. There is now a dedicated “Custom fields” setting on the “details” tab when editing a file or image field. When you choose to enable custom fields, it automatically creates the template for you, and provides you with a button that opens a modal window to add or modify the custom fields.
There are now contextual documentation links and code usage examples included in the configuration of file and image fields. For instance, the “formatted value” setting lets you decide whether your front-end will be dealing with a single file or an array of them. Code examples are now included to help point out the difference. Likewise, the “tags” section now includes several inline code examples that demonstrate how to use file tags from your template files.
File “description” settings have been moved from the “input” tab to the “details” tab. This made sense because the “Tags” settings were already on the “details” tab, and description and tags go together in file and image fields.
Grouped fieldsets now better compartmentalize the numerous settings for file and image fields on both the “details” and “input” tabs when editing a file or image field.
Two rarely used settings have been moved from the “details” tab to the “advanced” tab. These include the “page containing default/fallback value” and “Inputfield type for files field”.
Because file and image fields have a pretty extensive set of configuration options, all of the supporting code for managing those have been moved to separate files and classes. This helps to optimize the performance of these modules, especially in a multi-language environment.
Improvements to field editor (Setup > Fields)
Field label, name and type are now all on one row (or 2 rows if multi-language). This particular change does not apply to the older Default and Reno admin themes, as the grid system in those themes wasn’t quite fast enough to make it clean. So for the moment, this update is exclusive to AdminThemeUikit.
When creating a new field, you now enter the label first and the field name auto-populates with a suggested value, like it does when creating a new page. This should make creating new fields faster, more straightforward and consistent.
The field “icon” selection has been moved from the “Advanced” tab to the “Basics” tab.
The “Delete” tab has been removed and moved into the “Actions” tab.
Most standard settings now also have icons associated with them.
Improvements to template editor (Setup > Templates)
A new “Actions” tab has been added (consistent with Fields editor) with options to rename, clone, copy fields or delete template.
The template “icon” selection has been moved from the “Advanced” tab to the “Basics” tab.
Like in the Fields editor updates, most standard settings now also have icons associated with them.
Improvements to Modules system
The modules system can now detect modules that are present in the database but missing on the file system. When modules match this criteria, you’ll see them on a new “Missing” tab in the Modules admin. From there, you can choose to optionally delete the module from the database (previously was not possible) or you can place the module files where they should be.
Several core modules have changed locations in /wire/modules/, moving to dedicated directories. Previously, this would cause a fatal error in many instances. Now, ProcessWire can automatically detect these kinds of module movements and correct them at runtime.
While making these upgrades to the modules system, I found some room for improvement in handling modules that ran from namespaces other than the ProcessWire namespace. There are now optimizations to the detection and loading of modules that use alternate namespaces and root namespace.
To my surprise, there were a couple of modules that have been present in PW’s database since the beginning, but have never actually existed. New system update #19 removes these irrelevant entries from PW’s database.
$modules->getModule() methods are no longer case sensitive with regard to module name.
ProcessWire can now open and collapse a multi-column row of Inputfields together as a group. So if you collapse an Inputfield that has other Inputfields in the same row, the entire row will collapse, rather than just one Inputfield within it. Likewise for opening a row of Inputfields. This prevents the odd looking situation where one Inputfield in a row was open while another was collapsed. The result was that you basically would never define collapsed Inputfields that weren’t 100% width, because it didn’t look right. Well now you can do that, and look good at the same time.
$templates API var improvements
templates->add(‘name’); method that creates a new template and fieldgroup with the given name, saves it to the database and returns it.
$templates->rename($template, $newName); method that renames a template, its fieldgroup and file (if writable).
That's all for this week. Thanks for reading, Happy New Year, and enjoy reading the ProcessWire Weekly!