Issue: Strange synonym creation

Okay it's even worse.

It does this on EVERY name change where it tries to create a redirect.

Also what permission do people need to change the name of an article without creating redirects?

I'm sorry but changing the name of an article is not a moderator/staff permission. I don't want to allow people to delete records, but do want them to be able to edit and update them and that includes the name.

I don't see an obvious problem in the code, so I will try to create a synonym prefix loop locally.

The editor currently needs "delete" permissions in order to change the title without also creating a synonym. This is because doing so removes the previous URL. Removing URLs is a higher level permission, because it has the potential to break all existing direct links.

In theory there is potential for new synonyms to steal synonyms from the target page, but I don't see how this creates a synonym loop all of a sudden, since it would require the synonym to receive the same information for both its name and its target, which never happens in any of my line-by-line tests. The code was unchanged for the past 5 years but somehow now there is a problem. Since the issue is cross-platform, it seems like a logical flaw in new PHP or MySQL releases, or possibly we are both running low on disk space or memory. But making the following edits fixed the problem for me.

In src/addons/vw/vw/_core/controller/dm/base/routable/vw.php, find:
Replace with:
In src/addons/vw/vw/_core/controller/dm/revision/vw.php, find:
Replace with:
This prevents new synonyms from being able to steal synonyms from other content, which doesn't really address the underlying issue -- why it's even attempting to do that in the first place.

Thanks, let's give this a go

I have found the reason for the loop. When saving a synonym, it verifies that the target exists and sets the target name to the existing name of the target. The problem is that during a rename, the target name is actually about to change. So the synonym gets created pointing to its own name but with the correct target ID. Then the final collections that are intended to point synonyms with no prior target to the new target if it matches, catches the synonym itself and changes the target ID to itself so that it becomes useless (with information about the originally intended target being lost forever).

The reason that the change in my earlier post had fixed the problem was somewhat of a coincidence, because the synonym was still being created based on the pre-rename information. Escalated the issue described in my earlier post to a security issue, as it's a permissions escalation (mass-dissociating of synonyms without permission to delete synonyms).

To fix the problem with wrong meta for new synonyms (existing affected synonyms to be fixed / removed as needed by the next upgrade), edit src/addons/vw/vw/_core/controller/dm/base/routable/vw.php. Find:
AFTER it, add:
In src/addons/vw/vw/_core/controller/dm/redirect/vw.php, find:
BEFORE it, add:
The bug appeared in 4.0.16, which released in early 2017.