Open Bug 1867499 Opened 11 months ago Updated 1 month ago

Capitalization errors in KB article, template and image titles are no longer ignored, causing broken links and missing content

Categories

(support.mozilla.org :: Knowledge Base Software, defect)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
defect

Tracking

(Not tracked)

People

(Reporter: alice.wyman, Unassigned)

References

Details

(Posted earlier this week, in the SUMO room on Matrix)
I noticed that, when creating new KB content or editing a KB article, mistakes in capitalizing the title of a KB article you want to include as a link will cause the link to break. This also happens in KB article discussions. For example, [[Access Mozilla Services with a Mozilla account]] no longer works (you get the "Create a new Knowledge Base article" page) but if you correct the title to [[Access Mozilla services with a Mozilla account]] (Services-> services) the link works. My post at https://support.mozilla.org/en-US/kb/access-your-add-ons-firefox-accounts/discuss/11806#post-25925 shows what happens. If I remember right, capitalization errors didn't matter before, because the article title would correct itself. It no longer does. Was there a recent change to KB software that could have caused this?

See also https://support.mozilla.org/en-US/kb/subscribe-hubs/history and https://support.mozilla.org/en-US/kb/access-your-add-ons-firefox-accounts/history where I resubmitted the previous edits to fix the wikilink capitalization, which were marked before as minor edits.

Something else I noticed. Go to https://support.mozilla.org/en-US/kb/category/20 and check these links:
Access Mozilla services with a Firefox account
Access Mozilla services with a Mozilla account
Access Mozilla Services with Firefox Account
Access Mozilla Services with Firefox Accounts

The 3rd link, https://support.mozilla.org/en-US/kb/access-mozilla-services-firefox-account-redirect-1 for the article title "Access Mozilla Services with Firefox Account" goes to a "Create a new KB article" page.
Now add ?redirect=no to the end of that URL: https://support.mozilla.org/en-US/kb/access-mozilla-services-firefox-account-redirect-1?redirect=no
...which takes you to the KB article page "Access Mozilla Services with Firefox Account" showing:
REDIRECT Access Mozilla Services with a Firefox Account ... but that links to a "Create new article" page. I think something weird is happening.

This problem also affects templates. The article https://support.mozilla.org/en-US/kb/how-do-i-turn-do-not-track-feature had a capitalization error in Template:closeOptionsPreferences ("close" was capitalized) and step 4 said this: "The template "CloseOptionsPreferences" does not exist or has no approved revision."
The article has had [[T:CloseOptionsPreferences]] since its inception. A revision to fix the error was just approved. See https://support.mozilla.org/en-US/kb/how-do-i-turn-do-not-track-feature/history

Summary: Capitalization errors in KB article titles and templates are no longer ignored, causing article display issues → Capitalization errors in KB article titles and templates are no longer ignored, causing broken wikilinks and missing template content

Related issue... or is this a separate bug?
Adding an extra space when linking text to a KB article causes the link to fail. An [[article | text]] link, with a space after the article title, takes you to the "Create a new Knowledge Base article" page. An [[article|text]] without a space takes you to the KB article.
For example, the "content blocking" link in the https://support.mozilla.org/en-US/kb/what-happened-tracking-protection article goes to https://support.mozilla.org/en-US/kb/new?title=Content+blocking+
The link also fails in article discussion. See: https://support.mozilla.org/en-US/kb/what-happened-tracking-protection/discuss/11873

I've been reviewing numerous revisions with title capitalization errors for KB article links and templates. This bug also affects images. The Content for https://support.mozilla.org/en-US/kb/templateopendownloadslibrary/revision/225220 says this ("Menu" should not be capitalized):
Click the menu The image "fx89MenuButton" does not exist. button and click Downloads from the menu.

Summary: Capitalization errors in KB article titles and templates are no longer ignored, causing broken wikilinks and missing template content → Capitalization errors in KB article, template and image titles are no longer ignored, causing broken links and missing content

Emil, can you see if you can verify this issue?

Flags: needinfo?(eghitta)

Hey Kiki,

I've already pinged Ryan about this one. We think that this is caused by our migration to Postgres (because we're no longer using the case-insensitive collation that we had in place for MySQL). Mistakes in case will affect the outcome of a search for a particular resource (image or article).

Filled under https://github.com/mozilla/sumo/issues/1605

Engineering is currently looking into it.

Thanks!

Flags: needinfo?(eghitta)
See Also: → https://github.com/mozilla/sumo/issues/1605
Summary: Capitalization errors in KB article, template and image titles are no longer ignored, causing broken links and missing content → Capitalization errors in KB article, template and image titles (and extra space after article title in text links) are no longer ignored, causing broken links and missing content

