Repository: DDMAL/CantusDB

Issue:
Chant Search Manuscript view - change URL path to match OldCantus
I understand we're trying to keep URLs the same between OldCantus and NewCantus, but there's a difference in the Chant Search Manuscript view. OldCantus uses `/searchms/` (e.g. https://cantus.uwaterloo.ca/searchms/123610?t=est), whereas NewCantus uses `/chant-search-ms/` (e.g. http://206.12.93.196/chant-search-ms/123610?t=est).

This doesn't strike me as a particularly vital difference - I doubt many people will have bookmarked and or cited a Search Manuscript page. But this would be a fairly simple fix, so we may as well make NewCantus work the same as OldCantus in this case.

Bigger picture question: how important is it that all URL paths match between OldCantus and New? @annamorphism, do you have a sense of this?


Discussion:
Unless there's a strong compelling reasons to make things different, always make Old and New Cantus look and behave identically for users.
The general rule of redirects is to do them if:

a) You can store or access all the info you need to redirect them in perpetuity, and
b) You will never publish anything different at the old URL.

You want to prevent bookmarks from not working, but done correctly redirects can help you mend mistakes of the past.

When redirecting permanently, you should always return a `301 Moved Permanently` status code when accessing the old URL. This will redirect browsers transparently, but it will also signal to other clients (e.g., web crawlers) that they should update their caches to the new URL. 

What strikes me about this particular example is that you have:

http://206.12.93.196/source/123610

as the source page, but then

http://206.12.93.196/chant-search-ms/123610?t=est
(or https://cantus.uwaterloo.ca/searchms/123610?t=est -- same thing)

as the search page. No doubt this is because Drupal doesn't do sub-pages of a particular resource. If you're so inclined, and it fits your schedule and priority list, a potentially *better* URL would be:

http://206.12.93.196/sources/123610/chant-search?t=est 

This ties the search page into the overall hierarchy of the resource structure -- it's a chant search for a specific source.

The latter would also be fairly easy to persistently redirect. You could even do it at the nginx layer since the IDs are the same:

`^/chant-search-ms/(\d+)` -> `^/sources/$1/chant-search`  (with some additional provision for query arguments, but those would just be carried over.)

In nginx this might look something like:

```
location ~ ^/searchms/(?P<sourceid>\d+)$ {
    return 301 /sources/$sourceid/chant-search;
}
```

To be tested, of course. 

The nice thing about redirects is that if you do them right, you can roll them out as you need. So if you need to launch now with the old URL, you can always transparently replace it later if you have higher priority things to do. 

The last thing about redirects is that when you're doing a big change like this, is that having a log monitoring system in place that reports the 404 errors is really handy. This can tell you about old URLs that you may be breaking, and give you a chance to fix them before they affect too many users.

> Unless there's a strong compelling reasons to make things different, always make Old and New Cantus look and behave identically for users.

Okay, this is roughly what I expected. I'll make this change once Chant Search is in a better place.

Resolving patch:
diff --git a/django/cantusdb_project/main_app/urls.py b/django/cantusdb_project/main_app/urls.py
--- a/django/cantusdb_project/main_app/urls.py
+++ b/django/cantusdb_project/main_app/urls.py
@@ -319,7 +319,7 @@
     ),
     # misc search
     path(
-        "chant-search-ms/<int:source_pk>",
+        "searchms/<int:source_pk>",
         ChantSearchMSView.as_view(),
         name="chant-search-ms",
     ),


Test patch: