Module Version Control

[adrian]

@MindFull - have you tried setting the timezone of your MySQL server? I always do that on new installs and it seems to work to keep everything matched up. Here's a good tutorial on ways to achieve this: https://phoenixnap.com/kb/change-mysql-time-zone

I've always used option 1.

[MindFull]

@adrian - Thanks for that. That's usually what we do for the primary DB instance when we aren't using GCP. For us, setting the DB instance flags in Google Cloud SQL accomplishes the same thing via their admin console. In case anyone needs it: this is Google's reference for Cloud SQL's flags. Do note, there's a known issue that there's no automatic daylight saving adjustment.

I prefer to leave the UTC with no offset. I'll likely look at the module's source a little closer and modify the input/output timestamps from PW to match the client user's timezone.

[teppo]

On 1/29/2022 at 7:53 AM, MindFull said:

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

That does seem like an issue. I have a vague memory that I might've had to make changes related to the timestamps at some point in the past, but can't remember what it was all about. For the time being I'll open a GitHub issue for this, as it might require a bit of digging and testing to make sure that everything works as expected ?

[gebeer]

@teppo can this module handle multilang fields? Couln't find anything in the module description or this thread.

[teppo]

25 minutes ago, gebeer said:

@teppo can this module handle multilang fields? Couln't find anything in the module description or this thread.

README lists three supported multilingual fieldtypes:

• Text (regular and multi-language)
• Textarea (regular and multi-language)
• Page Title (regular and multi-language)

Technically other multilanguage fieldtypes should be supported as well, but these are the ones I've tested. Version Control has a config setting for enabling fieldtypes that are available on the site, but not listed as compatible by default.

[Didjee]

Hi @teppo, first of all, thank you for this wonderful module! Do you see a possibility that ProFields Table will be supported in the future? I am certainly willing to sponsor (part of) the development costs for this!

[prestoav]

Thanks for the great module!

Sadly, I'm now seeing error after updating my MAMP install to PHP 8.0.8. See errors below, other versions numbers for this install are:

PW 3.0.200
VersionControl 2.4.0 / VersionControl Cleanup 1.0.0 - this error doesn't occur with VersionControl 1.3.5 without the cleanup module.

Errors on admin pages:

Warning: scandir(db/variations): Failed to open directory: No such file or directory in .../site/modules/VersionControl/VersionControlCleanup.module on line 117
Warning: scandir(): (errno 2): No such file or directory in .../site/modules/VersionControl/VersionControlCleanup.module on line 117
Warning: foreach() argument must be of type array|object, bool given in .../site/modules/VersionControl/VersionControlCleanup.module on line 118
Warning: scandir(db/): Failed to open directory: No such file or directory in .../site/modules/VersionControl/VersionControlCleanup.module on line 124
Warning: scandir(): (errno 2): No such file or directory in .../site/modules/VersionControl/VersionControlCleanup.module on line 124
Warning: Cannot modify header information - headers already sent by (output started at .../index.php:55) in .../wire/core/WireHttp.php on line 1688

Error trace box content:

Look out… Fatal Error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, bool given in site/modules/VersionControl/VersionControlCleanup.module:124

#0 site/modules/VersionControl/VersionControlCleanup.module (124): count(false)
#1 site/modules/VersionControl/VersionControlCleanup.module (95): VersionControlCleanup->cleanupFiles()
#2 wire/core/Wire.php (417): VersionControlCleanup->cleanup(Object(HookEvent))
#3 wire/core/WireHooks.php (1062): Wire->_callMethod('cleanup', Array)
#4 wire/core/Wire.php (485): WireHooks->runHooks(Object(LazyCron), 'everyDay', Array)
#5 wire/modules/LazyCron.module (198): Wire->__call('everyDay', Array)
#6 wire/core/WireHooks.php (1059): LazyCron->afterPageView(Object(HookEvent))
#7 wire/core/Wire.php (485): WireHooks->runHooks(Object(ProcessPageView), 'finished', Array)
#8 index.php (56): Wire->__call('finished', Array)
#9 {main}
thrown (line 124 of site/modules/VersionControl/VersionControlCleanup.module)

Seems to refer to this line (124 of the Cleanup module):
 

if (count(scandir($dir)) == 1) wireRmdir($dir, true);

Sadly my knowledge / understanding of what's going on ends here but hoping it can be fixed or it is something else in my install.

[adrian]

Hi @teppo - firstly, just another mention of how important this module is to me - it's always one of the very first installed on every site, so thank you :)

Now to some issues / suggestions if I may.

1) We often find lots of revisions listed for a field that simply return "There is no difference between these revisions". I don't really understand why a revision is stored if there were no changes made. It seems like unnecessary DB bloat, but more importantly, it makes it very hard to find the revisions where changes actually are made. Do you think this behaviour could be changed so that no revision is stored?

