Module Version Control

[Manon]

Would it be possible to not have the clock icon show up on fields that are not editable since their value shouldn't change?

[teppo]

Hey @Manon!

This seems like a good idea, so I've gone ahead and implemented it in Version Control 2.x (available via the dev branch int the GitHub repository). Note that if you're using Version Control 1.x, this update is not available there — I'm planning to merge the dev branch into master soon (this year at least), making 2.x the default version, and as such I'm not going to make any additional feature updates for 1.x releases.

[teppo]

On 6/26/2020 at 7:49 PM, Jan Romero said:

But also, one thing, does anyone else feel that the diff should always be old to new? Right now when you open the history and click the most recent compare button, it’s the other way around. Wikipedia gives you one radio button for each version to compare and simply doesn’t let you select old to new. It’s kind of awkward and over-engineered, but I think the spirit of not going backwards in time is intuitive.

I guess it depends on your point of view. I can see how "always compare old to new" might make sense, but personally I prefer current approach, which is basically just "selected revision compared to any other revision".

At least for now I think that current approach is straightforward and makes sense (without requiring additional UI tricks, such as the one used by Wikipedia) 🤷‍♂️🙂

[Sevarf2]

In my site I use a templating system Template Engine Factory and I'm having a small issue when trying to visualize the preview revision inside the History tab, I get this error, the way the template engine passes variables between the controller and the view is not recognized  ($view->set('myvar',$myvar)), is something fixable? Thanks

[teppo]

Hey @Sevarf2. Which version of Template Engine Factory is this? If it's 2.x, do you have auto_page_render setting enabled via module config?

I'm not particularly well versed in the inner workings of said module, but my initial assumption would be that it's related to the way it chooses which pages to render. It may also have something to do with hook priority, etc.

Anyway, let me know which version you're using, and I'll see if I can set up a quick test case.

[Sevarf2]

6 hours ago, teppo said:

Hey @Sevarf2. Which version of Template Engine Factory is this? If it's 2.x, do you have auto_page_render setting enabled via module config?

I'm not particularly well versed in the inner workings of said module, but my initial assumption would be that it's related to the way it chooses which pages to render. It may also have something to do with hook priority, etc.

Anyway, let me know which version you're using, and I'll see if I can set up a quick test case.

mmhhh never knew there was a 2.0 version...I was always relying on the automatic upgrade module and the 1.3 was the latest available...I'm gonna try it, maybe the issue will solve itself with the newer version, thanks

[Sevarf2]

Unfortunately (after a quick review) I can't use the 2.0 version of Template Engine Factory because I can't install other dependencies (twig) so I have to stick with the 1.1.3

[gornycreative]

Curious if there is a use case for this module in conjunction with ProDrafts. Is there still utility in being able to callback past version of field values outside the realm of full page drafts? Is it redundant to have both Version Control and ProDrafts on a site? Does having drafts enabled for a template/field make things more confusing for VC?

[Outward]

Thanks for a great module Teppo.

I don't suppose anyone has had success recording version control changes with front-end inline editing? I'm using inline editing on a personal project with just one specific field which is a large textarea (the rest use dialogue editor - works great).

Edit: Silly me, Version Control changes are indeed recorded with in-line editing. The field is within a repeater, so the front-end editor only saves changes to the repeater ID. It's still saved to the appropriate Version Control database tables.

[Arcturus]

Has anyone been able to install any of the 2.x versions of Version Control with PW 3.0.165? I keep running into the following error:

Quote

[04-Jan-2021 18:49:50 America/Denver] PHP Fatal error:  Uncaught TypeError: Argument 1 passed to ProcessWire\Modules::setModuleConfigData() must implement interface ProcessWire\Module, string given, called in /home/word/public_html/wire/core/Wire.php on line 397 and defined in /home/word/public_html/wire/core/Modules.php:3697
Stack trace:
#0 /home/word/public_html/wire/core/Wire.php(397): ProcessWire\Modules->setModuleConfigData('ProcessVersionC...')
#1 /home/word/public_html/wire/core/WireHooks.php(823): ProcessWire\Wire->_callMethod('setModuleConfig...', Array)
#2 /home/word/public_html/wire/core/Wire.php(465): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Modules), 'setModuleConfig...', Array)
#3 /home/word/public_html/site/modules/VersionControl/ProcessVersionControl.module(75): ProcessWire\Wire->__call('setModuleConfig...', Array)
#4 /home/word/public_html/wire/core/Modules.php(557): ProcessWire\ProcessVersionControl->__construct()
#5 /home/word/public_html/wire/core/Modules.php(1878): ProcessWire\Modules->newModule( in /home/word/public_html/wire/core/Modules.php on line 3697

 

[adrian]

@Arcturus - I think you should be using the dev branch - I believe that the 2.0 branch is obsolete. @teppo ?

[teppo]

1 hour ago, adrian said:

@Arcturus - I think you should be using the dev branch - I believe that the 2.0 branch is obsolete. @teppo ?

I'm pretty sure that aforementioned issue is now fixed in all the branches — but yes, you're correct, 2.0 branch is deprecated and the ones that are maintained — sort of — are dev (2.x) and master (1.x) 🙂

[PWaddict]

@teppo Thank you very much for this module. I have enable version control on some fields at the user template. I'm using PHP 7.4.9 and when I visit a user page I'm getting this PHP Notice:

Trying to access array offset on value of type int in C:\laragon\www\mysite\wire\core\WireDatabasePDOStatement.php on line 107

 

[teppo]

Hey @PWaddict!

So far I've been unable to reproduce that. I'm running PHP8, which should be close enough, but there are no warnings for me.

