PrevAbout the new ProcessWire ProFields Combo Field
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
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
NextProcessWire 3.0.172 – Find faster and more efficiently
5 February 2021 11
This week ProcessWire gained powerful new tools for finding pages and controlling how they are loaded. If you like to maximize performance and efficiency, you’ll like what 3.0.172 brings. More
Joe
What I would love to see is a better GUI for live edits. Probably vue based. Where you can do front end edits and see changes live while you are typing. Font size sliders. Something like what oxygen does. Any edits with any control can be class based or id based. I would love that editing experience with the power of the processwire api. I hate wordpress.
Reply
Eros
If oxygen/elemento/webflow/wix... (insert countless more visual website builders) is what you want, why not use them? There are so many services specializing in just this with teams of people working on those experiences (because visual editors are an absolute royal pain to maintain), One of the great things about PW is that it doesn't have all that.
Reply
Joe
I do in a lot of cases because there are many things they do much faster and better. Already has a great media library, can tack on e-commerce very easily, etc. But I would rather have the building experience on top of processwire instead of wordpress. Just prefer the api.
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
I would love to see processwire leave php for nodejs, there are many things that I can no longer implement on processwire like websockets, so refactoring to node sounds like a big job, but there is nothing like processwire on nodeland
Reply
Eros
Have to disagree, PHP 8+ all the way! I'd stop using PW if it went to node.js. Also, I don't know where the got the idea you can't use websockets... because there are a heap of websocket libraries for PHP.
Reply
Mustafa Online
- 2 years ago
- 68
★★★★★Really great updates, the only missing thing is "Gutenberg" or similar field. I hope we see it soon.
Happy new year to you Ryan
Reply
Thomas
First of all, I would like to thank you for your work and dedication to this project. I discovered ProcessWire around 2013 and have been absolutely thrilled ever since.
>>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
Totally agree with both points. Thank you for the suggestion and happy new year.
Reply
Tomas
I am already doing multi-lingual / multi-domain on https://www.goldenyacca.net/ (although, for practical reasons I started redirecting some of the domains). Yet, it is still possible to see landing on specific languages for specific domains, e.g., https://www.goldenyacca.de/.
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
Well, here goes and I know this may get some flack from longtime PW developers. I’m a designer for the most part. Sometimes I use a framework like UIkit or Tailwind because I want to do the hands-on coding and control every aspect of the layout code. Other times I use Webflow. I’d love to use PW more often but I honestly hate dealing with serving images. Webflow and WordPress (I know...yuck) handle responsive images automatically. I want that from PW. I upload my media and based on breakpoints provided by the CSS framework, then PW would handle serving up the right sizes. This would make my job easier and more enjoyable. And it would remove the major reason I have to not deciding on PW for certain projects.
I think there’s an opportunity for designers to adopt PW.
Reply
ryan
I'm not sure I understand. PW already does all of this that's possible with responsive images from the server side, so I wonder if you can clarify more specifically what you mean? It sounds like you might be talking about something client-side, but I can't tell for sure. Or do you mean that you want it to read the breakpoints in the CSS files and decide on image dimensions based on that?
Reply
Michael Csáki
- 2 years ago
- 11
★★★★★Im just gonna second Thomas Comment: Thank you for the great work with ProcessWire!
- central media library: this is easily the thing that our customers are missing the most. i know there are plugins but it should be in core imo.
- multilanguage by domain: there are also plugins and with a few tweaks its quite easy to get going but also this should definitly be a core-feature in our opinion.
Thanks again, have a great 2021
Reply
thetuningspoon
The main thing I would like to see is further support for using PW pages as an ORM. It’s 99% of the way there, but we’ve run into issues with using subfield selectors at scale. But all these requests have been made known in the PW issues and PW requests github :)
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
Just thought of a few more things.
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
The problem (or not, depends on the use case) with most newer editors is that they don't support HTML anymore. So you can't just go into source view and add a CSS class anymore.
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
Warwick
Ryan – thanks for your work and dedication to ProcessWire! It continues to do an excellent job. The developers love it because it's so powerful, and the users love it because it's so easy. Please keep up the good work!
For 2021 we'd like to see focus on documentation (e.g. the selectors docs) and dealing with outstanding issues. You’re right that ProcessWire now has excellent capability, so we’d value a focus on dealing with its relatively-few flaws rather than adding new features.
Apart from that, we find ProDrafts to be fundamental to our work and would welcome any improvements and bug-fixes to that.
It'd also be great to have a built-in way to have pages that can be automatically published and unpublished at certain dates: useful for media releases, job advertisements and the like. It'd be fantastic if this integrated with ProDrafts so that the final document is approved, but does not become published until the set date. We've created our own solution to this for now, but it doesn't integrate as well as it could.
We’d find it useful if video was a core type, like images. We've managed hundreds of videos using a repeater to group each video file, caption file, poster frame and transcript. However, the option to have this as a core type could enable alternative versions and preview sprite sheets of the video to be automatically made, and the videos to be playable in the admin interface. (I could imagine this would be a big request though and may be not worth the development time.)
Reply