Website Platform Discussion

Fri Jun 16 13:25:25 EDT 2017

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)

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’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)

That may sound rough but in practice it really is simple and easy.

-Adrien
> 
> However all things considered, this is yet another project I had queued for 
> "when I will have some spare time", which I never seem to have any more. So 
> I'm quite pleased there are several people already willing to help out on 
> this!
> 
> Regards,
> 
> Geert
> 
> On vrijdag 16 juni 2017 03:55:59 CEST Adrien Monteleone wrote:
>> I’ve used Drupal in the past but haven’t touched it in any meaningful way
>> for about 5 years. From what I understand, it has been abstracted from a
>> CMS to a framework for building a CMS.
>> 
>> I presently develop Wordpress sites. Not sure what the present host offers,
>> but some like SiteGround offer staging tools using sub-domains or
>> sub-folders. (that can all be set up manually of course, but some offer it
>> in a few clicks) You can use Git for edits and updates. But that’s really
>> only necessary for the site structure itself like themes, plugins, etc.
>> 
>> Actual content can easily be saved as drafts that can then be later approved
>> and published.
>> 
>> There are plenty of options for user roles with editing and publishing
>> rights.
>> 
>> I haven’t looked, but I would be surprised to not find translation plugins.
>> 
>> You could also integrate a web store really easy using the Woocommerce
>> plugin for donations, developer support, swag, etc.
>> 
>> There are also calendar and project management plugins. Not sure if ya’ll
>> are using any online project management tools yet, but that’s a definite
>> option.
>> 
>> I’d be happy to assist with the build if needed.
>> 
>> -Adrien
>> 
>>> On Jun 15, 2017, at 2:05 PM, Eric Theise <erictheise at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> My trajectory with site-building is somewhat similar to David's except
>>> that
>>> I ended up building less sites through CMSs and more using frameworks such
>>> as Rails, Django, and Express. But lately I've taken a few steps back and
>>> I've found Jekyll to be an excellent way to get the job done. I'll
>>> advocate
>>> for it here because of its tight integration with GitHub. Updating a site
>>> is a git push, and content updates can go through the same evaluation as
>>> any other pull request.
>>> 
>>> Perhaps not immediately obvious is Jekyll's use of yaml objects to
>>> replace/simulate database reads and I've found this incredibly useful in
>>> situations where updates are infrequent.
>>> 
>>> http://jekyllrb.com/
>>> 
>>> Eric
>>> 
>>> 
>>> On Thu, Jun 15, 2017 at 10:57 AM, David T. via gnucash-devel <
>>> 
>>> gnucash-devel at gnucash.org> wrote:
>>>> In Bug 783240, I made some suggestions about modifying the website
>>>> structure to improve the new user experience. As the discussion has
>>>> developed, the implications of some of the suggestions have become more
>>>> substantial, and John Ralls suggested that we bring the discussion to the
>>>> devel list for broader discussion. Most significantly, John raised the
>>>> possibility of changing the website from being a hand-coded PHP site, to
>>>> one that uses a content management system (CMS).
>>>> 
>>>> I think a CMS would be a good idea, assuming that the GnuCash website’s
>>>> look and feel can be reasonably approximated—or an alternative look and
>>>> feel can be accepted as the new norm. Having built websites manually,
>>>> then
>>>> coding my own php sites, and finally using a CMS, I can vouch for the
>>>> benefits of a CMS. Creating and managing content and features is much
>>>> easier with an established CMS. Creating a new version in a CMS that is
>>>> tightly locked down would allow the focus to be on the content but still
>>>> allow a broader number of contributors to possibly add to the GnuCash web
>>>> presence—something that the current system doesn’t do well. As I see it,
>>>> the GnuCash website doesn’t offer any significant special formatting or
>>>> whiz-bang web features, so I think its basic content could be ported
>>>> without a herculean effort.
>>>> 
>>>> Two major questions occur to me:
>>>> 
>>>> How would the current version control method of website management port
>>>> over to a CMS? and,
>>>> How would translations be handled in a CMS?
>>>> 
>>>> I am sure there are other big questions as well...
>>>> 
>>>> There are numerous CMS platforms out there; I am personally familiar with
>>>> Drupal, and know that it can quickly provide a robust and feature-laden
>>>> website. It seems to have tools for managing page translations, although
>>>> I
>>>> admit to only a superficial glance at what’s there, and I am not sure how
>>>> that issue would get handled for the GnuCash use case. It even has the
>>>> potential for providing a wiki experience, which might allow these two
>>>> pieces of the GnuCash web experience to become more closely linked.
>>>> 
>>>> I welcome your comments!
>>>> 
>>>> Best,
>>>> David
>>>> _______________________________________________
>>>> gnucash-devel mailing list
>>>> gnucash-devel at gnucash.org
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>> 
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> gnucash-devel at gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> 
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> 