> On Jun 16, 2017, at 1:40 PM, Geert Janssens <geert.gnuc...@kobaltwit.be> > wrote: > > On vrijdag 16 juni 2017 19:25:25 CEST Adrien Monteleone wrote: >> Adrien Monteleone >> adrien.montele...@gmail.com >> 337-593-8208 >> 103 Rosalind street >> Lafayette, Louisiana >> >>> 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. >>> >>> 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.
It shouldn’t be an issue. Both versions will automatically get security updates at the same time. Alternatively, you could turn this off and use GIT for all of it, but that requires more diligence. > >> >> 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
