Leaderboard

This week I've continued work on the page versions support that I wrote about last week. While the main PagesVersions module needs more work before it's ready to commit to the dev branch and test externally, it is so far working quite well in internal testing. I mentioned last week how it will support an interface where Fieldtypes can declare that they will handle their own versions. That interface has been pushed to the dev branch as FieldtypeDoesVersions. I've also implemented it with the Repeater Fieldtype, which is visible starting here. Repeaters are so far working really well with versions! As far as core Fieldtypes go, Repeater, PageTable and FieldsetPage are likely the only ones that will need custom implementations. For ProFields, RepeaterMatrix already works with the implementation in the core Repeater (already tested). It's possible that other ProFields will not need custom implementations, though not yet positive. The module that provides version capability is called PagesVersions and the plan so far is to make it a core module that provides API version support for pages. A separate module provides interactive version support in the page editor. I've built this module initially so that I can test versions more easily, but it'll be expanded to provide a lot more. Below is a screenshot if what it looks like in the page editor Settings tab so far: As you can see, you can Edit or Restore any existing version. You can also create a new version from the Live version, or any other version. And of course you can view and delete any versions. When you Restore a version, it essentially replaces the live version with the one that you are restoring. All of this can be done from the module's API as well. Note that the API is provided by a $pagesVersions API variable that is present when PagesVersions module is installed. The API method names and such are a bit verbose right now but may be simplified before it's final. // Get page and add a new version of it $page = $pages->get(1234); $page->title = 'New title'; $version = $pagesVersions->addPageVersion($page); echo $version; // i.e. "2" // Get version 2 of a page $pageV2 = $pagesVersions->getPageVersion($page, 2); // Update a version of a page $pageV2->title = "Updated title"; $pagesVersions->savePageVersion($pageV2); // Restore version to live page $pagesVersions->restorePageVersion($pageV2); // Delete page version $pagesVersions->deletePageVersion($pageV2); Thanks for reading! More next week.

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!

Hello Flo, thanks for reporting this issue and a possible solution. I have added a fix und bumped up the version number. Please update the module and check if the issue is gone now. Best regards Jürgen

Watch this 6-minute video to learn the basics of PAGEGRID. TIPP: You can hold down [SHIFT] while dragging to change the parent of an item. More shortcuts How to install and setup the module

Damned, I have always thought that custom page classes were usable only in template.php files. ?‍♂️ This evening I wanted to hack PW to create a template/CustomPageClass mapping usable everywhere with PW API (get, find, etc), and in the first 3 minutes I found it was already there. ? This is huge, I love it and am already refactoring some code and twig templates with a custom UserPage, using Traits to share some implementation with my RawUser class (an optimized class from direct database query). I'm quite excited! ?

Hey @Juergen, today I ran into a really strange issue and it took me a while to track it down. I use FormBuilder and automatically save entries to PW pages. I had the issue that although I selected to save to published pages (in FormBuilder config for the form) my pages always had the unpublished status. I wanted to blame FormBuilder first, but then I noticed that there was a hook in JKPublishPages on page save: /** * Set page status to unpublished or remove unpublished status depending on if date range is out of date or not * This runs on manual save * @param HookEvent $event * @return void */ protected function setPageStatusManually(HookEvent $event): void { $page = $event->arguments(0); $from = true; if ($page->jk_publish_from) { $from = $page->jk_publish_from < time(); } else { $page->jk_publish_from = time(); } $to = true; if ($page->jk_publish_until) { $to = ($page->jk_publish_until > time()); } if (!$from || !$to) { $page->addStatus(Page::statusUnpublished); } } Shouldn't this contain a check so it only applies to the templates selected in JKPublicPages' module settings? In my case it sets pages that have no jk_publish_from and jk_publish_to fields to unpublished. When I comment out $page->addStatus(Page::statusUnpublished); or deactivate your module everything works as expected. Could you please check that and provide a fix? I guess this causes issues for others as well when creating pages from the API. Cheers, Flo

I'm also interested in this use case, I'm also curious of the feasibility and I need a short "brain pause" from my current project, so I'm trying some experiments for fun. Like @bernhard said this approach have limitations and drawbacks, at least: You must be sure that both databases use same ID for fields and templates (and maybe more like languages...), But if that's not the case, we may fallback on field and template name, except when field/template has been renamed. Nobody can manually change fields and templates on the target installation, Some data can not be updated so easily, like the field type that can require changes on database structure, Maybe some data in "data" column ("fields" and "templates" database tables) can not be changed so easily too (I see for example some "parent_id" properties), Probably more drawbacks... ? But anyway, I find the idea interesting and am having fun experimenting this. Actually I have some bit of code that do 2 things, compare "fields" table from 2 PW installation and display a summary of the changes. Example of output: Next step should be to update database, and adding sanity checks to avoid some kind of changes (like on field type). But I'm not confident at all to use this on a production server before a lot of tests and a confirmation by Ryan and other PW developers that there's not risk updating what I'm gonna update. ? I'm not even sure I'll use it one day, this is actually just experimentation for fun and curiosity.

I would advice all you that the geocoder API is no longer accessible in the format of the current module. I have an error geocoding address and the return message from nominatim.openstreetmap is: Using the URL /search/ and /reverse/ (with slashes) is no longer supported. Change url from /search/?q=Berlin in /search?q=Berlin Also complete addresses are changed, see below: File not found: API no longer accessible via this URL Using the URL /search/ and /reverse/ (with slashes) is no longer supported. Please use URLs as given in the documentation. Examples how to change the URL: You use: https://nominatim.openstreetmap.org/search/?q=Berlin Change to: https://nominatim.openstreetmap.org/search?q=Berlin You use: https://nominatim.openstreetmap.org/search/US/Texas/Huston Change to: https://nominatim.openstreetmap.org/search?q=Huston, Texas, US See github issue #3134 for more details. See github issue #3134 for more details. Maybe editing ControlGeocoder.js fixes partially the problem? :343 L.Control.Geocoder.jsonp(this.options.serviceUrl + 'search/', L.extend({ change in L.Control.Geocoder.jsonp(this.options.serviceUrl + 'search', L.extend({ :370 L.Control.Geocoder.jsonp(this.options.serviceUrl + 'reverse/', L.extend({ change in L.Control.Geocoder.jsonp(this.options.serviceUrl + 'reverse', L.extend({ I have tested with simple addresses (italian street, number and city) ad it works fine again, both search and reverse. Posted a commit on Github: https://github.com/FriendsOfProcessWire/FieldtypeLeafletMapMarker/commit/63254dffea9bd504eb45b124d64fd5832e38f013