I noticed that, after I edited the title for some KB articles to remove unneeded capitalization (for example, I changed "Using Pocket Offline" to Using Pocket offline" and "Getting Started with Pocket for Android" to "Getting started with Pocket for Android" for the https://support.mozilla.org/en-US/kb/using-pocket-offline and https://support.mozilla.org/en-US/kb/getting-started-with-pocket-for-android articles) any wikilinks using the old titles no longer linked to the articles but instead opened in the "Create a new Knowledge Base article" page (no redirects were created). This was fixed for one article that included two such wikilinks - see https://support.mozilla.org/en-US/kb/using-pocket-on-kindle-devices/history - but other articles may be affected.

Thanks for your patience. A pull-request that restores the case-insensitive title search behavior prior to Postgres is in review.

(In reply to Ryan Johnson (:rjohnson) from comment #6)

Thanks for your patience. A pull-request that restores the case-insensitive title search behavior prior to Postgres is in review.

Thanks for the update. Will this also fix the "extra space after article title in text links" issue (see comment 1) or is that a separate bug?

Can you update the status?

Flags: needinfo?(rjohnson)

We decided against the earlier pull-request that restores the case-insensitive title search behavior, because it introduces new problems, as outlined in https://github.com/mozilla/sumo/issues/1605#issuecomment-1977030222:

If we allow case-insensitive matching at all, it sets up the following possible problems:

Set-Up -- Create a wiki link whose title is not an exact match to an existing image.

  • An image with the title Test Image exists.
  • Someone creates the wiki link [[Image:Test image]]
  • When rendering the article, we can't find an image with the exact title Test image, but doing a case-insensitive search by title yields the image with the title Test Image
  • The link is created.

Possible Problems:

  1. A "malicious" user could upload any image with the exact title Test image, and when the article containing the wiki link is next rendered, it'll link to that "malicious" image because it has the exact title requested in the wiki link.
  2. A "malicious" user could upload any image with any title that is a case-insensitive variation, but doesn't conflict with existing image, for example an image with the title test image or test Image or TEST IMAGE, and now because two case-insensitive variations exist, we don't know which one is intended, so the link will be broken when rendered.

Conclusions

So we can't allow case-insensitive fall-backs for images and articles. it just opens a Pandora's box of problems.

The case-insensitivity worked when we were using MySQL because it was baked into the database collation. If someone tried to upload an image Test Image when an image titled test image already existed, you'd get a database conflict. Since we're now using Postgres with its default case-sensitive collation, someone can upload images titled Test Image and Test image without a problem, because they differ in case, and because of that, I think we have to remain consistent and insist on exact titles in wiki links.

So, I'm thinking the best way forward might be to keep things the way they are -- exact title matches are required -- and then provide one or all of the following:

  • If when rendering a wiki link, we don't find an exact match, but find one or more case-insensitive matches, instead of providing a link to create a new article or showing a message that the image doesn't exist, for both articles and images we show a message saying that the requested title doesn't exist, but did they instead intend one of the case-insensitive title matches we found.
  • Perhaps create a new tool or dashboard, that finds and reports broken links in all articles, and notes the ones with case-insensitive matches.
Flags: needinfo?(rjohnson)

Thanks for the followup. On the conclusion:

I agree with your second point, that we need a tool or dashboard that finds and reports broken links in all articles and notes the ones with case-insensitive matches. On your first point, we'll also need to address the problem of changing the title of an article when only the case of words in the title is changed, so a redirect is created (see comment 5). At the very least, a message should be shown when editing the article title.

Kiki, what do you think?

Flags: needinfo?(kelimutu)

(from comment #10)

Thanks for the followup. On the conclusion:

I agree with your second point, that we need a tool or dashboard that finds and reports broken links in all articles and notes the ones with case-insensitive matches. On your first point, we'll also need to address the problem of changing the title of an article when only the case of words in the title is changed, so a redirect is created (see comment 5). At the very least, a message should be shown when editing the article title.

Kiki, what do you think?

Changing NeedInfo to Lucas.

This bug is causing erroneous creation of new articles when links (or redirects) for articles that have a capitalization error go to the 'Create a new Knowledge Base article" page. If the user actually creates a new article, it may then be considered spam. For example, see https://support.mozilla.org/en-US/kb/search-with-the-firefox-address-bar/discuss/12125 ( this link will be a 404 Page Not Found if you don't have SUMO reviewer permission)

Flags: needinfo?(kelimutu) → needinfo?(lsiebert)
See Also: → https://github.com/mozilla/sumo/issues/1710

(from comment #1)

Related issue... or is this a separate bug?
Adding an extra space when linking text to a KB article causes the link to fail. An [[article | text]] link, with a space after the article title, takes you to the "Create a new Knowledge Base article" page. An [[article|text]] without a space takes you to the KB article.
For example, the "content blocking" link in the https://support.mozilla.org/en-US/kb/what-happened-tracking-protection article goes to https://support.mozilla.org/en-US/kb/new?title=Content+blocking+
The link also fails in article discussion. See: https://support.mozilla.org/en-US/kb/what-happened-tracking-protection/discuss/11873

See https://github.com/mozilla/sumo/issues/1710 Extra space in article links causes the link to break #1710

Hi Alice! Thank you for your detailed feedback and persistence in addressing these issues. Although not ideal, incorporating checks for them into our current audit (https://blog.mozilla.org/sumo/2024/04/18/freshening-up-the-knowledge-base-for-spring-2024/) might be a feasible immediate solution, given we won’t move forward with https://github.com/mozilla/sumo/issues/1605#issuecomment-1977030222. I’ll bring this up with the Content Team and we will revisit this Bugzilla thread with updates once we’ve settled on a resolution.

Flags: needinfo?(lsiebert)

(In reply to Ryan Johnson (:rjohnson) from comment #9)

We decided against the earlier pull-request that restores the case-insensitive title search behavior, because it introduces new problems, as outlined in https://github.com/mozilla/sumo/issues/1605#issuecomment-1977030222:
<snip>
So, I'm thinking the best way forward might be to keep things the way they are -- exact title matches are required -- and then provide one or all of the following:

  • If when rendering a wiki link, we don't find an exact match, but find one or more case-insensitive matches, instead of providing a link to create a new article or showing a message that the image doesn't exist, for both articles and images we show a message saying that the requested title doesn't exist, but did they instead intend one of the case-insensitive title matches we found.
  • Perhaps create a new tool or dashboard, that finds and reports broken links in all articles, and notes the ones with case-insensitive matches.

(In reply to Lucas Siebert from comment #13)

<snip> Although not ideal, incorporating checks for them into our current audit (https://blog.mozilla.org/sumo/2024/04/18/freshening-up-the-knowledge-base-for-spring-2024/) might be a feasible immediate solution, given we won’t move forward with https://github.com/mozilla/sumo/issues/1605#issuecomment-1977030222. I’ll bring this up with the Content Team and we will revisit this Bugzilla thread with updates once we’ve settled on a resolution.

Any updates?

Flags: needinfo?(lsiebert)

Hi Alice!

The issue mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1867499#c1 should be fixed now with our latest release.

Please let me know if you are still encountering that particular issue!

(In reply to Emil Ghitta, QA [:emilghitta] from comment #15)

Hi Alice!

The issue mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1867499#c1 should be fixed now with our latest release.

Please let me know if you are still encountering that particular issue!

In comment 1 I wrote,
Related issue... or is this a separate bug?
Adding an extra space when linking text to a KB article causes the link to fail. An [[article | text]] link, with a space after the article title, takes you to the "Create a new Knowledge Base article" page. An [[article|text]] without a space takes you to the KB article.
For example, the "content blocking" link in the https://support.mozilla.org/en-US/kb/what-happened-tracking-protection article ... <snip>

That particular issue, described above and in https://github.com/mozilla/sumo/issues/1710 is indeed fixed, since the [[Content blocking | content blocking]] link in the https://support.mozilla.org/en-US/kb/what-happened-tracking-protection article now works (I'll remove that portion from the summary for this bug).

Summary: Capitalization errors in KB article, template and image titles (and extra space after article title in text links) are no longer ignored, causing broken links and missing content → Capitalization errors in KB article, template and image titles are no longer ignored, causing broken links and missing content
Flags: needinfo?(lsiebert)

Capitalization errors in linked article titles still cause this bug - see the Recommended Firefox privacy and security settings for families article, which links to [[Site permissions panel]] under the Permissions section. I have a revision pending, to change the link to [[Site Permissions panel]] and fix the error. Lucas, can you review? See
https://support.mozilla.org/en-US/kb/recommended-firefox-privacy-and-security-settings-families/history

Flags: needinfo?(lsiebert)

(In reply to Alice Wyman from comment #17)

Capitalization errors in linked article titles still cause this bug - see the Recommended Firefox privacy and security settings for families article, which links to [[Site permissions panel]] under the Permissions section. I have a revision pending, to change the link to [[Site Permissions panel]] and fix the error. Lucas, can you review? See
https://support.mozilla.org/en-US/kb/recommended-firefox-privacy-and-security-settings-families/history

Done! Thanks, Alice :)

Flags: needinfo?(lsiebert)
You need to log in before you can comment on or make changes to this bug.