Deleting a wikipage should not really delete it

Bug #1735435 reported by kaputtnik
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Widelands Website
Won't Fix
Undecided
Unassigned

Bug Description

Instead a wikipage should be emptied and filled with some text like: "No content anymore".

There should also be some filtering to prevent showing it in the List of Wikiarticles or the search. Accessing per address (e.g. in browsers address bar) should be possible though.

Any other ideas?

Consider to use the django redirect app for this: https://docs.djangoproject.com/en/1.11/ref/contrib/redirects/

Related branches

Revision history for this message
GunChleoc (gunchleoc) wrote :

Maybe this: https://en.wikipedia.org/wiki/HTTP_301 and link to the wiki's main page, or a user specified page instead if one is given?

Revision history for this message
kaputtnik (franku) wrote :

HTTP 301 is fine. But linking to the wiki's main page isn't that good imho, because HTTP 301 is used for redirects. From my understanding a HTTP 301 should be returned if the address has changed, say an Article 'TranslationDutch' is moved to 'TranslDutch', but the content of the article is still valid and should be crawled. In this case this would be wrong, because we don't want the content to be crawled. But i do not understand much of this ;)

I think the right approach would be:

1. Add a DB row for model ARTICLE which defines a state of an article. A state would be something like 'up_to_date', 'needs_update', 'deleted', 'in_progress'

2. Deleted pages get two urls: wiki/trash/TranslationDutch (original content) and /wiki/TranslationDutch (contain a sentence that this article has been deleted and a link to wiki/trash/TranslationDutch)

3. Modify robots.txt to inform crawlers not to crawl wiki/trash/*

4. Modify the sitemap to not contain articles from wiki/trash

This way we could also easily remove articles in trash from the 'List of all pages' or create additional lists depending on the state of an article, e.g. show a list of articles that where outdatet and needs work.

I am not sure about point 2... always struggling with the urls :-D

Revision history for this message
GunChleoc (gunchleoc) wrote :

The best would be an HTTP header PERMANENTLY_DELETED, but I couldn't find one. So, your approach should do it.

Revision history for this message
kaputtnik (franku) wrote :

I guess HTTP 410 ('Gone') is something you are looking for.

Cool uris don't change (https://www.w3.org/Provider/Style/URI) is the rule why, in our case, a wikiarticle shoudn't be deleted. Personally i can't follow this rule under all circumstances. If we decide to delete an Wiki article we do it on purpose. The links from other sites or from crawlers to that article doesn't work then anymore, thats true. But linking to a page with no, or unrelated content isn't useful either.

Anyway, the server error is coming from my bad code design when i have implemented the backlinks page. This has to be fixed regardless of allowing or disallowing deleting of an wiki article.

Revision history for this message
GunChleoc (gunchleoc) wrote :

Yes, I know that cool URIs don't change, but there is no on-site content ta is equivalent for those particular pages. We could redirect them all to https://wl.widelands.org/wiki/TranslatingWidelands/#the-transifex-glossary though.

Revision history for this message
kaputtnik (franku) wrote :

Does Google treat 404 and 410 status codes differently? https://www.youtube.com/watch?v=xp5Nf8ANfOw

As far i understand deleting a wiki article could serve a 410. So if we have a tag 'deleted' like mentioned in #2 we can serve a 410. The article will still remain with all the content though.

> We could redirect them all to https://wl.widelands.org/wiki/TranslatingWidelands/#the-transifex-glossary though.

I am not sure what you mean here. Automatical redirecting isn't possible (atm). The only automatic redirects we have applies when an article get renamed. But i think its worth to implement an automatic redirect mechanism, also to an anchor of another page.

Revision history for this message
GunChleoc (gunchleoc) wrote :

410 is exactly what I was looking for :)

So, we could have 2 options that both would need implementing:

410 for pages that don't have any viable replacement

301 for pages that should be visited instead, allowing an anchor for the redirection.

kaputtnik (franku)
description: updated
Revision history for this message
GunChleoc (gunchleoc) wrote :
Changed in widelands-website:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.