This last week with RC2 version 3.0.122, things have been relatively quiet on the issue reports front. There have not been any new dev-branch specific issue reports appearing. And all issues that did appear to be dev-branch specific have been resolved in the last month. In the last few weeks, we've also wound down the new additions to the core and focused purely on issue resolutions. I feel confident that our dev branch is more stable than our current master branch and thus we’re ready to release our next master version, 3.0.123.
Relative to our last master version (3.0.98), ProcessWire 3.0.123 contains a whole lot of bug fixes and issue resolutions. More than 190 issue reports have been closed in that time period. While there haven’t been any that we would consider major bugs in 3.0.98, version 3.0.123 nevertheless contains countless minor fixes, tweaks and optimizations. If you are following the master branch, it's definitely a worthwhile upgrade. It's also an easy upgrade, as you should only need to replace the /wire/ directory with the new version, and that's it.
In addition to fixes, tweaks and optimizations, below are some highlights of the new updates and additions that you’ll find in ProcessWire 3.0.123 relative to the last master version.
Brand new live search engine in the admin that now supports the ability for any module to include its items in search results. Search results are now organized by module, or you can limit search just to a specific module and use operators and properties to control what gets searched. More and more
Major improvements to trash emptying process, which can now manage much bigger deletions and provides options for time limits and gives you details on how long it might take as well as a pages-deleted-per-second rate. More
Improvements to the user Profile edit screen, including a pop-up dialog box prompting the user for their password when a change a field requires it as a security confirmation. More
Several improvements to ProcessWire’s Pages Export/Import functions in the admin, available via core modules ProcessPagesExportImport. More
Lots of updates to the customizability of Uikit admin theme, AdminThemeUikit. More
Added a new field tags manager in the admin for simpler management of the fields that belong to each tag. More
Updated versions for both Uikit 3 and CKEditor.
Added support for two-factor authentication in the admin. Also created two modules for different kinds of multi-factor authentication including TfaTotp (time-based one-time password) and TfaEmail (for email/SMS). More
Major and numerous updates to ProcessWire’s core ProcessForgotPassword (“Forgot Password”) module (nearly a rewrite). More
Added the option to prevent more than one parallel session per user when using the core SessionHandlerDB (database sessions) module (via @kixe). More
Added the ability to harass users into enabling two-factor authentication. More
Added ability to support the “Trash” option in the Page List for non-superusers. More
Added the ability to customize the quantity type shown in the Page List. Rather than just showing a count of direct children, you can now configure it to show counts of all descendants, both children and descendants (distinctly), or page ID numbers. More
New “Restore” tab added to the Page Editor for pages that are in the trash. Checking a box on this tab lets you restore the page to its original pre-trash location. More
Added new “What pages point to this one?” Field in the page editor (settings tab). This shows pages that contain page references or links to the page being edited. More
Improved page editor handling for support of “required” attributes on inputs. Now when a required input is missing, the page editor will automatically change the tab and locate the field that is missing a required value for you. More
New redirect URL management in the page editor. See the bottom of the “Settings” tab, with field “What other URLs redirect to this page?”. This field not only shows you what URLs redirect to it, but also lets you add new ones. More
Collapsed file, image and CKEditor fields now automatically open when you drag a file from your computer on top of them. This enables you to perform a drag-n-drop file upload in cases you previously could not, due to a field being collapsed. (via @Toutouwai) More
New $page->restorable() method that returns boolean true for pages that are in the trash and can be restored to their original location. More
New $page->references() method that returns a PageArray of all other pages referencing the page it is called from (via Page reference fields). Also added $page->referencing property which returns a PageArray of outbound links on $page, as well as $page->numReferences and $page->hasReferences which return quantities of inbound links from other pages. More
New $page->links() method that returns PageArray of all pages linking to the current one in <a> links contained in Textarea fields. Also added $page->numLinks and $page->hasLinks properties which return counts of inbound links. More
Added new $page->urls() method which returns an array of all URLs that $page is accessible from. This includes past URLs that redirect to it, as well as multi-language URLs that $page is also accessible from. More
New $page->findOne() method that works like $page->find() except that it returns the first matching descendant page rather than all matching pages. More
New $page->numDescendants() that is like $page->numChildren() except that it returns a count of all descending pages rather than just direct children. More
New $page->descendants() and $page->descendant() methods that are aliases of $page->find() and $page->findOne(). More
New $page->addUrl() and $page->removeUrl() methods that let you add or remove URLs that should redirect to the $page. More
Added new $mail->mail() and $mail->mailHTML() methods which mimic the behavior of PHP's mail() function while using WireMail. More
Added new $mail->to(), $mail->from() and $mail->subject() methods, enabling you to skip the $mail->new() call, saving a step. More
New $sanitizer->truncate() method for smart text truncation to nearest word, sentence or paragraph (and more) with lots of customization options. More
Improvements to $sanitizer methods: $sanitizer->text(), textarea(), unentities(). Plus addition of $sanitizer->removeWhitespace() method. More
New $sanitizer methods for case conversion: $sanitizer->hyphenCase(), kebabCase(), snakeCase(), camelCase() and pascalCase(). More
New pagination helpers: $config->pagerHeadTags that contains <link rel=[pref|next]> ready for document <head>, plus new $config->urls->next and $config->urls->prev properties that contain next and previous URL when using pagination. More
Addition of $config->noHTTPS which lets you disable HTTPS requirements for staging/development environments or for specific HTTP hosts. More
New $input API variable methods $input->pageNumStr(), $input->httpHostUrl(), and upgrades to existing $input->urlSegmentStr(args). More
Added new $files->unlink() method for deleting files, and new $files->rename() method for renaming files. These methods include extra safety measures relative to their native PHP equivalents. More
New Javascript API functions: InputfieldFocus($el), InputfieldOpen($el) and InputfieldClose($el) functions that enable you to focus, open and close Inputfield elements from Javascript. The InputfieldFocus() method automatically locates the input (changing tabs or opening fieldsets as necessary) to reveal and focus the Inputfield. More
New Inputfield class traversal methods: $inputfield->getRootParent() and $inputfield->getForm(). More
Updated the base WireArray class to make it a lot more useful. It can now be used for for general purpose storage needs. You can also create a new WireArray and populate it with values using the WireArray::new(‘a’, ‘b’, ‘c’); method or WireArray([‘a’, ‘b’, ‘c’]) function. Both also work with PageArray. More
New WireArray::slices() method that splits any WireArray into a quantity of slices that you specify, where each slice contains that quantity of items from the original WireArray. This can be used by WireArray or any WireArray derived type, however we expect it’s most likely to come in handy with PageArray. More
New PagesNames class, accessible at $pages->names(), which provides several new methods for management of page names. While mostly for internal use, the API is public as some of the methods may be useful outside the core. More
New WireRandom class that adds a useful assortment of cryptographically secure random number and string generation methods. More
Relative to the previous master version (3.0.98) numerous core classes (too many to count) have undergone significant refactoring and improvements.
Added support for method-level permission settings in Process modules, enabling even more granular permission control. More
Added new “pw-optional” attribute for use with Markup Regions. This enables you to designate elements as optional and to-be-removed from the markup automatically if something does not populate them. More
New support for chunked Ajax file upload (via @BitPoet) enabling you to Ajax-upload files larger than you previously could due to PHP memory settings. More
New Functions API setting() function for management of run-time settings on the front-end for your site. More
Numerous improvements to the core comments search engine available at FieldtypeComments::find(). More
New “Regular” site profile added to the core, which also demonstrates use of Markup Regions. The profile uses Uikit v3. More
Added the ability for $pages->find() to search multiple fields at once by using field tags as the search property rather than field. More
As you can see from this post, ProcessWire 3.0.123 is actually a fairly major release relative to the last master version. There's just a lot here and I debated whether or not to call this ProcessWire 3.1 or 3.0.123. Technically I think our core is certainly one or more minor version(s) beyond the original PW 3.0 release. In terms of scope, a 3.1 designation for this version would certainly be appropriate. But I'm not calling it PW 3.1 because, while the core has come a long way, it remains for the most part fully compatible with early 3.x versions. Meaning, there's little reason to have separate 3.0 and 3.1 versions as it relates to compatibility, as far as I can tell so far.
Specifically, I'm thinking about the modules directory. I can't currently think of any modules that require something more than 3.0.89, other than one ListerPro Action module released a couple of weeks ago. I could be wrong (?), but there doesn't seem to be a technical need for a 3.1 version designation at present. As a result, I'd rather save those 3.[minorVersion] updates for versions that might represent a major change as it relates to module compatibility.
Please let me know how ProcessWire 3.0.123 works for you. Usually when we put out a new master version, we might put out one or two updates to it in the following weeks just to correct minor isssues that cropped up due to a larger audience now using it. That's likely to be the case this time too, and following that we'll get back to focusing on the dev branch with some new features and pending PRs I've been wanting to add. Thanks for reading and be sure to check in at the ProcessWire Weekly this weekend for the latest news and updates. Merry Christmas / Happy Holidays to everyone.
7 December 2018 6
The RC1 version for our next master release is here. This post covers all the details and information about how you can help. We also look at a a new PageAction module added to ListerPro, and a couple of other new modules currently in development. More
28 December 2018
Happy New Year! This week we’ll take a quick look at last week’s new master version launch and then discuss the status of the new ProcesssWire.com website currently in development. More
“ProcessWire is like a breath of fresh air. So powerful yet simple to build with and customise, and web editors love it too.” —Margaret Chatwin, Web developer
Alexander
- 6 years ago
- 20
★★★★★Ryan, thank you so much for such great gifts.
Happy Holidays!
Reply
ryan
I don't think I've ever stated we are using semantic versioning (?). That's not the intention with our version numbers. The version numbers are focused on the end users (more than module developers), what they represent more in terms of upgrades than downgrades, and highlight of particular major features, when needed. I use the version patch/revision numbers for the weeklies, while the minor version numbers for master release versions when it seems appropriate. For instance, a minor version for tagging in the modules directory, or if some major new feature(s) need extra emphasis in the version number or indicate something different about the upgrade process, etc. The version numbers are focused on our context and what's more relevant to the bigger picture and audience, at least for PW. That minor version bump made sense in some respects and not in others this time around, and ultimately opted not to do it, which is what the section in the blog post above was about. I do like semantic versioning by the way, but it's not the right fit here.
Reply
Adam Spruijt
While I guess it's fair you may not have stated you are following semantic versioning, you are using the dot notation commonly associated with it, and I doubt I will be the only developer to assume as much. I think it's beneficial to be cognizant of the wider development community in these situations. It's rarely better to take a unique approach when something has become such a common standard. It seems to me based on what you described that use of semantic versioning would serve both our needs fine, though I can't speak to exactly what "when it seems appropriate" means.
Saying that you don't see any "technical reason" for a move to 3.1 doesn't make sense to me, this actively discourages a module dev from using the latest API additions since the module directory doesn't support this level of compatibility designation. Just because there aren't currently any modules that need this level of distinction, doesn't mean we shouldn't encourage it. Add to this the fact that you don't post a version history that makes API changes clear anywhere on the site and things start to get confusing. I develop a ton of custom modules and features for my sites, keeping track of API compatibility is a nuisance and it's also a large reason why I rarely bother to turn any of them into community modules anymore.
I think its important to adopt a more common standardized approach where possible if we want to see PW continue to grow, not just in size of audience but breadth and scope of use and appeal.
Reply
Pete
I'm wondering, though it would obvioudly make the documentation more complex, if when new features were rolled out (and if a versioning system were officially adopted) it would also make sense to do something like in the PHP docs where you have the new functions documented as well as the way to achieve the same thing prior to that feature being rolled out.
It sort of happens already in the blog posts but would be great to see everything documented (from what I understand there is a great deal of work going into the docs for the new website anyway).
I'm in two minds about the major/minor version numbers - usually the 3.x releases in other software are to bring in new features aren't they? Whereas a lot of the time what Ryan rolls out is a better (more efficient) way to do something you can do already, so I'm not sure it's as clear-cut in every release. Even some new features (thinking back a long time) like the Session Database module are optional so don't necessarily require a major increment of the version number maybe?
I guess all I've really got to compare it against in terms of my own exoerience is the forum software here where a new release always increments the 4.x number as it always has major new features or changes to the way something works, whereas often PW improves performance, fixes bugs or introduces new optional modules to the core but doesn't change how your site actually functions in any way.
Not sure where I'm going with this to be honest but sounds like that at the very least knowing clearly when certain functions were introduced would help?
Reply
Adam Spruijt
I’m not sure your following semantic versioning properly. Typically the last dot designation would only be for bug fixes, never features. I shouldn’t be able to built a module for a 3.0.x version that ins’t compatible with all 3.0.x versions. If I used these new api methods in a module or site now, it won’t work with all version of 3.0.x. Realistically PW should probably already be at something like 3.6.x.
I could be wrong but this is how I’ve always understood proper versioning.
Reply
Alexey
- 6 years ago
- 30
★★★★★Thank you for your great work! This is a huge release. Happy Holidays!
Reply