2) We often see changes to page reference fields (checkboxes in this case, but I expect it probably doesn't matter the inputfield type) where changes are recorded, but in reality, they weren't actually changed - why would they be recorded as being removed and then added again?

 

3) When you have a page template where the width of fields is a small percentage (25%, 33%, etc), the interface for viewing the revision history is quite awkward, with lots of horizontal and vertical scrolling required. I was wondering whether you think it might be a better experience to load the revisions in a PW panel (pw-panel - https://processwire.com/blog/posts/pw-3.0.15/)

Thanks so much for considering and let me know if there is any way I can help with any aspect of this.

[netcarver]

Maybe 1) could have a configuration option?

[teppo]

On 3/28/2023 at 12:52 PM, Didjee said:

Hi @teppo, first of all, thank you for this wonderful module! Do you see a possibility that ProFields Table will be supported in the future? I am certainly willing to sponsor (part of) the development costs for this!

 This is something that I may need as well, so will look into that, soon(ish) I hope ?

On 4/12/2023 at 2:00 PM, prestoav said:

Thanks for the great module!

Sadly, I'm now seeing error after updating my MAMP install to PHP 8.0.8. See errors below, other versions numbers for this install are:

Thanks for the report, I'll look into this. Sounds like paths are somehow messed up.

1 hour ago, adrian said:

1) We often find lots of revisions listed for a field that simply return "There is no difference between these revisions". I don't really understand why a revision is stored if there were no changes made. It seems like unnecessary DB bloat, but more importantly, it makes it very hard to find the revisions where changes actually are made. Do you think this behaviour could be changed so that no revision is stored?

Just to be clear, are these consecutive revisions for a field where there are no actual changes between those revisions? If so, it definitely sounds like a bug. It is not intentional to store a revision when/where there are no changes in it.

Which version of VersionControl is this on, and are you able to reproduce this easily or does it occure randomly / rarely? What type of field is this? Does the error occur on API use, or while editing the page via admin?

Any chance that you might've come across these on a "blank" setup, just to rule out conflicts caused by hooks, other modules, etc.?

It's been a while since I touched the code related to this, but based on a quick look it seems that VersionControl only stores data if $page->isChanged($page_field->name) returns true, so basically it sounds like ProcessWire itself is saying that the field has changed. There's only one exception to this, but that is only applicable to when module configuration is saved/changed, so it would be odd if that was the cause.

Do you have any idea why ProcessWire might report these fields as changed, even if they aren't? I don't think I've run into this particular problem myself, though isChanged() has always felt somewhat "quirky" to me, or rather I've never quite understood where and when it works or doesn't work ?

1 hour ago, adrian said:

2) We often see changes to page reference fields (checkboxes in this case, but I expect it probably doesn't matter the inputfield type) where changes are recorded, but in reality, they weren't actually changed - why would they be recorded as being removed and then added again?

This also seems odd. It would make sense if order would've changed, but here it sounds like something is marking the field as "changed" even though it has not. It might have something to do with your first point, though at this point I'm just guessing. Again, this is not something I've observed myself, as far as I can recall.

1 hour ago, adrian said:

3) When you have a page template where the width of fields is a small percentage (25%, 33%, etc), the interface for viewing the revision history is quite awkward, with lots of horizontal and vertical scrolling required. I was wondering whether you think it might be a better experience to load the revisions in a PW panel (pw-panel - https://processwire.com/blog/posts/pw-3.0.15/)

That is a good point. For 2.x I did consider redesigning the interface, but if I recall correctly, I figured that current interface feels better for most use cases. There may have been technical issues as well, though I can't quite remember what they might've been.

I'd be happy to give this a shot again some time, though not sure about the timeline ?

[adrian]

Hi @teppo - sorry for the delayed response.

#1 - from what I can tell, the instances of "There is no difference between these revisions." are only an issue when saving via the API (in this case a frontend form). Not sure if it matters (seems unlikely), but it is an AJAX saved form and fields are saved with "setAndSave()" - maybe that is a factor?

#2 - is this case, it's an admin save.

[TheMick]

Does this module work with Repeater / Repeater Matrix in the current version? After the posts of adrian and zoeck in 2018 I did not read anything about this.

And thanks for this awesome module @teppo!

[gebeer]

29 minutes ago, TheMick said:

Does this module work with Repeater / Repeater Matrix in the current version? After the posts of adrian and zoeck in 2018 I did not read anything about this.

And thanks for this awesome module @teppo!

As it happens, I looked into this with the latest version just a couple of days ago on a PW 3.0.208 install with Repeater Matrix and nested Repeaters inside Matrix items. Unfortunately there seems to be no support for Repeater Matrix.

[snck]

Hey @teppo, I occasionally noticed some PHP Warnings when editing pages that use repeaters:

PHP Warning: Attempt to read property "type" on null in .../modules/VersionControl/ProcessVersionControl.module:668

Could be changed to the following to suppress the warning:

// before
if ($diff && wire('fields')->get($field)->type instanceof FieldtypeFile) $diff = "";

// after
if ($diff && wire('fields')->get($field) !== null && wire('fields')->get($field)->type instanceof FieldtypeFile) $diff = "";

Maybe something that could be addressed in a future release?