The more I explore the module VersionControl, the more I discover great features like the little clock icon next to the input in the admin module for fields included for version control (see screenshot below).

Hovering over the clock icon reveals the list of revisions for the field which then in turn can be compared with the latest revision of the field.

Whereas this feature seems to produce correct results for standard input fields, it produces some erroneous results for multi-language fields.

Since there is only one icon for a multi-language field (see screenshot above) it is not possible to have separate revision histories for the different languages.

Currently the result is a mixture of diffs between languages depending on the languages modified per revisions. So it can be that a change to the German version is compared with the latest English version. A comparison with the latest German version does not seem possible.

For a correct implementation of this feature with multi-language fields, we would probably need to have a clock icon for each language and create a history for each language separately.

A really helpful feature in the context of multi-language fields might be a function which allows to compare two languages and show the differences applied to one language since the last time the other language has been updated. This would help the translator to know what he needs to change without having to read the whole text again in both languages.

The text in the compare container does not wrap to new lines since the parent td has white-space set to nowrap;.

ProcessWire 3.0.91 

As you can see in the screenshot my field outputs d.m.Y H:i:s, but when I show the diff of a previous version it just shows the timestamp and not the previous date.
This is not a good user experience.

If VersionControl is added to one single template, the tab will appear in every page UI.

The hook in ProcessPageEdit::getTabs() added by init() is assigned if the property (array) $enabled_templates is not empty. This check is a bit lazy.

Solution:
Move the hook inside hook function buildFormHistory() Line 971 after checking data:

if (!$data) return;
$this->addHookAfter('ProcessPageEdit::getTabs', $this, 'addTabHistory');

Hi @teppokoivula - I am seeing these errors in my Tracy error logs:

https://mysite.com/admin/setup/version-control/page?pages_id=1342&settings%5Bempty%5D=true&settings%5Brender%5D=HTML

PHP Notice: Trying to get property 'type' of non-object in /var/www/html/site/modules/VersionControl/ProcessVersionControl.module:662

Please let me know if you need anything else to track down the cause.

Hi @teppokoivula - I fixed it quickly by replacing count() with wireCount()

VersionControl does at the moment of its installation not store the initial values of TextareaLanguage (Textarea [Multi-language]) fields. To be specific probably all fields which store there data with the class LanguagesPageFieldValue.
I have been testing it again on the latest release version 1.2.9 by installing VersionControl on my test site and activating it for two fields on one template. The two fields are of type:

• Textarea (normal single language text)
• TextareaLanguage (multi-language)
  When I check the table "version_control__data" I find only entries for the field of type "Textarea" whereas there are no entries at all for the field of type "TextareaLanguage".
  As far as I can tell, there is an issue with the function used to find the data of fields of type "TextareaLanguage" at the time of installation of the module: $data->getChanges() will only return changes made to the data of the instance of $data at run-time which is the case when this code finds changes to a field of type "TextareaLanguage". But when the module is newly installed the function $data->getChanges() will return nothing since the field data is in it's original state as stored in the database table.

                } else if ($data instanceof LanguagesPageFieldValue) {
                    foreach ($data->getChanges() as $key) {
                        if ($key == 'data') continue;
                        $data_array[$key] = $data->getLanguageValue(str_replace('data', '', $key));
                    }
                } else {

(see code on github here)

I have done some research on how the data is stored internally at run-time and on the database and I hope that my patch addresses the problem correctly: Every language value, including the default language, is stored under a key 'data'.$language->id, the same way the function getChanges() returns the keys.

I have made a suggestion for how to changes this on my fork. There is a pull request available.

It appears that for Page fields that can contain multiple pages and are entered using the AsmSelect input field type, values are not saved. Saving the page clears this type of fields.

Add width: auto !important; to .field-revisions class.

VersionControl.css (line 39)

.field-revisions {
    width: auto !important;
    padding: 36px 0 0 0 !important;
    overflow: visible !important;
    position: absolute;
    margin-top: -28px;
    display: none;
    z-index: 99;
    right: 10px;
}

Hi @teppokoivula - I have a textarea field that user are inserting emojis into and because VersionControl doesn't set up its DB tables and fields as utf8mb4, I get the error mentioned in the title.

I manually adjusted the tables and relevant fields and it's all good now, but it would be good if the module handled this by default.

Thanks,
Adrian

Self explanatory :)

