Defect #35885
open
- Related to Patch #26522: Repository routing bug when file path starts with (browse|entry|raw|changes|annotate|diff)/ added
Unfortunately, the previous routing implementation could lead to the wrong route being selected if there was e.g a directory named raw
in the default repository.
As such, the routing behavior was changed in 4.0.0 with #26522 to remove the routes without an explicit repository id and to make sure we always select the correct action and repo path.
Wim Bertels wrote:
[...]
So after upgrading, none of the links referring to repository with a name identifiers still work,
as they all point to https://../projects/../repository/raw/.. instead of https://../projects/../repository/repo_name_identifier/raw/..
Holger Just wrote:
[...]
As such, the routing behavior was changed in 4.0.0 with #26522 to remove the routes without an explicit repository id and to make sure we always select the correct action and repo path.
Just for the clarity on this matter, I presume that Redmine links ('source:', 'export:') were not affected by this change (i.e. they link to the new routes) as opposed to direct links which are affected as reported in this issue.
With that being said, it shouldn't be very difficult to restore the prior behavior by adding the removed routes to a custom plugin in case you are sure that you won't be affected by the issue reported in #26522.
Mischa The Evil wrote:
[...]
Just for the clarity on this matter, I presume that Redmine links ('source:', 'export:') were not affected by this change (i.e. they link to the new routes) as opposed to direct links which are affected as reported in this issue.
With that being said, it shouldn't be very difficult to restore the prior behavior by adding the removed routes to a custom plugin in case you are sure that you won't be affected by the issue reported in #26522.
that is helpful, i guess there is no way to hide 'source:' or 'export:' from the endviewer (as one can do with link to redmine)
--
i have looked at the db schema: it seems there a table wiki_contents and wiki_content_versions that hold the actual content of the wiki pages.
do you think it would be a problem using a direct UPDATE statement to change the affected links in the table wiki_contents
small test done:
- made a fresh wikipage with some content,
- UPDATE wiki_content_version table of that fresh wikipage
result:
- only 1 version in wiki_content_versions as expected
- different content in wiki_contents
- this different content gets shown on the wiki-website, but can't be found in the history
continu:
- edit this wikipage from redmine, a second version appears, the previously UPDATED content (together with this edit) is archived in the history as 1 version together
this behaviour is fine for my usecase, or do you expect problems with this approach?
Also available in: Atom
PDF