The error you've mentioned — assuming that you're using recent ProcessWire version — seems to point to WireDatabasePDOStatement::setDebugParam(), and more precisely it getting an integer as the param name. I've no idea how that could happen, and at the very least I can't find anything in Version Control that should (directly) cause it.

So... if you have any additional details, like where in the Version Control this error might originate, that'd be great. Also: which version of ProcessWire and which version of Version Control are you using?

[PWaddict]

5 hours ago, teppo said:

Hey @PWaddict!

So far I've been unable to reproduce that. I'm running PHP8, which should be close enough, but there are no warnings for me.

The error you've mentioned — assuming that you're using recent ProcessWire version — seems to point to WireDatabasePDOStatement::setDebugParam(), and more precisely it getting an integer as the param name. I've no idea how that could happen, and at the very least I can't find anything in Version Control that should (directly) cause it.

So... if you have any additional details, like where in the Version Control this error might originate, that'd be great. Also: which version of ProcessWire and which version of Version Control are you using?

I guess you have to switch to 7.4.x to actually get the notice. I'm using the PW master version 3.0.165 and the 1.3.1 of Version Control. It happens only on the pages where I have enabled Version Control. I tested it also on a brand new PW installation where only Padloper module installed and I'm getting the same notice on the php_errors.log.

[PWaddict]

@teppo I have on Laragon some older PHP versions installed and did some tests:

PHP 7.033 = Still getting the notice
PHP 5.6.40 = NO notice

So this is definitely a PHP 7 compatibility issue.

[teppo]

5 hours ago, PWaddict said:

I guess you have to switch to 7.4.x to actually get the notice. I'm using the PW master version 3.0.165 and the 1.3.1 of Version Control. It happens only on the pages where I have enabled Version Control. I tested it also on a brand new PW installation where only Padloper module installed and I'm getting the same notice on the php_errors.log.

Generally speaking PHP 7 and 8 tend to work similarly in these situations — PHP 5 was more "forgiving" 🙂

Anyway, it could be related to VC 1.3.1. I've been using VC 2.x for a very long time, will have to set up a test site for 1.x.

Edit: turns out it's an issue affecting PW < 3.0.166. At least this particular instance of it is pretty easy to circumvent; I've prepared a fix, but will have to test carefully before releasing it.

[teppo]

@PWaddict, the issue you reported earlier should now be fixed. Sorry for the delay.

[tires]

Is there an easy way to echo the number of page edits / versions?

Thanks!

[teppo]

On 7/14/2021 at 1:14 AM, tires said:

Is there an easy way to echo the number of page edits / versions?

Currently you could get this from the versionControlRevisions() method of the page. The value of said property is an array of all existing revisions, or null if none were found, so passing it to count() will tell you how many of those there were:

echo count($page->versionControlRevisions());

[tires]

On 7/14/2021 at 8:11 PM, teppo said:

Currently you could get this from the versionControlRevisions property of the page. The value of said property is an array of all existing revisions, or null if none were found, so passing it to count() will tell you how many of those there were:

echo count($page->versionControlRevisions);

Thanks for your answer!

But it outputs nothing although there are about 10 versions.

When i do a "print_r" it outputs a "1":

print_r($page->versionControlRevisions)

Any ideas?

[adrian]

Hi @teppo - just wondering your thoughts about this:

Would it be possible to not show entries when there is no change? I am actually curious what has triggered the entry in the first place - what could cause the entry to be registered if nothing was actually changed?

Thanks.

[teppo]

On 12/21/2021 at 9:54 PM, adrian said:

Would it be possible to not show entries when there is no change? I am actually curious what has triggered the entry in the first place - what could cause the entry to be registered if nothing was actually changed?

These seem very much related: there shouldn't be any need to skip over identical (consecutive) entries, since such entries shouldn't occur 🙂

In the latest dev version of the module I have some issues with image fields, where a) adding an image via AJAX is registered as a change, and then b) on page save field content is updated, also registering as a change. This could be related, perhaps? You could check which fields are involved by querying version_control__data and version_control__revisions database tables: the data table is connected to the revisions table with "revisions_id" column, and each row in the data table refers to a single fields_id + property pair, so there may be multiple data rows for each revision row.

I'm hoping to get the latest changes (currently in feature-data-objects branch at GitHub) polished and merged to dev, hopefully that will fix this issue as well. Fingers crossed that I'll get there soon. Any changes/updates to this module are pretty time consuming — part of why the feature-data-objects branch exists is to reorganise things, hopefully bringing sanity to the module's architecture 😅

[teppo]

On 7/20/2021 at 7:16 PM, tires said:

But it outputs nothing although there are about 10 versions.

When i do a "print_r" it outputs a "1":

print_r($page->versionControlRevisions)

Any ideas?

Sorry for taking "a while" to respond, completely missed this message. First of all it looks like this should've been versionControlRevisions() method, not property (my bad). That might've been the issue here.

If not, I'm not sure why print_r() returns 1 — I use it very rarely and am somewhat unfamiliar (and uncomfortable) with how it formats stuff. I'd start debugging by 1) using var_dump() or var_export() instead of print_r(), 2) checking with gettype() what type is returned and perhaps get_class() what class if it's an object, and/or 3) using Tracy Debugger to dump the value 🙂

[MindFull]

Happy to report this module has been fairly robust in some of our clients PW instances. Thanks for all your work!

One thing I noticed is that the revision timestamp is being generated by the database and not via PHP. So when the two services are on separate machines, with different timezone configurations, the timestamps don't match up with the activity on the web server. Just discovered this as one of our client's databases went down and a failover database in another zone took its place. Revisions were showing that the users had traveled to the future... 5 hours from now. 😄