Hi @teppokoivula - I've been getting this when trying to remove fields from templates. It prevents me from removing the fields.

I assume this is a PHP8 only issue, but not certain.

Installing this module in my ProcessWire 3.0.42 (on Windows 10 XAMPP) throws the following error:
Call to undefined function finfo_open()
...\site\modules\VersionControl\VersionControl.module:844
$finfo = finfo_open(FILEINFO_MIME_TYPE);
But after reloading the page the error does not appear.

The question I have concerns version history of pages that are deleted. My understanding from reading the documentation some months ago was that, if a page of content is deleted, then the corresponding VCS history is deleted.

Essentially the basic requirement is to be able to track and potentially restore deleted content. Is that a possibility?

As explained in https://processwire.com/talk/topic/6333-version-control/?do=findComment&comment=221082, current method of handling timestamps can be problematic due to relying on the timezone of the database.

xdebug says
Deprecated: implode(): Passing glue string after array is deprecated. Swap the parameters in VersionControl.module on line 216

Having many of such erros in my logs:

PagePathHistory::getPage() - SQLSTATE[42S22]: Column not found: 1054 Unknown column 'language_id' in 'field list'

Seems to come with the URL en/http404.

How to fix that?

Hi @teppokoivula - running the latest dev version and seeing that warning on PHP 8.1.

Thanks!

There are unnecessary scroll bars on the revisions div:

Possible fix: change...

.field-revisions > div {
    overflow: scroll !important;
}

...to...

.field-revisions > div {
    overflow: auto !important;
}

Hi @teppokoivula - just saw this when removing an image field from several templates via its "Actions" tab.

Not a big deal, but thought I should report anyway.

Hi, I have tried your module but get:

{"error":true,"message":"Missing required GET param pages_id"}

output on top of the page after saving.

I also wonder where to find the history of all page edits.

In the readme, the information is missing how to access the page history and revert. Can you please add this. It would help others too.

Hi @teppokoivula - would you mind appending the tab hash to the url when clicking page links on the history tab, eg: /edit/?page=2&id=10416#VersionControlHistory

Currently it loads the edit page on the main content tab which isn't ideal. Or maybe the tab can be triggered the same way the PW core does when you save a page and you're on a different tab at the time. I haven't looked into how this is done.

Thanks.

Seeing this on PHP8.2. That's it really :)

1×
PHP Deprecated: Creation of dynamic property VersionControl\ModuleConfig::$data is deprecated in .../html/site/modules/VersionControl/lib/ModuleConfig.php:25
1×
PHP Deprecated: Creation of dynamic property VersionControl\ProcessModuleConfig::$data is deprecated in .../modules/VersionControl/lib/ProcessModuleConfig.php:25
1×
PHP Deprecated: Creation of dynamic property VersionControl\CleanupModuleConfig::$data is deprecated in .../modules/VersionControl/lib/CleanupModuleConfig.php:25

Hi @teppokoivula - seeing this in the latest version (committed yesterday) whenever I save a page. It looks like you just need to change all instances of $object with $page, but maybe I am missing something.

Let me know if you have any problems reproducing.

BTW, I am running PHP8 and everything else so far seems fixed with this new version.

Copying this over from a forum comment that might have been overlooked.

The Version Control module is preventing the red asterisk from appearing in the header of required fields. The relevant admin CSS is:

.InputfieldStateRequired>.InputfieldHeader:first-child:after {
    content: ' *';
    color: #C00C19;
}

The addition of the field-revisions div interferes with this.

P.S. This relates to the dev branch - not sure if the v1 branch is also affected.

It would be great if there were some hookable methods in the module that allowed for special treatment to be applied to non-core fieldtypes. I'm imagining hooks that let a developer modify the history data that is saved to the database, and modify the result of that data when it is restored to a field.

For instance, I tested with FieldtypeMapMarker and the history and diff parts seemed to work okay but the restore action failed because the saved data needs to be converted into an object of the right class.

Hi @teppokoivula

I am seeing new entries with that text for certain field types. For some field types it only happens if I use setAndSave(), but for others, it happens even with a regular save().

