From comments this seems to be incorporated by 11

Okay, I believe this isn't as big a deal in later versions of 11 because of

https://sakaiproject.atlassian.net/browse/SAM-2594#icft=SAM-2594 https://sakaiproject.atlassian.net/browse/SAM-2595#icft=SAM-2595 https://sakaiproject.atlassian.net/browse/SAM-2596#icft=SAM-2596

However this is still a problem on 10.x because https://sakaiproject.atlassian.net/browse/SAM-1596#icft=SAM-1596 was merged into 10. So I feel like merging https://sakaiproject.atlassian.net/browse/SAM-3186#icft=SAM-3186 into 10 is the best course of action. Any maybe just removing this eventually.

Idea for implementation:

Replace the replaceAll method in replaceSiteIdsForString with a replaceAllFn http://stackoverflow.com/a/13932688/3708872 In this method check to see if the destination actually exists (ideally through the CHS api).

I also feel like this behavior backported to 10.6 isn't great since it's functionality change in a minor release that can't be disabled. It's already coming up for some of our users.

I still feel like it's a bug so I'm reopening as the title does describe the problem. I think the solutions need to either be

• Provide an option during the publish to either update (or not update) the links when publishing. I don't feel like it should be doing this automatically. We have many use cases where it shouldn't be happening automatically.

Or possibly better

• Before updating the links, actually verify if the link going to be updated in https://sakaiproject.atlassian.net/browse/SAM-1596#icft=SAM-1596 exists in the destination location. If it doesn't don't do the update. It's quite possible that the students could access the link perfectly fine where it was without doing any URL rewriting.