Deployment of new website has broken old references
source link: https://gitlab.gnome.org/Teams/documentation/developer-www/-/issues/23
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Deployment of new website has broken old references
Deployment of new website has broken old references
Search engines are still caching old URLs that no longer point to documentation, following the changeover from the old website. It's likely there are old external references to those URLs in places that can't/won't be updated also (such as mailing lists, forum threads, etc.)
I believe there's an opportunity to improve discoverability by re-adding these URLs as redirects to the appropriate article (either one that exists internally, or point to developer-old. in cases where documentation hasn't been ported). As we're publishing on GitLab Pages, a module such as sphinx-redirects might serve useful.
Linked issues
I discussed the broken GTK links in particular in a recent conversation with @ebassi in #gtk. ebassi pointed out that the old and new links follow completely different structures, so the number of nginx rewrite rules would be prohibitive. I suggested redirecting all subpages of - for example - developer.gnome.org/gtk3 to a single page. The single page would then rewrite URLs to the new scheme. There are at least two options for this single page:
- Rewrite developer.gnome.org/gtk3/stable/GtkTextView#gtk-text-view-new to developer.gnome.org/some/path/#GtkTextView. There would be a simple static page that contains JavaScript that reads the fragment identifier ("#GtkTextView") and performs a client-side redirect to the appropriate path, in this case https://docs.gtk.org/gtk3/class.TextView.html. The JavaScript would need to know which links to put "class." in front of and so on. There aren't too many possible links in total (since we're getting rid of the original fragment identifier), so the JavaScript shouldn't be very heavy.
- Rewrite developer.gnome.org/gtk3/stable/GtkTextView#gtk-text-view-new to developer.gnome.org/some/path/GtkTextView#gtk-text-view-new, so that the "item name" (GtkTextView) would be part of the path, not the fragment identifier. There would be a simple webapp that performs a redirect.
Advantage of the static page: simplicity. Advantage of the webapp: links to individual functions work.
I would be very happy to work on whatever people can agree on; I dislike link rot.
Edited by enterprisey 2 days ago- Collapse replies
That sounds like the easiest/most elegant solution to the problem!
"Easiest" wouldn't be my word of choice. In any case, if @enterprisey wants to work on this, I'm fine with it.
I just wouldn't really waste that much effort on it.
The main issue is that, while
GtkTextView.htmlis an easy map toclass.TextView.html(assuming you do know how to maintain the mapping), gtk-doc generated links for other pages and sub-pages that simply have no corresponding URL in the new API reference, eg this sub-section maps to this anchor.As I said on IRC, one of the reasons why we switched to a new documentation generator was to ensure stable links.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK