404 page should only list accessible articles

VERIFIED FIXED in 1.3

Status

support.mozilla.org
General
VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: krupa, Assigned: paulc)

Tracking

unspecified
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: tiki_fixed, URL)

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Steps to reproduce:
1.go to http://support-stage.mozilla.org/en-US/kb/Clearing+Private+Datab
2.Notice the list under Perhaps you were looking for: category

observed behavior:
The first few links have "*" before them whereas the rest are simply listed.(see screenshot
(Reporter)

Comment 1

9 years ago
Created attachment 371602 [details]
listing
(Reporter)

Updated

9 years ago
Summary: Formatting of listing under "Perhaps you were looking for: "category is not consistent → Formatting of list under "Perhaps you were looking for: "category is not consistent
(Assignee)

Updated

9 years ago
Assignee: nobody → paul.craciunoiu
Renaming to "404 page should only list accessible articles".

"*Clearing Location bar history" and "Clearing Location bar history" are two separate articles. The asterisk is part of the article name, which indicates that is the staging copy.
See <http://support.mozilla.com/kb/Approving+articles+and+edits>.

One thing that is alarming about that page is that staging copies are listed even when not logged in. It should list articles that accessible to the viewer. So to a person not logged in, it should not list articles in the staging area, sandbox, or archive categories. Similar to what we do with the language selector.
Summary: Formatting of list under "Perhaps you were looking for: "category is not consistent → 404 page should only list accessible articles
(Assignee)

Comment 3

9 years ago
I think it would be good to also try and list staging + live articles on the same line wherever possible.
E.g. list "Clearing Location bar history" as
"Clearing Location bar history (approved) (staging)" or something of the sort. I suppose that could be a separate bug.
(Assignee)

Comment 4

9 years ago
r24284 / r24285
For some reason, the wikilib function checked the permission on the current page over and over, instead of the suggested pages.

This seems to be a bug in TikiWiki. Sylvie, what do you think?
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Assignee)

Updated

9 years ago
OS: Windows XP → All
Hardware: x86 → All
Target Milestone: --- → 1.0.2

Comment 5

9 years ago
Thanks - committed in tw
(Reporter)

Comment 6

9 years ago
I still see staging article listed in the 404 page.Check-

http://support-stage.mozilla.org/en-US/kb/How+To+Make+Firefox+The+Default+Browsern


screenshot: http://screencast.com/t/hNVE3usq

So reopening...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 7

9 years ago
Krupa: it appears that those staging articles are accessible wihout being logged in. As such, they're listed.

Do we want to remove staging articles from this list even if they are accessible to anonymous users?
(Assignee)

Comment 8

9 years ago
Laura, David, Chris, please see comment 7.
It looks as though those articles are staging copies, but not in the staging area category.
(Assignee)

Comment 10

9 years ago
Chris, this sounds like it can be done manually. Or shall we consider a bug for moving all staging copies to the staging area?

I'm not sure if we implemented that articles shouldn't start with a "*", but they shouldn't.
They should be in the staging area in the first place, so I'd like to investigate that before moving them.

Updated

9 years ago
Target Milestone: 1.0.2 → Future

Updated

9 years ago
Depends on: 489839

Updated

9 years ago
No longer depends on: 489839

Updated

9 years ago
Depends on: 489839

Updated

9 years ago
Depends on: 489874
(Assignee)

Updated

9 years ago
Depends on: 489210
(Assignee)

Comment 13

9 years ago
Looks like this doesn't happen anymore. Probably a result of bug 489874 being fixed. Chris, can you confirm?
confirmed
I also tried http://support-stage.mozilla.org/en-US/kb/Cannot+log+in+to+websitess but could not find a link to an article in the staging area.

We obviously can't check every possible 404 page though.
(Assignee)

Comment 15

9 years ago
Yay! If this occurs again, please reopen :)
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 16

9 years ago
Paul,
I need a little clarification-
IF I navigate to the 404 page(http://support-stage.mozilla.org/en-US/kb/How+To+Make+Firefox+The+Default+Browsern)..I noticed that the below specified link is listed twice.The second link in this page has no content.


*Firefox не может соединиться по безопасному протоколу, потому что сайт использует старую � (http://tinyurl.com/lzwm7q)

is this the expected behavior? reopening for clarification...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 17

9 years ago
Ugh. That article title seems pretty buggy. Additionally, the two URLs are different (notice below). I would guess it is not the same article. But there also seem to be some encoding issues here, not a part of this bug. Both of those are articles that are not in the staging area though (if you look at the breadcrumb). They are articles that should be assigned a category, though. I hope that clarifies it.

http://support-stage.mozilla.org/en-US/kb/%2AFirefox+%D0%BD%D0%B5+%D0%BC%D0%BE%D0%B6%D0%B5%D1%82+%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B8%D1%82%D1%8C%D1%81%D1%8F+%D0%BF%D0%BE+%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D0%BC%D1%83+%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%83%2C+%D0%BF%D0%BE%D1%82%D0%BE%D0%BC%D1%83+%D1%87%D1%82%D0%BE+%D1%81%D0%B0%D0%B9%D1%82+%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D1%82+%D1%81%D1%82%D0%B0%D1%80%D1%83%D1%8E+%D0
http://support-stage.mozilla.org/en-US/kb/%2AFirefox+%D0%BD%D0%B5+%D0%BC%D0%BE%D0%B6%D0%B5%D1%82+%D1%81%D0%BE%D0%B5%D0%B4%D0%B8%D0%BD%D0%B8%D1%82%D1%8C%D1%81%D1%8F+%D0%BF%D0%BE+%D0%B1%D0%B5%D0%B7%D0%BE%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D0%BC%D1%83+%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D1%83%2C+%D0%BF%D0%BE%D1%82%D0%BE%D0%BC%D1%83+%D1%87%D1%82%D0%BE+%D1%81%D0%B0%D0%B9%D1%82+%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D0%B5%D1%82+%D1%81%D1%82%D0%B0%D1%80%D1%83%D1%8E+%EF
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 18

9 years ago
looks fixed.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 19

9 years ago
Let's claim it happened in 1.3 to keep track of it :)
Target Milestone: Future → 1.3
Whiteboard: tiki_bug
Change already made in tiki.
Whiteboard: tiki_bug → tiki_fixed
You need to log in before you can comment on or make changes to this bug.