Looking closer at the ProcessWire 3.x and 2.8 release

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.

• ProcessWire 3.0.32 and 2.8.32
  • Core updates in this version
• Looking at the PW 3.0 and 2.8 release
  • 2.7.2 to 3.x?
  • One potential plan
  • More about what 2.8 is for
  • What’s the main version of ProcessWire?

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.

Comments

• 

  Sev Furneaux

  • 8 years ago
  • 60

  Great news about the GitHub name change, Ryan! Looking forward to a more collaborative account, similar to other frameworks.

  Reply

• 

  Can

  • 8 years ago
  • 31

  ★★★★★

  sounds great thanks for keeping us up to date :)

  Reply

• 

  Kyle

  • 8 years ago
  • 20

  Like the idea of a clean start with the new github account.

  Reply

• 

  Leon

  • 8 years ago
  • 20

  ★★★★★

  I would say that the Github account is also the best way to get more contributors in future.

  Reply

• 

  Francesco Schwarz

  • 8 years ago
  • 30

  ★★★★★

  Love the idea of the new GitHub repository. And yes, I would love to contribute to it, too.

  Reply

• 

  Teppo

  • 8 years ago
  • 20

  ★★★★★

  "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?"

  I think it's a great decision. GitHub account change makes a lot of sense in itself (branding and all), and this does guarantee that there's little chance of existing sites suddenly crashing because of namespace / 3.x incompatibilities of the site or 3rd party modules.

  GitHub issues are one thing to consider, in case you want them moved to the correct repository. There are programmatic solutions (https://github.com/google/github-issue-mover) too, but I have no idea how stable those are. Might still be worth checking out.

  If you need help with anything during or after the transition, just ask :)

  Reply

• 

  Tom

  • 8 years ago
  • 20

  Great news Ryan!
  think having the new github repo name will help 'brand' the oss aspect of ProcessWire as a community effort. yay! :)
  regarding the 2.8/3.0 issues; looking at TYPO3 for example, it is not uncommon to have several 'master' branches in one repository, but I see why this might pose other problems in this case where the existing installations are connected with the ryancramer github.
  then on the other hand, merging and sharing features between the two versions would be easier if they'd live in the same repository as two trees. also, kepping track of the issues and fixes would be easier, too, I guess.
  People savvy enough to have their installation connected with the github repo ryancramer shouldn't have problems in updating their remote info to point to 'ProcessWire'.
  I think having the current active development under the new 'ProcessWire' github roof would be a good thing. Then again, having a distinction between the old and transitional stuff (in the current repo) and the future stuff in the new repo makes sense, too. esp as more and more development will focus on the new repo. hm. :)
  ok, I'd 'vote' for the new repo, but with both 2.8 and 3.0 development in there, managed by branches.
  keep up the good work, and I'd love to become part of the flock around the new repo :)
  Tom | webrocker

  Reply

• 

  Richard Jedli?ka

  • 8 years ago
  • 01

  Hi, I like the idea of createing new repo for PW 3.x. But I think there will be necessary to create a separate module directory for modules. The 2.x compatible and 3.x compatible. Because there could be a module which require different versions for each PW version, most of them will work thanks to the compiler, but not all of them. Otherwise I don't see a good solution for modules which cannot be handled by the compiler.

  Reply

• 

  thetuningspoon

  • 8 years ago
  • 00

  I am trying out the character limit feature. The counter is nice, but it doesn't seem to actually limit anything. If I type more than the limited number of characters, the page still saves the full string. Is this the intended behavior?

  Reply