Leaderboard

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!

Parts of it, at least, yes! I've had for a very long time on my todo list a related idea; basically something like the https://translate.wordpress.org/ portal for WordPress. Though I didn't honestly even consider using pre-built solutions. I don't say this lightly, but this is an area where WordPress is way ahead ProcessWire, in my opinion. Just a few reasons why I think their system is so good: It's a shared, easy to use, web-based, non-developer friendly system. Whether I'm a contributor or someone wanting to install a translation for a plugin, I don't need to figure out how author of plugin x wants to handle their translations, and I also don't need to know or figure out how to create a GitHub account, open pull requests, etc. This point alone is a major benefit and lowers the bar for contributing ? Just for the record, many plugins still bundle translations with the source code. So yes, both systems can co-exist. Anyone can contribute without core/theme/plugin author(s) having to do anything. I for one have access to Finnish translations for a few plugins. Permissions are handed down by general translation editors for the locale, which is much easier than having to contact individual plugin authors who may or may not be around and active, and may or may not be interested in bundling some language they have no personal interest in. Once a locale has enough coverage, it automatically becomes installable via the admin and via WP-CLI. Personally I use WP-CLI for managing site translations, as it makes things a lot easier to automate. Installing and updating translations is literally one command away, which — as someone who manages quite a few sites — is a big bonus. This, of course, only works for plugins that have been translated this way. Not all have. It's not a perfect world. Finally, the system handles versions properly. For an example if I wanted to submit a correction for the Finnish translations for ProcessWire version 3.0.184, there's no easy way to do that. Maintainer of the Finnish translations repository could set up separate branches or some other way to handle it, but this would be a case by case thing, and there's no guarantee that the language pack maintainer is interested in such a thing. In the past I've also contributed via Launchpad, which (at least back then) was essentially the same thing for free / open source software, and worked really well in my opinion. Anyway, I'm still interested in this idea, but have not had time to pursue it myself. Maybe one day, unless someone else solves it properly before me ? In my opinion it is a viable idea, but there are many questions to answer, and quite a few of those are not straightforward. Also I believe that in order to gain traction this would need to be somehow integrated into our current translation tool(s) and it shouldn't be too opinionated (for an example I personally would prefer it to not update anything completely automatically, as was suggested here earlier.)

I just came accross this feature request on Kirby: https://kirby.nolt.io/20. No real observation / comment but it’s just funny to see how PW and Kirby are opposite in approaches but still look to reach each other’s end

A highly configurable and flexible ACE editor input field. This module is sponsored in part by Nibiri, aka forum member Macrura which was a great jump start. So many thanks to him. See this short screencast to get an overview: Get it from Github or the Modules Directory. Roadmap add full screen mode expose a jQuery api for resizing, setting row count etc. add image handling like in Adam Kiss' version

It also took me a while to understand drupal. In a nutshell: A template is called content type and instead of pages there are nodes. These nodes can be transformed into a page structure via a navigation module. The templating is also somewhat difficult and the structures are predefined. The advantage is probabely that the editor can create many things in the backend himself (e.g. with the views module). However, it is anything but intuitive or easy to understand and learn.

@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. 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

Just in case I am not the only one trying to use this great (thanks @owzim!) module inside a repeater with dynamic (AJAX) load of items, it indeed works using the "current" (Oct 2017) dev version along with a tiny fix in ace-extended.js: The issue is, that acefy is invoked multiple times for the same inputfield, which finally seems to trash the JS engine. Just add two lines of code right before $textarea.each (in acefy): : //Fix: Avoid duplicate and recursive invocation of acefy if($textarea.hasClass(ACE_INITIALIZED_CLASS)) return; $textarea.addClass(ACE_INITIALIZED_CLASS); // Mark wrapper as initialized //FixEnd $textarea.each(function() { : and add an appropriate initialization for ACE_INITIALIZED_CLASS at the head of the module: ACE_INITIALIZED_CLASS = 'AceInitialized'

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

@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.

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

I've just made a module that exposes the 'published' date under the page's Settings tab, so you can update it. It appears to be working nicely, but any feedback would be very welcome as I'm new to this still. https://codeberg.org/artfulrobot/EditablePublishedDate/src/branch/main/EditablePublishedDate.module.php

Could we see a version 3.1 in the dev branch this week? I am always wondering what it would take to get that digit rising.

Well, since @monollonom tagged me I thought I'd tinker. I added a one-click button to Fluency that translates any module file, core or otherwise, in seconds. It's integrated with the native ProcessWire language translator pages. Some details here. It makes it entirely possible for everything a user interacts with in the admin to be translated within minutes, not hours. I didn't know about this module... this looks great! Language is a tough nut to crack and applying a universal solutions are difficult. It's huge task for a module developer, contributor, or a core maintainer like Ryan, to take on when they are providing free and open source software for the community. The fact that ProcessWire handles language so well to begin with shows a thoughtful approach by Ryan and ProcessWire contributors, especially if it is as rarely as you assume. Try Fluency and let me know if it helps out.

Hi all, Here is one of the latest website we created for a french company renting construction machines and trucks with specialized drivers, based in Le Mans. It’s a rather simple showcase/informational website, but we aimed at making clear (and visually attractive) what is available, what is the skillset and various ways to quickly get in touch. We produced everything, from the design, pictures, illustrations down to the development (ofc). There wasn’t any website before except for social media presence and this task was a follow-up to the update of the visual identity we did. Behind the scene, on the front-end, everything is custom made: we don’t use any frameworks. On the back-end we used the usual suspects and some: TracyDebugger ❤️ FormBuilder ProCache ProFields (RepeaterMatrix, Table) Dynamic options / Select images Our own flavor of “components” Thanks for having a look!