search

imagej / imagej.github.io

The ImageJ wiki
https://imagej.net
Other
25 stars 117 forks source link

Ensure old URLs all redirect appropriately #8

Closed ctrueden closed 3 years ago

ctrueden commented 4 years ago

We can keep imagej.net pointed at a LOCI server, and use Proxy/ProxyReverse to forward requests on to GitHub, same as we do with fiji.sc. That way, we can add Apache redirect rules for previous pages that have moved. This will be particularly important for extensions. We may also want to downcase all the links, since needing to put capital letters for things really throws people off (@elevans: is GitHub Pages case sensitive? If so: is there a way to make it case insensitive? Would be much nicer if so.)

frauzufall commented 4 years ago

We also need to handle mediawiki files like Develop.md with this content:

#REDIRECT [[Development]]

I guess we will generate a script catching them and writing Apache redirect rules?

frauzufall commented 4 years ago

URLs like Category:Plugins will need to be converted to /categories/category-plugins.html? Similar question for User:XXX pages - where will they live?

frauzufall commented 4 years ago

I googled if we can have case insensitive URLs and seems like we cannot. Since we redirect everything, should all URLs on this page be lower case and apache converts to lower case?

ctrueden commented 4 years ago

Since we redirect everything, should all URLs on this page be lower case and apache converts to lower case?

I would say yes, definitely, except for one complication: the site imagej.net also serves the ImageJ1 web site, overlaid! So e.g. https://imagej.net/plugins/ (NB: Link may not work at the moment due to SSL config issues, sorry) serves the ImageJ1 plugins page from https://mirror.imagej.net/plugins/, and so forth.

What do you think we should do about that? Simply stop doing that? What I'd love to do ideally is somehow incorporate all the ImageJ1 content into the new site structure, so that e.g. https://imagej.net/plugins/ includes all known content—but it is rather intractable while changes continue to be made to the ImageJ1 content directly.

imagejan commented 3 years ago

Both https://imagej.net/Plugins (linking to wiki content) and https://imagej.net/plugins/ (linking to IJ1 docs) have been used in mailing lists and forum posts. Is the plan to keep both functional (which I hope)?

ctrueden commented 3 years ago

Work completed in uw-loci/loci-servers@32fe6fda4132c1feb0d0052028e276638e202e01 (private repository)

imagejan commented 3 years ago

Note that https://imagej.net/plugins/, which used to show the same page as https://imagej.nih.gov/ij/plugins/index.html, now shows the new Plugins listing, and many links from that list that were used with the imagej.net domain in list and forum posts (e.g. https://imagej.net/plugins/escape.html) are now broken.

@ctrueden do you think there's a way to rescue these old links, or should we alternatively try to have a plugin page on the new wiki for all of the plugins listed in the old list (e.g. compare https://imagej.nih.gov/ij/plugins/cell-counter.html with https://imagej.net/plugins/cell-counter.html)? Or improve the 404 page with some more explanations about the current state?

ctrueden commented 3 years ago

Possible solutions:

  1. Rename the new imagej.net/plugins to imagej.net/extensions. And then imagej.net/plugins can blanket redirect to imagej.nih.gov/ij/plugins.
  2. Add individual redirects for all imagej.net/plugins/<foo>.html pages that currently exist at imagej.nih.gov/ij/plugins.

@imagejan Which sounds better to you?

Edit: I have implemented (2), adding redirects for all plugins linked from https://imagej.nih.gov/ij/plugins/. The only exception is https://imagej.net/plugins/3d-viewer, because there are wiki pages at there, which are IMHO better than what's available from https://imagej.nih.gov/ij/3d-viewer/

should we alternatively try to have a plugin page on the new wiki for all of the plugins listed in the old list

That was my original idea... but I'm about ready to give up on trying to integrate anything ImageJ1 into imagej.net at this point.

imagejan commented 3 years ago

Depending on how many changes we expect to be made to the old https://imagej.nih.gov/ij/plugins/ still, option (2) is more prone to getting out of sync with ImageJ1-related changes, that's why I would have opted for option (1). On the other hand, we might really not want to encourage people to link to the old plugin list. Google searches still show up quite some links from that list though...

I don't know what's better really.

ctrueden commented 3 years ago

I think it's fine for them to get out of sync. The redirects I put in place will continue supporting the old links. And we should stop posting imagej.net/plugins/some-imagej1-plugin.html links henceforth. My dream was that some day, all those pages could migrate to imagej.net as nicer or updated documentation. But it's clear to me now that ImageJ1-land won't be reconciled with ImageJ2 and Fiji. Simpler to just keep ImageJ1 on imagej.nih.gov, and stop bending over backwards to try to enhance it. Doing so is just prolonging its popularity while de-incentivizing making progress on ImageJ2 and SciJava.