PrevNew ProcessWire modules directory
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.
The $modules->get() and $modules->getModule() methods are no longer case sensitive with regard to module name.
Inputfields.js improvements
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
New $templates->add(‘name’); method that creates a new template and fieldgroup with the given name, saves it to the database and returns it.
New $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!
Comments
Post a comment
PrevAbout the new ProcessWire ProFields Combo Field
4 December 2020 13
This week we'll take a brief look at a powerful new ProFields module for ProcessWire that's just around the corner—the Combo field. More
Joe
Reply
Eros
Reply
Joe
I dont think you can throw oxygen into the others as being a pain to maintain. Its all class and id based and everything uses flexbox. I am assuming you havent used it before if you think its a pain to maintain.
Reply
Laikmosh
Reply
Eros
Reply
Mustafa Online
- 2 weeks ago
- 43
★★★★★Happy new year to you Ryan
Reply
Thomas
>>What would you like to see in ProcessWire for 2021?
I would like to see two features, that I need for simply every client project:
1.) A global media library as a real ProcessWire core feature, with global media management (every media-item as one ProcessWire-page, but completely abstracted, like the repeater pages are abstracted from the user), with multi-file-upload, bulk editing of tags / categories, clear list and thumbnail views, etc. and easy access to the media library in every CKEditor and other fields. I have a ton of further feature ideas :), like selector-fields that only show media-items of a specific tag or category to choose from. Imagine a field like: "choose from the company's icon library" or "choose from the employee portrait library", but really simple to set up.
2.) A multi-language / multi-site feature, that allows to run ProcessWire with different languages on different domains, like the contexts in MODX Revo: Every language has a branch in the page tree with an assigned domain and the corresponding URL-segments are completely abstracted in the whole backend, including CKEditor and other fields.
That would be really great.
I wish you and your family a happy new year!
Thomas
Reply
MrSnoozles
Reply
Tomas
Please note that the system I have built allows for specific home pages for specific domains (one or more at the time). Multiple home pages, multiple languages (varying per domain), multiple domains – all in one PW.
However, the only problem is the practical limit of about 30 languages. At that point PW introduces fatal errors when creating new text fields due to the database limit on the number indices.
Therefore, I have suggested Ryan to look into improving LanguageSupport [LS] by extricating the LS related columns from field tables and placing them into a separate table for LS, which is doable even for the current construct of LS. This improved LS could be used on demand when setting up the website (thusly available in parallel with the current LS system to keep backward compatibility for those who already use it as it is).
Reply
HMCB
I think there’s an opportunity for designers to adopt PW.
Reply
ryan
Reply
thetuningspoon
So beyond that I’d love to see a focus on making the core even faster and more efficient (fewer queries and faster ttfb) as well as just working through open issue reports.
Reply
thetuningspoon
The biggest request from my clients has been for version control, so native version control on fields or pages seems important, especially as this has become a pretty standard feature for many CMSs. On a somewhat related note, my clients have had problems using ProDrafts on more complex websites (especially using repeaters), leading me to have to disable ProDrafts on those sites. So if those issues could be ironed out it would be very helpful.
I second the idea of support for a CKEditor alternative. It still feels clunky to me. I like the looks of the Trix editor (by Basecamp).
Reply
MrSnoozles
Trix seems to be lacking a lot of functionality you would need for web authoring. If we were to replace editors my favorites would be Froala.com (paid, also supports adding inline classes/styles) or Atlaskit Editor (free; their tables implementation is amazing)
https://atlaskit.atlassian.com/examples/editor/editor-core/full-page-with-content
Reply