Fixing Strict URLs When Alias Replacements Touch the Wrong Links

Strict URL normalization is useful until the replacement logic gets too greedy. On some legacy sites, a URL plugin rewrote one intended path and accidentally modified other links that only partially matched the same pattern.

The root cause

The donor case described a plugin loop that used preg_replace to normalize a container URL such as /kursyi.html into /kursyi/. Because the suffix and alias parts were not escaped carefully enough, the same replacement could also affect links like /kursyi-html.html or nested pages such as /kursyi/html-php.html.

Why this happens

• the regex pattern is broader than the intended exact URL
• suffix characters such as the dot in .html are treated as regex operators
• replacement runs in a loop across the whole output buffer

The practical fix

Escape the friendly URL suffix and any dynamic alias parts before building the regex. The old article specifically pointed to the need to treat the suffix as a literal string rather than a pattern fragment.

Rule of thumb

If a URL plugin works by scanning and replacing links in final output, test it against edge-case aliases and nested paths. Exact URL normalization is safe. Broad text replacement is not.