The save is happening via an AJAX call and I don't do any checking on old (already in the DB) vs new (values submitted via the form) so I am always setting the value of every field as part of the save process. Not sure if that is relevant or not though.

For text and date fields it's only an issue if I do setAndSave(), but for page reference fields, it happens regardless of how I save. Another problematic field type is my phone field which also gets a revision entry regardless of how I save.

I wonder if perhaps the easiest way to fix this would be to have an option to not record a revision if there is no change?

OT, but back to the phone field - it only supports the main number subfield - do you think it would be possible to support the country subfield as well?

This idea came up in an otherwise unrelated forum thread: it would be pretty neat to be able to export and then import (same site, or a different site altogether) revision data. Definitely something to keep in mind, though probably not a top priority feature.

Hi @teppokoivula - I am seeing this error in the browser console when viewing a user page (Access > Users > xxxxxx). It seems to be coming from the History tab.

Obviously you'll need version control on for some of the fields on the user template. Please let me know if you have any problems reproducing.

Thanks.

Related support forum discussion: https://processwire.com/talk/topic/6333-version-control/?do=findComment&comment=188031

Hi, I'm running on a fresh processwire install with a fresh install of the module. No third party/incompatible field types are being used. Tracked templates and fields have been configured properly upon module installation.;

Clicking the "Restore Revision" button on the history tab of a page for some revision will show the message that "Page restored to revision #X", however, the page content and the field values never get changed to the values in the revision that was supposed to be reverted to.

Edit: I can, however, revert an individual field to a selected revision. Reverting the entire page "acts" as if it worked, but none of the content is actually reverted changed.

This happens when you have RepeaterMatrix fields (I don't think it affects normal Repeater fields) on the page.

The fields end up being named things like: body_repeater2143

Maybe not the best fix, but as I quick test, I confirmed that if you add this line before Line 654, it fixes it:

$field = preg_replace('/\d/', '', str_replace('_repeater','', $field));

@teppokoivula - I have other users with the user-admin permission, but when I have version control enabled for the user template (I have a biography textarea field here), then they get this error. It doesn't affect their ability to edit, but it's obviously in error still.

I am using the alternate user parent / template setup so maybe that is contributing to the problem?

Thanks.

Hi @teppokoivula - I get this when clicking the eye icon on the history tab. wireCount() does take care of it if you want to take that approach.

Thanks!

I am wondering if I misunderstand the concept of this module or if this is an actual bug.

Let's say, I have a template with two fields A and B which I have added to VersionControl. Then I apply the following changes:

1. Change field A to the value A2
2. Change field B to the value B2

This results in the following revision history:

If I now restore (or preview) Revision 2, I would assume that I get the following values A = A2 and B = B1.

But what I get is A = A2 and B = B2. Which means no change at all and VersionControl ignores the request to restore to Revision 2.

As far as I understand from the code, this happens, because VersionControl in order to restore a revision, clones the current page and applies the requested revision (2 in this case). The result is the above A = A2 and B = B2. And not what I would expect A = A2 and B = B1.

All would work fine if I had changed both fields at every step. But this is generally not the case.

With the current setup, I can only see one solution to the problem on how to restore a revision:

1. clone the page
2. apply all the revisions from revision 1 to the requested revision, in this way we would end up with A = A2 and B = B1.

This is an issue I have noticed when working on the issue raised about restoring revisions and testing it with different types of fields. It must be only related on how the changes to "Repeater" fields are shown in the admin revision history tab. The changes are properly recorded in the "version_control__data" and "version_control__revisions" tables and can also be restored from their.

Hi @teppokoivula - this is new in 2.4.6.

I think it's just a matter of changing to:

$this->readPageData($event->arguments[0], $event->arguments[1]);

so that the second argument to the function is 1 rather than 0

Hi @teppokoivula - I think it would be very handy to have the revision popup available from the history tab for each field. When you have a template with lots of fields with version control enabled, it can be very useful to look at the history tab to see what has actually changed, and accessing the diffs from here would make it even more useful, I think.

Mostly OT, but I would also like to see a close "X" on the popup - I find some users struggle to close it, not realizing they need to click the same icon again.

Trailing comma on last argument causes a parse error: