--------------------------------------------------------------------------------
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 version: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 version: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":https://www.redmine.org)

--

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?

--------------------------------------------------------------------------------
If someone else experiences the same problem:

"fix_old_wiki_links_without_repo_identifier.sql":https://projektwerk.ucll.be/projects/extensions4redmine/repository/git-repo/revisions/master/entry/db_manipulations/fix_old_wiki_links_without_repo_identifier.sql is a template for a script to change this in the database, use at own risk, no warranty

HTH

--------------------------------------------------------------------------------

relates,Closed,26522,Repository routing bug when file path starts with (browse|entry|raw|changes|annotate|diff)/