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.

• It looks more than a bit dated.
• It's wholly dynamic, which makes hosting more difficult. Any sort of HTTP caching is disabled. In any non-trivial traffic situation, the hosting struggles a lot.
• The underlying CMS, Xaraya, has been unmaintained for over a decade.
• The version of Xaraya used, 1.2.3, is based on PHP 5.6. This, the last of the 5 series, will go out of security maintenance at the end of 2018. We have determined that some changes will be definitely required for PHP 7. How many is unknowable, but the changes we do know about start with needing to change the MySQL interface.
• The content is nearly all held in the MySQL database. Which in turn means it's not easy to know what content is present.

None of the above should be interpreted as a criticism of the original decisions. It's more how things have panned out over time. And the current system does have some important features.

• The membership system. ALl handling of membership, including subscription reminders, payments etc. is done via a custom Xaraya module.
• There is a custom module for book reviews.
• Requiring a website login means that online access to the journals can be restricted.

The above problems has been clear for some time, but it has proved difficult to move forward. The problem, it seems to me, is that the problem has been considered in terms of a replacement of the current site, and a replacement is a non-trivial job. It's difficult to see how it can be approached incrementally.

This is amplified by the all-volunteer nature of ACCU. Without engaging in a serious procurement exercise, we need to be able to utilise members' skills, and these do not, typically, include website design and a thirst for working on old PHP systems.

It seems to me that the way to make progress on this is to outline a process that allows incremental progress. What I have in mind is as follows:

1. Make the current site available at members.accu.org and oldsite.accu.org as well as accu.org.
2. Build a new site at newsite.accu.org. This can have links to the existing site by linking to locations under oldsite.accu.org for website items and members.accu.org for ACCU membership management. In the first instance this new site can just be a new front page.
3. Once the new site is ready for deployment, move it to accu.org.
4. Look at replacing the membership management system with a COTS offering. The current system requires interfacing with credit card handlers and is limited in its facilties. This might be a good opportunity to move to something more flexible. We would need to be able to access some sort of member logon to enable us to provide member-only website content.
5. Over time, migrate content from oldsite.accu.org to the new site.

The next question is what sort of underlying technology to use to implement the new website. I think it should be static, as far as possible, to keep hosting as efficient and simple as possible.

For entirely static content, the ACCU Conference website uses a static website generator and source files in AsciiDoc, maintained in a Github repository. This model seems eminently sensible to me for the following reasons:

• In the main, website content can be added using a knowledge of text markup. One can bikeshed indefinitely on markup formats; AsciiDoc has the benefit of providing a comprehensive range of document markup, being originally intended to produce DocBook, and a single standard.
• Content can be added to the website by means of a pull request to the website editors. This is a workflow with which the vast majority of ACCU members will be very familiar.
• Selection of a popular static site generator will give access to a wide range of pre-designed templates - and hopefully designers familiar with generating those templates.
• Content is saved in a format reflective of the website URLs. The totality of the website content is therefore easy to discern.
• Content is also easy to extract. To move instead to a currently popular CMS such as WordPress seems to me to mean that content will have to be extracted from an opaque database only to be reinserted into another opaque database.

It's not the system currently used for the conference website, but there is some agreement that Hugo would be a good choice.

I do not at the moment have a clear vision of how to handle website sections that require some sort of authentication.

I intend to implement a proof of concept site using the scheme described in the first two steps above.

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.

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?

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.

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.