While we work towards a 3.x master version, we'll shift gears for a moment this week to review the Tesla Model S that we borrowed for the weekend, and were truly inspired by it. We've also got some updates to several 1st party modules this week as well. More
ProcessWire 3.0.32 and 2.8.32
In this post we take a look at the latest core updates and go into detail about how we might handle the release of ProcessWire 3.0 and 2.8.
Core updates in this version
This version upgrades a couple of our 3rd party libraries and adds some useful features that I think many of you will like.
In preparation for 3.x release, we've upgraded to the latest CKEditor version (moving from version 4.5.5 to 4.5.10) as well as the latest HTMLPurifier version (moving from 4.6.0 to 4.8.0). Most of the changes present are minor bug fixes and such, so likely not to affect most of our users, but still good to keep things up-to-date.
Version 3.0.32 also introduces the following to all of our Text and Textarea Inputfield types:
- Support for minimum length requirements in all text-based types.
- Support for maximum length requirements (which weren't previously supported in Textarea types).
- The ability to have a built-in runtime character counter or word counter.
- The character counter also highlights when requirements aren't met.
- All of these work in regular text fields or regular CKEditor fields (they don't work in inline CKEditor fields).
In addition to the ProcessWire admin and page editor, those using FormBuilder can also derive the benefits of these immediately.
To use any of these features, visit any field settings ("Input" tab in the Field editor, or "Details" tab in FormBuilder) and enable/configure them from there. Here's what the configuration looks like:
And here's what the result looks like:
Looking at the PW 3.0 and 2.8 release
We're getting quite close to release of ProcessWire 3.x (and 2.8) and now looking at how best to handle it. This will be a little different than past releases in that 3.x is a more major release than past releases.
For most people, the upgrade process will be the same as in the past (simply replace the /wire/ directory and index.php file). In addition, this has already been the experience of most that have upgraded from 2.x to 3.x. That's because we've got a file compilation system that abstracts away the technical details for most cases.
Keep in mind I said "most cases" above, not "all cases". ProcessWire is used in such a diversity of scenarios that accounting for all possible instances isn't possible. While I've not seen significant cases yet, I have to imagine there will be. Because of this, it leaves me with a question of how best to stage this release.
2.7.2 to 3.x?
If we replace the current 2.7.2 release with 3.x, then it may be that several people upgrade without being aware of potential issues going from a non-namespace environment to a namespace one. That's because people often upgrade by doing a git pull or by using the ProcessWireUpgrade module, or some other means, without reading the scope of changes ahead of time.
I'd really like to avoid inconveniencing existing installations as much as possible, so am a little nervous about just replacing the master (2.7) branch with the devns (3.x) branch. While it'll be fine for 90% of the cases, there will be that 10% where problems will arise and issues will need to be resolved. All things considered, that's actually pretty great considering the scope of change. But it's that 10% that worries me.
Enter our 2.8 version, which is basically just 3.x without the namespace. Because the file compiler isn't needed in 2.8 (unless installing new 3.x specific modules), it is likely a safer upgrade path for the group of people that have an existing 2.x install and don't know what namespaces are. Likewise, for people that don't have time/budget to do thorough post-upgrade testing or isolate any issues that may arise in a major upgrade, the more minor upgrade to 2.8 may be a good option.
One potential plan
As many of you know, the GitHub username the ProcessWire source is hosted under is ryancramerdesign. That's kind of a legacy term, as ProcessWire is not only a project of Ryan Cramer Design LLC, and hasn't been for some time. Instead the term ProcessWire is more about a worldwide community and open source project involving a lot of folks.
Several years ago I reserved the GitHub username ProcessWire, but never used it. Perhaps now is the time to use it for ProcessWire 3.x.
Under this plan, the new ProcessWire account would become the main ProcessWire repository and it would be focused purely on the 3.x+ versions of ProcessWire. The existing ryancramerdesign/processwire repository currently hosting master version 2.7.2 would become our legacy account, hosting master version 2.8. I'd also use that account to continue hosting my 3rd party modules. The 2.8 version would continue to stay up to date with the 3.x version, as it's all automated already.
In this plan, people already running previous versions of ProcessWire would get version 2.8 when they did their next git pull. Something that makes me sleep a little easier at night. Whereas people like you, that are ready for the switch to namespaces (and willing to test and/or make minor adjustments if need be) would go to the new 3.x ProcessWire repository, being fully aware of the scope of changes.
One benefit of this plan is that I think a GitHub account named ProcessWire represents the project better as our main account, as "ryancramerdesign" is probably unfamiliar and meaningless to most. That ryancramerdesign account might even make one question if they've found the right repo.
Another benefit is that with this being a yet untouched account that's not "my" account per se, it could be approached as a more collaborative account. One of my weaknesses is that I'm not great at keeping a GitHub repo organized (especially issue reports and such). Most of you are better at this than me. Many of you know Francesco Schwarz (and others) have been really helpful in the past, identifying issue reports that could be potentially closed and following up with them. How great would it be if trusted people like Francesco (or others like him) had access to administer that stuff? (assuming I could convince him to take on that job!) That's just an example, but the point is that I like the idea of a more collaborative GitHub account (isolated from my other 3rd party modules) and think it may be better for the project.
I'm writing all this because I want your feedback. What do you all think about this as a potential release plan for 3.x and 2.8?
More about what 2.8 is for
I'll be honest and say I've got several older PW installations for clients that I don't have an upgrade budget for. I don't want to introduce an underlying conceptual change (like namespaces) to existing sites like that. The client won't care about namespaces. Yet I want to upgrade them because I know the clients will appreciate it and be more likely to keep sending work my way.
This is what 2.8 is about for me. An easy upgrade path for older installations that I want to keep up-to-date, but don't want to make any potential changes to. It's a way for me to do a nice thing for my clients, without need for major testing, or the potential of cost (for them or me). It makes me more confident that they'll come back to me when we refresh the site someday. And when that day comes, of course we'll use 3.x (there's no reason to use 2.8 for new installations or major upgrades where you've got a budget to work with).
I imagine that many of you are like me, in that you've got lots of PW installations out there. Installations that you'd like to keep up-to-date and keep the client happy. But you aren't interested in upgrades that have the potential of pulling you to far into it. In most cases, 3.x will be just as easy of an upgrade as any in the past have been. But with the major underlying architectural change to the core, there's no way to avoid the potential of occasional exceptions. Especially for those big projects where you are pulling in other libraries or have built a lot of custom stuff in PHP.
Version 2.8 is for those cases where you want to upgrade to the latest, but aren't yet ready for the potential of any more than that. Honestly, this represents most of my past projects. So call me selfish, but I love having the 2.8 option, and I suspect that several of you like me will appreciate it for the same reason.
What’s the main version of ProcessWire?
The version of ProcessWire that we'd link to from our Download page (and anywhere else) would be the 3.x version. The 2.8 version is more focused on being an upgrade for existing installations. So when linked, it will be prioritized as a secondary/alternate version for special cases, some of which have been outlined here.
Thanks for reading and hope that you all have a great weekend! Stay up-to-date this weekend with the ProcessWire Weekly.