Choose software platform for contentmine.org

[ghost]

@tarrow mentioned a plan to use WordPress for contentmine.org . I see at least four drawbacks to that choice:

1. WordPress requires a web host that provides PHP scripting and a MySQL database, which reduces the number of potential web hosts, and reduces the ease of defending against (D)DoS attacks.
2. WordPress has a somewhat poor security record, including the occasional 0-day. This imposes at the very least a maintenance overhead for the site (either manually update the WordPress installation when new versions are released, or enable automatic updates and periodically check that they have worked), with no guarantees of actually keeping out miscreants (due to the nature of 0-days).
3. Last time I checked, the WordPress admin interface required the user to enable JavaScript in the browser. Couple that with point 2, and WordPress would put contentmine.org's contributors at increased risk, because of the increased attack surface that is provided by enabling JavaScript in the browser. Contentmine.org contributors should not, where possible, have to choose between (a) contributing, or (b) staying safe online.
4. Contentmine.org is not currently protected by HTTPS. With a static site, that matters less, as the administrator authenticates to the web host via a protocol other than HTTP, e.g. SSH. With a WordPress site, the lack of HTTPS is a cause for concern, as the administrator (and any other contributors, or people posting comments) would authenticate to the site via plain HTTP. This exposes them to Firesheep-style attacks.

My alternative proposal would be for Contentmine.org to use a static site generator. There are many available. Jekyll would probably be a good choice. It is:

• Already used by ContentMine for contentmine.github.io;
• supported by GitHub Pages, GitLab Pages (in case CM moves to GitLab for repository hosting), and of course by absolutely any ordinary web host;
• well-documented;
• free software;
• widely-used;
• small, fast, and straightforward.

[ghost]

@markmacgillivray wrote:

wordpress is a bad choice [...]. By the way, the contentmine project already did have wordpress, already did move away from it for these reasons ...

Thanks, useful to know!

[tarrow]

Yep, we did previously have a wordpress website and did move away from it for a variety of reasons.

I personally have a preference for a static site generated by something like Jekyll (I made contentmine.github.io) but the problem with it is simply that it needs to be maintained by non-technical people (i.e. people who basically want WYSIWYG and don't have a github account). I haven't yet seen a good solution to this problem.

If the site can only have content updated by the (few) technical members of the team then it isn't very frequently maintained. Not only the content but also the layout is often wanted to be changed by non-technical people.

So far I've found that maintaining the website and debates about layout, content etc.. are a huge distraction to the team so the solution we're currently working with is to hire (at very minimal cost) an external engineer to implement a Wordpress theme with a layout that all (or a consensus of the) members of the team are happy with. We'll then host this with a provider that specialises in Wordpress hosting (like wordpress.com but no decision has yet been made).

The engineer has actually already started work and I'm hoping that we'll see the results soon (although we had hoped that this process would be much quicker: it started in Feb :( )

Content can then be produced, maintained and edited by anyone. Hopefully this will reduce the burden of the website on all the members of the team and we can focus on actually ContentMining for people :).

I can see that there are disadvantages to this solution but I don't currently see a better alternative. I'd be happy to hear from either @markmacgillivray or @sampablokuper (or anyone else) if you have any ideas that takes all of these concerns into account.

[markmacgillivray]

@tarrow I agree that the simple solution for non-tech members is a wordpress blog hosted on wordpress.org. This leaves the complexity and security issues to wordpress, and has very little cost to the CM team, and no technical overhead. it does not meet all the concerns of ultra-security, but I think also does not warrant a high enough risk profile to warrant such concerns.

Given that CM has gone around many multiple times on site designs, layouts, technologies, etc, I'd say just go with a simple wordpress.org hosted blog and don't even bother with a custom theme / layout. Particularly if this is now delaying things further since February, it is a piece of work that I'd expect to do in no more than a day. Perhaps just pick a simple plain standard theme that allows you to customise the colours to the CM colours.

In fact, I think that such a wordpress.org blog was already set up in exactly this way in the past... the current blog still looks very much like this is exactly what it is, and it looks perfectly functional to me:

https://contentmining.wordpress.com/

[markmacgillivray]

@tarrow I also personally agree that a static site is a better approach, and I don't even think that using them - especially in combination with markdown - is actually any harder than using a wysiwyg editor, particularly when considering that most non-tech users will never use most of the more complex layout features of the wysiwyg editor anyway. However, people do not like change, so... wordpress is the lowest common denominator.

[ghost]

@tarrow wrote

the solution we're currently working with is to hire (at very minimal cost) an external engineer to implement a Wordpress theme with a layout that all (or a consensus of the) members of the team are happy with. We'll then host this with a provider that specialises in Wordpress hosting (like wordpress.com but no decision has yet been made).

The engineer has actually already started work and I'm hoping that we'll see the results soon (although we had hoped that this process would be much quicker: it started in Feb :( )

Understood, and fair enough. In that case, I'm going to close this thread as wontfix. (That's just to stop it showing up as an open bug, not to prevent people continuing the discussion.) If for any reason the WordPress solution currently in development falls through or needs to be replaced in the future, this thread should be reopened.

Just to address other comments raised...

I personally have a preference for a static site generated by something like Jekyll (I made contentmine.github.io) but the problem with it is simply that it needs to be maintained by non-technical people (i.e. people who basically want WYSIWYG and don't have a github account). I haven't yet seen a good solution to this problem. [...] I'd be happy to hear from either @markmacgillivray or @sampablokuper (or anyone else) if you have any ideas that takes all of these concerns into account.

Squaring that specific circle (i.e. achieving an SSGen that is acceptably easy to use for people unfamiliar with Git/etc) has been one of the primary quests of web developers over the last 2-3 years. A number of efforts exist. Unfortunately, I have not yet tried any of them, so cannot personally offer feedback on how well they work. Some examples:

• https://www.getlektor.com/
• https://wordpress.org/plugins/static-html-output-plugin/
• http://carrot.is/coding/static_cms
• https://headlesscms.org/
• https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/

If anyone reading this thread feels like testing these out in their spare time and feeding back, that would be great :)

@markmacgillivray wrote:

I also personally agree that a static site is a better approach, and I don't even think that using them - especially in combination with markdown - is actually any harder than using a wysiwyg editor, particularly when considering that most non-tech users will never use most of the more complex layout features of the wysiwyg editor anyway.

I broadly agree. IME the biggest snags novices seem to encounter are unfamiliarity with:

• editing plain text, i.e. understanding how it differs from rich text and that specialised text editors are a boon;
• version control systems;
• file transfer mechanisms used by web hosts, e.g. SFTP, Git, SSH, etc.

However, people do not like change, so... wordpress is the lowest common denominator.

Indeed :/

@markmacgillivray wrote:

I agree that the simple solution for non-tech members is a wordpress blog hosted on wordpress.org.

I'm assuming you mean wordpress.com :)

This leaves the complexity and security issues to wordpress, and has very little cost to the CM team, and no technical overhead. it does not meet all the concerns of ultra-security, but I think also does not warrant a high enough risk profile to warrant such concerns.

Given that CM has gone around many multiple times on site designs, layouts, technologies, etc, I'd say just go with a simple wordpress.org hosted blog and don't even bother with a custom theme / layout. Particularly if this is now delaying things further since February, it is a piece of work that I'd expect to do in no more than a day. Perhaps just pick a simple plain standard theme that allows you to customise the colours to the CM colours.

In fact, I think that such a wordpress.org blog was already set up in exactly this way in the past... the current blog still looks very much like this is exactly what it is, and it looks perfectly functional to me:

https://contentmining.wordpress.com/

I almost entirely agree :) Certainly, wordpress.com, being run by Automattic, ought to be among the best managed WordPress hosts, and is far from a bad choice. I'll just note that they aren't the only option for managed WordPress hosting, and some of the other companies offering that service are carbon-neutral and/or in more security/privacy-friendly jurisdictions than wordpress.com . I have updated this comment to mention two such companies.