PW 3.0.232 – Core updates + new version modules

[ryan]

In the last couple of weeks I've been working on the page versions support in ProcessWire (recap here and here). This week the new PagesVersions module was committed to the core. Though please consider it very much "beta" at this stage. Along with this, the core dev branch version was bumped to 3.0.232. The API reference page for PagesVersions is now live here: https://processwire.com/api/ref/pages-versions/. Note that the module is not installed by default, but once running 3.0.232, it can be installed by going in your admin to Modules > Wire > Pages > PagesVersions.  

In addition, a related development module named PagesVersionsPro has also been released. This module uses the new API from the core PagesVersions module. This module will eventually be merged with or replace ProDrafts. The new PagesVersionsPro support board and module is currently visible to ProDrafts, ProFields and ProDevTools subscribers here. 

Unlike ProDrafts, PagesVersionsPro gets all of its version abilities from the core, and instead just focuses on providing an interactive interface to them in the page editor. To word it another way, the module does not extend the PagesVersions module in the way that ListerPro extends Lister. Instead, it just provides a web interface for it. I think this is a better long term and more sustainable strategy for handling version support. 

Core version 3.0.232 also adds version support for nested repeaters and FieldsetPage fields. Support was added in those Fieldtypes directly. Still remaining are PageTable (core) and Table (ProFields), both of which will need their own implementations for versions like Repeater and FieldsetPage needed. But following that, there won't be any unsupported fieldtypes to my knowledge.

ProcessWire Weekly published its 500th issue! Congratulations and big thanks to @teppo for his incredible work with ProcessWire Weekly, it is truly outstanding!

Thanks for reading and have a great weekend!

[David Karich]

@ryan I'm really looking forward to testing it! Awesome. One question in advance: are there ways to exclude Fieldtypes? Example, my module PageHitCounter. The number of hits should of course not be overwritten by another version. I haven't tested it yet, but is it the case that if a Fieldtype doesn't have a version interface implemented, it won't be versioned?

[ryan]

@David Karich Most fieldtypes don't have the version interface implemented, and it's only those that want to override the default implementation that need to do it. But for Fieldtypes that also store data somewhere other than their field_* DB table, they aren't supported unless they implement the interface. The only examples I can think of are Repeater, PageTable and Table (though Repeaters have fully implemented the version interface already). Currently there isn't a way to exclude some fields or types beyond that, but it'll definitely be added as the module matures, likely even next week. 

[gebeer]

@ryangreat news. Thank you so much for adding this to the core. Having the Pro module for a GUI is a good approach imo.

[szabesz]

Great news as always, thanks @ryan!

12 hours ago, ryan said:

...but it'll definitely be added as the module matures, likely even next week. 

Does that also mean that even superusers will be able to configure which fields of a given template should or should not be versioned? Or will only module developers in their own code be able to specify that?

I would certainly need field-level configuration as well if I wanted to use something like this because the only way to be able to do it at the module code level does not sound like a good idea.

[ryan]

Quote

Does that also mean that even superusers will be able to configure which fields of a given template should or should not be versioned? 

@szabesz Yes. Though it would be a field setting rather than a template one. I suppose field/template context could make it both though. But what I was thinking in addition is that when you choose to create a "new" version, you'd have a "all fields" or "some fields" toggle, and choosing "some fields" would show checkboxes so you could choose the fields. Likewise, when restoring a version, you'd have a similar option to choose what fields get restored. I'm not yet positive it'll be possible, but think it will. The main thing preventing it right now is files, as the version includes all the files in /site/assets/files/123/, and we don't currently have a reliable way to isolate files by field, but I'm working on it. It's not too bad if just considering the core file/image types, but other types can have files too, like Combo, Table, and maybe others I'm not thinking of now. 

Quote

Or will only module developers in their own code be able to specify that?

I wasn't specifically thinking of module developers for anything here, and instead just trying to make an API for page versions that's easy to use, similar to other parts of PW. The API would  be accessible to anyone developing a site or a module. B

[szabesz]

12 minutes ago, ryan said:

Though it would be a field setting rather than a template one. I suppose field/template context could make it both though.

I was thinking along these lines. Thanks for your clarification!

13 minutes ago, ryan said:

But what I was thinking in addition is that when you choose to create a "new" version, you'd have a "all fields" or "some fields" toggle, and choosing "some fields" would show checkboxes so you could choose the fields. Likewise, when restoring a version, you'd have a similar option to choose what fields get restored.

Such a feature does sound very powerful, but I am pretty sure there can be use-cases when we do not want to let clients decide what to include in either the creation or the retrieval of a version. So, I think making it also configurable would be preferable.

Another feature I would love to see is the possibility to purge versions, having options like:

• Chop/Burn just like for logs
• Only purging saved field data but retaining the "versions log" (versions no longer having their field data would not be restorable, of course). Such a feature could be used to track (keep) the date/time of changes without forcing us to keep field data that is no longer needed.
• The combination of the above two.

[gornycreative]

Love what I am seeing here.

Having the ability to clone an old version into a new page might also be handy.