Our website is hard to change. Consequently, it does change very often, or at least, parts of it don't.
Changing the site means working with one of three things:
- the content
: members can write their own blog posts but the rest of the site is strictly for admins
- the configuration
: only admins can change this - parts of the design (blocks/widgets/sidebars) is done through config
- the design
: only admins can change the theme/template
Working on the theme means setting up a fairly complex development and staging environment. But it's also very difficult to really visualise how theme work will look without having the real content to hand - and that means doing a database export, while carefully avoiding touching the membership/private data.
We need to unravel the technical and organisational issues to make working across the whole site - content and design - much easier for anyone who wants to do it. It still needs good communication and collaboration, but it should have a minimum of setup, complexity and risk.
So here's my suggestion:
Separate out the public-visible website from the membership management system. Keep Drupal running the membership stuff and put it on its own subdomain (e.g. members.pirateparty.org.uk). This can have a very basic theme. A stock theme with the party logo would probably be fine.
Everything else is run as a static website on www.pirateparty.org.uk. Use a static site generator like Jekyll
to build the site. All the design and content is managed as a single GitHub repo that anyone can fork and work on. Static sites are easy to stage: just upload the files to any web server. Or GitHub can even build and host a Jekyll site for you with GitHub Pages
Anyone who wants to make changes commits them to their fork and sends a pull request. The party has a group of committers on the canonical repo who review the changes and merge/deploy them if good. Deployment can be as simple as a git push.GitHub has web-based editing tools
for people who just want to make text changes or write blog posts. The text is in Markdown
files. The proposed changes can then be sent as a pull request.
This setup would mean never having to worry about how changing the main website might affect membership functionality, including the possibility of a data breach. Anyone who wants to work on the site could very quickly setup a dev/staging environment with all the current content.
Properly managed, a system like this could enable much more rapid development and easier collaboration than what we've got at the moment.