Website Platform Discussion

Geert Janssens geert.gnucash at kobaltwit.be
Thu Jun 22 12:55:33 EDT 2017


On donderdag 22 juni 2017 18:05:40 CEST Derek Atkins wrote:
> Hi,
> 
> Sorry for the delay in responding; I was on vacation..
> 
> "David T." <sunfish62 at yahoo.com> writes:
> > Derek,
> 
> [snip]
> 
> > I will note that one of the problems I see with the website/wiki
> > presence is precisely its static nature. Pages and information seem to
> > get on the sites and never change or get updated.
> 
> I don't think that changing the website storage system would change
> this.  Getting the website changed is a simple "git pull request", and
> even if the underlying site changed to something else, I don't see this
> process changing.  What that says to me is that changing to a CMS wont
> make it any easier to change the content.
> 
I disagree.

A CMS based website has several parts, to simplify:
- the CMS code with optional modules (drupal/mediawiki/...)
- the theme
- the content

The first two would be managed in git, the latter would be managed by a 
webinterface (and stored partly in a db/partly in a data directory on the 
server).

So the initial work of getting the website up and running technically and 
getting the theme right will require git interaction.

However altering content would not. From the mere reactions to this thread it 
looks like several people would definitely volunteer to help out maintaining 
the content. However I think that will only work if the content is not managed 
in a developer-centric mindset (aka via git). I would love to see those 
volunteers in come in action. If separating content management from code and 
theme management would support this, I really think we should consider it.

> >        A number of the wiki
> > 
> > pages I was just looking at had references to “new” features for v1.8,
> > along with links to discussions in the mailing lists ca. 2002. There
> > were references to resources that have long ago disappeared off the
> > Internet, as well as discussions about issues that are no longer
> > relevant to GnuCash in 2017—like discussions about code to create SQL
> > data from an XML data file, which while perhaps still interesting, are
> > nonetheless rendered rather moot with the incorporation of the SQL
> > back end in 2.4.
> 
> Again, I dont see how changing the underlying infrastructure would help
> here.
> 
> To me, the issue is a lack of "maintainers".  We would need people who
> are responsible for the website and wiki content, monitor it, edit it,
> ensure that it remains current and up to date.
> 
And I argue this lack of "maintainers" is in part because of the way we manage 
our main site.

Note a recent thread on obsolete pages in the wiki immediately resulted in 
several people willing to go over the wiki and refresh it. The wiki has no 
"commit through git" management wrapped around it.

> I agree that the wiki is probably easier for the majority of users
> because it doesn't use git.  But I'm perfect happy adding more people to
> the "website" commiter ACL, giving more people the ability to push
> updates to the website directly.

I continue to argue allowing more people to use git is not going to bring us 
more people willing to keep the content up to date simply because git itself 
is a pretty effective deterrent for non-developers (who would otherwise be 
perfectly capable of writing good website content).

> 
> > As for the ongoing maintenance of a cms, I agree that it can be a
> > pain. However, at least with Drupal, I find the process pretty quick
> > to manage (in fact, I just installed an update today), and assuming
> > that the GnuCash site would continue to be a basic site, it would
> > likely not require many additional modules—thus keeping the update
> > routines simpler. Moreover, with a bundled cms, you have web
> > developers who are maintaining awareness of security issues and
> > pushing out fixes for them. In this day of increased threat vectors
> > online, can we be sure that the GnuCash site is immune to these new
> > threats?
> 
> Considering right now www.gnucash.org is a quazi static website that
> uses PHP for NEWS and Localization, I'm pretty sure it's immune.  The
> attack surface of the current www.gnucash.org site is fairly small.  I
> feel there's more of an attack vector against code/wiki.gnucash.org
> specifically because it's running more complicated software (namely
> mediawiki).

Yes, CMS systems are a complex body of code and hence have a bigger potential 
for security issues. At the same time they are constantly monitored  by a 
larger number of people as well.

The suggestion was made that drupal could be configured to behave similarly to 
a wiki (while other parts of the same website are still typical CMS pages). 
That is a very tempting idea to me. It would reduce that attack surface again 
to one CMS as it could then replace mediawiki, it would be very nice to theme 
the wiki and more static pages using the same theming engine,...

Of course it would still remain a complex piece of code requiring frequent 
security updates, which someone will need to perform. And this person will 
have to be willing to use git for it.
> 
> > Whether a new platform would encourage the community to maintain a
> > vibrant web presence or not is of course debatable. but I think it’s a
> > fair one to have.
> 
> Fair enough, but I would maintain that changing to a new platform that
> still gates through GIT would, in essence, not change the community
> willing to maintain a vibrant web presence.  At least I suspect it's
> "git" that's the barrier to entry and not the fact that it's a raw
> PHP-based website vs Drupal/et al.

Totally agreed, except I believe pulling the content from git will make a 
difference.

> 
> In short -- I don't see how adding (or changing to) Drupal would
> increase the number of people willing and able to keep the website
> content up to date.

IMO it would because the content itself would no longer be git managed.

Geert



More information about the gnucash-devel mailing list