page history messed up when pagename contains a dot

[schplurtz]

Hi,

I found a funny and strange bug. It's triggered by a dot in the pagename. I first noticed with the findbad.php history page. I originally thought .php was the cause, but any pagename with a dot shows the problem.

If you follow the do=revisions link, you get to a strange history page where only one link is present. This unique link links to ?do=media.

See this history https://www.dokuwiki.org/playground:eleph.pant?do=revisions

[ssahara]

This must be bug with #3361 . page name contains dot . is wrongly handled.
https://github.com/splitbrain/dokuwiki/blob/4ef5d38db53e045a81f129b29a8b886cecc38497/inc/ChangeLog/RevisionInfo.php#L35

Could I add more commit to fix this issue in #3607 ?

[splitbrain]

@ssahara please open a new PR for the fix.

[TherealperO]

Possible fix: #3730

Pardon me if I'm not doing this right.. My first time posting on GitHub.

[Klap-in]

Hi, it is indeed a option to look for the request parameters proposed, but probably there are exceptions on this approach.

The class modified is the abstract ChangeLog class. It is extended as MediaChangelog or PageChangeLog. So we always already know the type
The more robust approach could probably be to set the type in the constructor of MediaChangelog and PageChangeLog, which calls also the parent constructor for the general part.

Edit: ah, sorry I looked wrong, this about the RevisionInfo class, that one does not yet know page/media type. Then I have to look a bit further. Could it be that RevisionInfo is always initiated by a source that knows the type?

[Klap-in]

RevisionInfo is filled with an array, could you check if that array contains $info['media'], I guessed it is there, at least if it is set for the recent changes retrieved by the (global) getRecents() function. Not sure if it is set for all uses of RevisionInfo class?

[TherealperO]

Yup, we both found $info['media']. I've spent some time and came up with this #3731

[TherealperO]

This issue is now fixed with 8acc3ab and 8e8e73a to fix a minor issue with 8acc3ab.

[Klap-in]

Thanks for the contribution!

[TherealperO]

Glad to help!

[hilliesample]

I am adding this comment as it took me awhile to find this page. I was searching for "Old Revisions not working 2022-07-31a "Igor" as I didn't realize at first that it was related to the '.' in the page name. Hopefully this comment will help others find this page more easily. Thank you for the work on this issue.

[0x46616c6b]

Is it possible to have a new release with this fix in it? The issue is very confusing for users and they ask administrators if something is broken with there data at all. Would really appreciate when it would be fixed within a release. Thanks!

[bernhardbrunner]

Is it possible to have a new release with this fix in it? The issue is very confusing for users and they ask administrators if something is broken with there data at all. Would really appreciate when it would be fixed within a release. Thanks!

In the meantime you can just change the broken line 39 with the fix from 8acc3ab:

In File inc/ChangeLog/RevisionInfo.php:

39 # $info['mode'] = strrpos($info['id'], '.') ? 'media' : 'page';
40 $info['mode'] = $info['media'] ? 'media' : 'page';

This fixes the change history for paths with a . in it.

[0x46616c6b]

Sorry but this is not a good practice. I don't want to patch software on my machines after a new release is published. What is the problem with releasing a new version of Dokuwiki with this bugfix? I mean this bug breaks a really important functionality in that kind of software: the page history.