Website Platform Discussion

[Geert Janssens]

On vrijdag 16 juni 2017 19:25:25 CEST Adrien Monteleone wrote:
> Adrien Monteleone
> adrien.monteleone at gmail.com
> 337-593-8208
> 103 Rosalind street
> Lafayette, Louisiana
> 
> > On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:
> > 
> > My (limited) experience is with drupal as well.
> > 
> > Regarding your first question (how to map version management on a cms
> > driven website): usually only the cms code, modules and themes are
> > version managed. The data resides in a database which is not well suited
> > for version management. So code, module and theme updates would be done
> > in much the same way as is done for the current website. One clones the
> > git repository holding all the website code, make changes, create a
> > PR/push upstream. The only additional step would be to run db updates
> > right after this. Perhaps even that could be scripted.
> > The actual content needs something else, just like we need something else
> > for our wiki pages. Both mediawiki (for our wiki pages) and drupal
> > support "page revisions". So just as in the wiki we could follow the
> > history of changes made to each page.
> > 
> > A side effect of the content being in a db rather than in git is it is no
> > longer stored in a distributed way. So it will be important to implement a
> > backup plan for the data.
> > 
> > That goes for the current wiki as well by the way. Do we have a backup in
> > place there ?
> > 
> > For your second question: translations are handled pretty well in drupal.
> > I
> > have played with multilingual websites and from my experience this worked
> > well.
> > 
> > One additional note: dynamic websites frequently need security updates
> > applied. So switching to a cms (any non-static one) would require more
> > maintenance work than we did so far on the website. Someone will have to
> > take this time.
> 
> A staging/dev subdomain works well for this since testing is usually
> necessary to discover likely breakage. It’s very easy to set up. You can
> use Git for pushing updates and then do a clone from the staging site to
> the live site when it is ready. How much work is involved depends on how
> manual the present set up is. If this is a personally hosted site as jralls
> indicates, it might involve some bit of work, but I’m sure most of that can
> be reduced with scripting. (that’s all the big hosts do anyway save they
> add a control panel button for the function)
> 
This is indeed not too hard to set up. We already have a beta setup for the 
current website so this can be reused for this purpose. It lives on a separate 
branch in our gnucash-htdocs repo.

> I’m not sure about Drupal, but Wordpress has built-in auto security updates
> for point releases (which you could turn off if you desire) and you only
> need to intentionally update minor and major versions.

I'm not aware of this in drupal. Anyway this would not work in a git driven 
setup as we currenly have. Changes to the website sources are pushed to the 
gnucash-htdocs repo which has a trigger to update the live website (or beta if 
you prefer) on a remote host. If the updates would be automatic, they would 
happen on the remote host, not in the git repo. Subsequent updates in the git 
repo would probably either result in merge conflicts when the trigger updates 
the live websites or the automatic updates would get discarded.

> 
> I’ve never noticed breakage from security point releases so I generally
> leave those as automatic. All other updates, especially plugin updates,
> should be read over and tested on the staging site first. The more well
> maintained and actively developed plugins frequently (once or more a week
> even) push point releases that include compatibility fixes in addition to
> security fixes. This is why breakage is likely in these areas. (you’d think
> compatibility improvements with the main CMS would decrease breakage, but
> not always depending on work arounds used and the method used to improve
> compatibility)

I think in our process the updates should be applied in the git repo and then 
synchronized to the live site during push of the commits. As happens 
currently.

Pulling in core updates is very easy with git as drupal itself is managed as a 
git repo. So one can simply use the drupal canonical repo as (one) upstream 
for our gnucash-htdocs repo and rebase as we see fit. It's a little bit less 
easy for drupal modules as they are not part of that master drupal repo. 
Perhaps it can be handled via subrepo's, but I have never used that. But even 
manually unzipping a module release in our repo and adding the differences is 
not that hard in the worst case.

Regards,

Geert