> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@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.
The site host should provide a facility for this either through cPanel/Plex, or you can set a cron job via SSH. Many have options to schedule backups to an offsite FTP server. You’d need to regularly back up both the db and the site structure. > > 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. > > 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 <ericthe...@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@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@gnucash.org >>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>> >>> _______________________________________________ >>> gnucash-devel mailing list >>> gnucash-devel@gnucash.org >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> >> _______________________________________________ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel