Welcome to the Community

Please choose one of the options below to log in and get stuck in!

Login with PPUK

Improving our website: agile, static site, continuous deployment

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.

Comments

  • edited June 2016
    If anyone wants to play around with this as a working system, have a look at the code on GitHub and the staging site.

    Don't get hung up on the (broken, incomplete) design and content. That's not the point at this stage. Fork it, tweak it, stage it yourself, send me pull requests.
  • ThyPirateDaveThyPirateDave South Wales
    One of the reasons the main site is tied into the membership system is we put things to a membership vote quite often on the main site. This means the vote is only visible to accounts that are marked as "members" and varying permission levels provide varying oversight on elections. Election monitor, nomination officer, etc...

    If we separate membership from site, how would we achieve this?

    We currently vote in:

    NEC/Gov elections
    Policy crowd-sourcing
    Random polls on membership
  • We could just link to the relevant pages on the members' site.
  • Personally, I don't think the issues with the current platform a severe enough to warrant a rewrite.

    Yes, writing themes without a simple staging process is not straightforward, but given there hasn't been any plan for a reskin of the website (that I'm aware of), it's not something that urgently needs fixing. We are currently simplifying how the platform is configured on both the front end and the back to make it easier to use and work with, and I don't really see how having another service that's maintained completely differently alongside the services we're currently running is going to help us out.

    We've been using Trello with some success to plan work to maintain the current site and IT infrastructure, and it's demonstrated to be a good way to collaborate.
  • ThyPirateDaveThyPirateDave South Wales
    @adrianshort I worry about having to maintain two separate sites this way.

    I'd love a theme change but there are so many things that need doing atm that I am concerned about the amount of manhours and volunteers a rewrite would need. We'd also need a lot of discussion over what the new site would be written in etc.
  • The site needs more than a new theme. It needs rethinking from scratch, with the design and content considered holistically.

    The prototype in the OP is build with Jekyll, a static site generator in Ruby. You don't need to know Ruby to use it. While any static site generator would give the main benefits of managing the design and content in one place, Jekyll has the extra advantage of being native to GitHub Pages, so it's easy to stage.
  • But you still have to learn Markdown syntax, right?

    There's a reason WYSIWYG editors are so popular on CMS platforms, because it creates a very low barrier of entry for people who want to just create an article with some basic styled text, a couple of pictures, and a video link, for instance.

    Honestly, I think main problem we have with Drupal right now isn't really the tool itself, it's the way we've used it. I don't think this is a problem that needs us to migrate stack to fix, and running it in conjunction with the existing platform to retain membership stuff is going to increase the complexity of our backend when we're currently trying to simplify it, and adds yet another thing that requires maintenance.
  • Did this ever take off

    I'm not fussed about what platform the Web interface is on, but for the community would an atlassian/jira interface not be better to track idea's/policy and pull things together. I am new to the party so I'm probably talking out my arse and not meaning to tread on any toes, but there doesn't seem to be much activity/engagement in the current community setup.
    So perhaps a facelift/migration should be looked at?
  • We're still trying to get our existing infrastructure in order before we embark on any kind of facelift.
  • In the mean time @Lennon and I have been reducing a lot of the noise on the site and replacing a lot of wall-o-text stuff with images. It's a bit like fitting bicycle wheels onto a juggernaut at times but it looks a damn sight better than it did... there is also some stuff in the pipeline to better include discord (embedding it into the forum for example).
  • Just a side note from a non Website type person. There is still the IRC tab at the top of the community site that you might want to swap to a discord one perhaps?
  • Yeah that's what I was referring to above. We're going to be embedding Discord instead of IRC. I put it on ITs eternal to-do list myself :)
Sign In or Register to comment.