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.