Then I don’t suppose it’s a major issue. You’d just need a backup of public_html (or WWW folder, whichever is used) like is probably being done now, and a dump of whatever db is used for the cms. Since there is already a dump of the wiki db, it would just be an extra one of those for the cms db. A straight dump by the db software or a tar.gz by the OS will do. Whatever procedure is currently used for the wiki should be fine for the cms.
> On Jun 16, 2017, at 10:58 AM, John Ralls <jra...@ceridwen.us> wrote: > >> >> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone <adrien.montele...@gmail.com >> <mailto:adrien.montele...@gmail.com>> wrote: >> >>> >>> On Jun 16, 2017, at 2:47 AM, Geert Janssens <geert.gnuc...@kobaltwit.be >>> <mailto: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. > > Adrien, > > Our “hosting provider” is Linas Vepstas, one of the original developers of > GnuCash, on a machine at his home. There is no CPanel or Plex interface and > AFAIK nobody has remote shell access to it. OTOH he knows how to set up > backups, we'll just need to tell him what to back up. An obvious offsite > location would be code.gnucash.org <http://code.gnucash.org/> hosted at Derek > Atkins’s house, which is where the wiki and canonical git repositories live. > > Regards, > John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
