Differences

This shows you the differences between two versions of the page.

--- hosting:newwebsiteplan [2018/08/21 15:52] – jim
+++ hosting:newwebsiteplan [2023/03/13 15:14] (current) – jim
@@ Line 1: / Line 1: @@
 ====== Thoughts on a plan for a new website ======
+(This page is the original notes for what turned eventually into the current main website. It is now of historic interested only. I will note that a COTS membership system turned out to be rather more of a challenge than anticipated, and at the time of writing - March 2023 - an unsolved problem.)
 First, let's quickly summarise some problems with the current website.
@@ Line 50: / Line 52: @@
 I intend to implement a proof of concept site using the scheme described in the first two steps above.
+===== Progress 31/8/2018 =====
+I've implemented a proof of concept site at [[https://newsite.accu.org]]. It's built using Hugo. Click on Local Groups/ACCU London to see a link to the existing site in action.
+For the moment the source code in at https://git.accu.org/jim/Hugo-site. You'll probably need a login for this; ask me (Jim). I will move it to the ACCU GitHub account soon.
+I've used the Hugo theme 'Universal' and not changed any of the graphics, apart from adding some existing ACCU graphics where appropriate.
+I've also distinguished further (mostly in my head at the moment) the different ways of linking to the old site.
+* ''members.accu.org'' - a transition location for site members-only content.
+* ''membership.accu.org'' - membership maintenance and signup.
+* ''oldsite.accu.org'' - a transition location for site general content.
+What's there has taken me about a day. I'm finding AsciiDoc a very convenient and quick way to add content.
+==== Members-only content ====
+I said above I've not been sure how to handle members-only content.
+As far as I'm aware, with the exception of site editor and special users like membership secretary and book review manager, the site manages access distinguishing between everybody and ACCU members only.
+For members-only content, there has to be some sort of dynamic session management and access control.
+My current bright idea (ha!) is as follows:
+  * Have members-only content under ''/members''.
+    * The content there to be generated by Hugo like everything else.
+    * Content to be held in a ''git'' subrepo, hosted on ''git.accu.org''. We obviously can't put it on GitHub or it would immediately become public.
+    * Apache routes anything under ''/members'' to the dynamic engine.
+    * The dynamic engine would then manage user login and, if logged in, serve the statically generated content. This keeps the dynamic engine complexity and required functionality to a minimum.
+  * This assumes only member/non-member granularity is required. Is this so?
+==== Preserving URLs ====
+URLs on the existing site are generally of the form ''/index.php/area/page''. Obviously it would be desirable in the main to preserve URLs for those who have stored them. Hugo generates URLs following
+the file structure under its source ''content'' directory, so a structure with ''/area/page'' would be logical and possible. An Apache rewrite rule to redirect URLs starting ''/index.php'' to the plain page URL would be fairly straightforward.
+===== However =====
+Since writing the above, I have looked closer at some of the URL structures. There's a lot - all journal articles, for example - which are of the form ''/index.php/journal/12345''. The latter number is simply the number of the article in the Xaraya database table. A similar form applies to book reviews.
+I don't think these are sustainable. I propose instead to move to a more rational arrangement, ''/journals/CVu/<issue number>/<authorname>''. Existing content will be extracted from the database by a small bit of Python, which will also generate a ''journals/12345'' stub containing an HTML redirection to the new path. Going forward, manual addition of new articles is obvious.
+For journals this will require modifications to the index generation process. But since the index is generated by a program at the moment, I think this is doable.
+There's a related concern with book reviews. A bit more thought is required on the URL form, but again the idea of generating a redirection file for existing reviews should work.