Re: Gtk3

[John Ralls]

Bob,

Super! Thanks!

The treatment of stock images was something of a moving target in Gtk3 so you 
may have to do some config/cmake work to figure out what to use and then 
conditionally compile based the result. We do need to look good on 3.10-3.22 
and everything in between. I think complaints about that were one of the 
motivations for the new release plan for 4.x.

Change the Glade files as much as you think appropriate and have time for.

Regards,
John Ralls

> On Jun 16, 2017, at 9:24 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> OK, I have been tapping away with the following progress...
> I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
> but I seem to of lost some stock images, not an issue as I can temporary
> replace them
> but I can use it to make sure I have not included any newer functions.
> 
> In the original VM I have built and made some changes which can be seen at My
> GitHub 
> I have hopefully done the following but as normal there may be some
> tweaks...
> Replaced RC file with CSS file, name may need changing
> The dense calendar now renders with a white background but can be set with
> CSS
> Changed the way tabs are done and now display correctly and fixed the width
> updates
> Changed most widgets that had a horizontal / vertical function to the new
> equivalents.  These were simple function swaps I had in existing patch file.
> 
> I was going to look at the account edit dialogue but wanted to ask how much
> do you want the glade files changed ?
> Change the version and replace deprecated widgets ?
> 
> There are some further deprecated widgets that I will change if able to as
> I come across them.
> 
> Bob
> 
> On 6 June 2017 at 09:54, Geert Janssens  wrote:
> 
>> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
>>> Hi,
>>> 
>>> I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I
>> have
>>> pulled from there and recently updated my local version which was built
>>> successfully.
>>> I tend not to fiddle where other people are working as I would no doubt
>>> just get in the way or slow down their efforts.
>>> 
>>> If you would like me to look at some thing, just ask and I will have a
>>> look, been looking at some schedule bugs but they can wait...
>>> 
>>> What version of Gtk3 are these changes aimed at, my gtk3 development VM
>> is
>>> on 3.20.9 ?
>> 
>> Hi Bob,
>> 
>> I'm happy you're willing to jump in as well.
>> 
>> As John already mentioned (and you could have read on IRC) I'm currently
>> pretty occupied outside of the gnucash project.
>> 
>> The Gtk3 version to target is 3.10. This is the most recent version on
>> Ubuntu
>> Trusty, which is the base OS for our Travis builds. Any other build
>> platform
>> we care about comes with a more recent version of gtk3.
>> 
>> Feel free to clone my branch and make PR's against it.
>> 
>> So far I've been mostly focused on
>> 1. getting it to build and run (which should be accomplished)
>> 2. Tweak the the register code to make it render properly
>> 
>> For part 1 I needed do replace several Gtk2 functions that have been
>> removed
>> from Gtk3. The code wouldn't build otherwise. I only did minimal changes to
>> get it to run. With that I mean I only replaced removed functions, not
>> deprecated API.
>> 
>> So here are a few opportunities to jump in:
>> - The rendering of the custom calendar in the SX editor is wrong. I think
>> the
>> background isn't rendered, but there may be other things going on there.
>> - Tab titles aren't rendering correctly. They are being rendered as "..."
>> instead of the full (or partially elipsized) text. I suspect this has to do
>> with Gtk3 new paradigm of minimal vs natural width, which we're not
>> handling
>> properly for the tab titles.
>> - There may still be other visual issues I haven't spotted yet. If
>> discovered
>> these should get priority over the next point IMO.
>> - There are lots of deprecated API warnings. Unfortunately Gtk3 has been
>> moving target so there are new deprecations in almost every Gtk3 release. I
>> propose to focus on those function calls which have been deprecated in Gtk3
>> 3.10 or earlier.
>> 
>> I will continue to focus on the register code and will communicate my
>> progress
>> when I get to it.
>> 
>> Regards,
>> 
>> Geert
>> 
> ___
> 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

Re: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 1:40 PM, Geert Janssens  
> 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 
>>> 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 

Re: Website Platform Discussion

[Geert Janssens]

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 
> > 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Adrien Monteleone]

I just pulled down a copy of GnuCash.org with SiteSucker. Total size is 228MB, 
210MB of which are docs in various formats and translations. (ePub, etc.)

There is less than 1MB of images, though I’d suppose that may change in the 
future.

And this is uncompressed.

The site itself is nill. The infrastructure and theme for the CMS will likely 
be larger than content for some time.

I should think since the docs are built separately anyway, they can remain in 
sub-folder and be backed up separately if desired. Worst case would be someone 
would have to regenerate the various formats and translations if they were lost.

Not that I’d go that route, but a thumdrive could handle it.

Regards,
Adrien

> On Jun 16, 2017, at 12:39 PM, Derek Atkins  wrote:
> 
> Jon Daley  writes:
> 
>> On Fri, 16 Jun 2017, Derek Atkins wrote:
>>> Code performs a nightly mysql dump, and I have a nightly backup of all
>>> my servers (including code) to a backup server with storage on my
>>> FreeNAS box.  This is all completely automated.  The only thing I do not
>>> have, yet, is a an offsite backup plan to protect against fire, tornado,
>>> etc.
>>> 
>>> Linas and I have discussed using each other for offsite backups, but
>>> then he disappeared for 6 weeks and we haven't returned to the topic.
>> 
>>  How much data do you have that needs to be backed up?  I have
>> space that I can offer, depending on how big it is.
> 
> Right now the backup volume uses 645GB:
> 
> [root@freenas] ~# df -h /mnt/freenas-0/backups/
> Filesystem   SizeUsed   Avail Capacity  Mounted on
> freenas-0/backups5.3T645G4.6T12%/mnt/freenas-0/backups
> 
> Note, however, this is all my servers' backups, not just code.  Code's
> backup is a fraction of this, but I couldn't tell you offhand how much
> it is.
> 
> What I can show you is how mych the htdocs repos take:
> 
> [root@code repositories]# du -sh gnucash-htdocs*
> 2.5G  gnucash-htdocs-docs.git
> 20M   gnucash-htdocs.git
> 
> -derek
> -- 
>   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>   Member, MIT Student Information Processing Board  (SIPB)
>   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>   warl...@mit.eduPGP key available
> ___
> 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

Re: Website Platform Discussion

[David T. via gnucash-devel]

Derek,

> On Jun 16, 2017, at 10:33 PM, Derek Atkins  wrote:
> 
> Adrien Monteleone  writes:
> 
>>> 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.
> 
> Okay, so... what's the actual benefit of migrating www.gnucash.org to a
> CMS?  Right now we can easily update the website remotely, have
> translations, images, etc.  And it doesn't require Linas to do much
> maintenance work.  The content is quazi-static, so it really doesn't
> need a lot of updates.  It's not like the application is changing it's
> look at feel every couple months!
> 

As the one who started this, I’d say the immediate payoff with regard to the 
issues you raise is limited. However, I had made some suggestions on Bugzilla 
about changing the website (and possibly the wiki as well) that were beginning 
to take on more substantial nature. At that point, the idea of looking more 
generally at ways to facilitate change on the website/wiki seemed appropriate.


I will note that one of the problems I see with the website/wiki presence is 
precisely its static nature. Pages and information seem to get on the sites and 
never change or get updated. A number of the wiki pages I was just looking at 
had references to “new” features for v1.8, along with links to discussions in 
the mailing lists ca. 2002. There were references to resources that have long 
ago disappeared off the Internet, as well as discussions about issues that are 
no longer relevant to GnuCash in 2017—like discussions about code to create SQL 
data from an XML data file, which while perhaps still interesting, are 
nonetheless rendered rather moot with the incorporation of the SQL back end in 
2.4.

As for the ongoing maintenance of a cms, I agree that it can be a pain. 
However, at least with Drupal, I find the process pretty quick to manage (in 
fact, I just installed an update today), and assuming that the GnuCash site 
would continue to be a basic site, it would likely not require many additional 
modules—thus keeping the update routines simpler. Moreover, with a bundled cms, 
you have web developers who are maintaining awareness of security issues and 
pushing out fixes for them. In this day of increased threat vectors online, can 
we be sure that the GnuCash site is immune to these new threats?

Whether a new platform would encourage the community to maintain a vibrant web 
presence or not is of course debatable. but I think it’s a fair one to have.

David


> -derek
> -- 
>   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>   Member, MIT Student Information Processing Board  (SIPB)
>   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
>   warl...@mit.eduPGP key available
> ___
> 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

Re: Website Platform Discussion

[Jon Daley]

On Fri, 16 Jun 2017, Jon Daley wrote:

On Fri, 16 Jun 2017, Derek Atkins wrote:

Jon Daley  writes:

How much data do you have that needs to be backed up?  I have
space that I can offer, depending on how big it is.


Right now the backup volume uses 645GB:

[root@freenas] ~# df -h /mnt/freenas-0/backups/
Filesystem   SizeUsed   Avail Capacity  Mounted on
freenas-0/backups5.3T645G4.6T12%/mnt/freenas-0/backups

Note, however, this is all my servers' backups, not just code.  Code's
backup is a fraction of this, but I couldn't tell you offhand how much
it is.


	Hm, the total number is kind of big.  At the moment I have extra disk 
space that could handle it, but if a paying customer came along, I would 
rather sell that amount of space than give it away.



What I can show you is how mych the htdocs repos take:

[root@code repositories]# du -sh gnucash-htdocs*
2.5Ggnucash-htdocs-docs.git
20M gnucash-htdocs.git


	I wasn't totally following the conversation about all of this, but if 
I can be of help with 5 or 10GB, I can do that.


And I suppose I should have said - my servers are RAID5 or 6, and also 
backed up off-site with an incremental backup every few days, full backups 
every two weeks, and it saves backups for a month or two.


If there was a way for me to get an ssh/rsync account to where the data is 
stored, then I wouldn't have to have the "extra" copy stored up on the 
web, but just kept on my backup system, which maybe would be nicer, but 
either way is okay with me.





--
Jon Daley
http://jon.limedaley.com
~~
It always takes longer than you expect, even when you take into
account Hofstadter's Law.
-- Hofstadter's Law
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Jon Daley]

On Fri, 16 Jun 2017, Derek Atkins wrote:

Jon Daley  writes:

How much data do you have that needs to be backed up?  I have
space that I can offer, depending on how big it is.


Right now the backup volume uses 645GB:

[root@freenas] ~# df -h /mnt/freenas-0/backups/
Filesystem   SizeUsed   Avail Capacity  Mounted on
freenas-0/backups5.3T645G4.6T12%/mnt/freenas-0/backups

Note, however, this is all my servers' backups, not just code.  Code's
backup is a fraction of this, but I couldn't tell you offhand how much
it is.


	Hm, the total number is kind of big.  At the moment I have extra 
disk space that could handle it, but if a paying customer came along, I 
would rather sell that amount of space than give it away.



What I can show you is how mych the htdocs repos take:

[root@code repositories]# du -sh gnucash-htdocs*
2.5Ggnucash-htdocs-docs.git
20M gnucash-htdocs.git


	I wasn't totally following the conversation about all of this, but 
if I can be of help with 5 or 10GB, I can do that.



--
Jon Daley
http://jon.limedaley.com
~~
To be upset over what you don't have is to waste what you do have.
-- Unknown
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Jon Daley]

On Fri, 16 Jun 2017, Adrien Monteleone wrote:

On Jun 16, 2017, at 11:54 AM, Jon Daley  wrote:
On Fri, 16 Jun 2017, Derek Atkins wrote:

Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box.  This is all completely automated.  The only thing I do not
have, yet, is a an offsite backup plan to protect against fire, tornado,
etc.

Linas and I have discussed using each other for offsite backups, but
then he disappeared for 6 weeks and we haven't returned to the topic.


	How much data do you have that needs to be backed up?  I have 
space that I can offer, depending on how big it is.


We could get the current backup size as a starting point and then add a 
blank cms install size on top of that. (content + structure) Of course, 
we won’t really know till at least a staging version is up and running 
and content has been ported over.


As with any site, images take the most room. I suspect though these will 
be limited to screen shots so I wouldn’t anticipate the requirement 
being high.


For a ballpark idea, I have backups for an e-commerce and blog site that 
has about 100 blog posts of 250+ words each and about 500 product images 
of fair quality (usually 800-1000px longest side and stored as 75% 
quality JPGs) and that db takes up 500K and the site with images takes 
up 2GB. Both backup files are tar.gz.


I have room for that, and could give you an account to copy or rsync or 
whatever.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Derek Atkins]

Jon Daley  writes:

> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Code performs a nightly mysql dump, and I have a nightly backup of all
>> my servers (including code) to a backup server with storage on my
>> FreeNAS box.  This is all completely automated.  The only thing I do not
>> have, yet, is a an offsite backup plan to protect against fire, tornado,
>> etc.
>>
>> Linas and I have discussed using each other for offsite backups, but
>> then he disappeared for 6 weeks and we haven't returned to the topic.
>
>   How much data do you have that needs to be backed up?  I have
> space that I can offer, depending on how big it is.

Right now the backup volume uses 645GB:

[root@freenas] ~# df -h /mnt/freenas-0/backups/
Filesystem   SizeUsed   Avail Capacity  Mounted on
freenas-0/backups5.3T645G4.6T12%/mnt/freenas-0/backups

Note, however, this is all my servers' backups, not just code.  Code's
backup is a fraction of this, but I couldn't tell you offhand how much
it is.

What I can show you is how mych the htdocs repos take:

[root@code repositories]# du -sh gnucash-htdocs*
2.5Ggnucash-htdocs-docs.git
20M gnucash-htdocs.git

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Derek Atkins]

Adrien Monteleone  writes:

> 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.

It's a little more than that.  Linas maintains www, so it would need to
work into his backup infrastructure, not mine.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Derek Atkins]

Adrien Monteleone  writes:

>> 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.

Okay, so... what's the actual benefit of migrating www.gnucash.org to a
CMS?  Right now we can easily update the website remotely, have
translations, images, etc.  And it doesn't require Linas to do much
maintenance work.  The content is quazi-static, so it really doesn't
need a lot of updates.  It's not like the application is changing it's
look at feel every couple months!

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Geert Janssens]

On vrijdag 16 juni 2017 18:58:35 CEST Adrien Monteleone wrote:
> 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.

Oh and I meant to add, the cms code including themes will live in git, so it 
will already be replicated at least to github.

The only things requiring additional backup configuration are the db (easily 
done via db dump) and any content that's not stored in the db (such as 
images).

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Geert Janssens]

On vrijdag 16 juni 2017 18:58:35 CEST Adrien Monteleone wrote:
> 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.

Not a problem indeed. My main motivation to bring this up was to remind us 
this has to be set up as we have no db in use for the website right now, so no 
backup set up either.

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Adrien Monteleone]

Adrien Monteleone
adrien.montele...@gmail.com
337-593-8208
103 Rosalind street
Lafayette, Louisiana

> On Jun 16, 2017, at 2:47 AM, Geert Janssens  
> 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  wrote:
>>> 
>>> Hi all,
>>> 
>>> My trajectory with site-building is somewhat similar to David's except
>>> that
>>> I ended up 

Re: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 11:54 AM, Jon Daley  wrote:
> 
> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Code performs a nightly mysql dump, and I have a nightly backup of all
>> my servers (including code) to a backup server with storage on my
>> FreeNAS box.  This is all completely automated.  The only thing I do not
>> have, yet, is a an offsite backup plan to protect against fire, tornado,
>> etc.
>> 
>> Linas and I have discussed using each other for offsite backups, but
>> then he disappeared for 6 weeks and we haven't returned to the topic.
> 
>   How much data do you have that needs to be backed up?  I have space 
> that I can offer, depending on how big it is.

We could get the current backup size as a starting point and then add a blank 
cms install size on top of that. (content + structure) Of course, we won’t 
really know till at least a staging version is up and running and content has 
been ported over.

As with any site, images take the most room. I suspect though these will be 
limited to screen shots so I wouldn’t anticipate the requirement being high.

For a ballpark idea, I have backups for an e-commerce and blog site that has 
about 100 blog posts of 250+ words each and about 500 product images of fair 
quality (usually 800-1000px longest side and stored as 75% quality JPGs) and 
that db takes up 500K and the site with images takes up 2GB. Both backup files 
are tar.gz.

-Adrien

> 
> -- 
> Jon Daley
> http://jon.limedaley.com
> ~~
> Work is the curse of the drinking classes.
> -- Rev. William Spooner
> ___
> 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

Re: Website Platform Discussion

[Adrien Monteleone]

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  wrote:
> 
>> 
>> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone > > wrote:
>> 
>>> 
>>> On Jun 16, 2017, at 2:47 AM, Geert Janssens >> > 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  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

Re: Website Platform Discussion

[Jon Daley]

On Fri, 16 Jun 2017, Derek Atkins wrote:

Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box.  This is all completely automated.  The only thing I do not
have, yet, is a an offsite backup plan to protect against fire, tornado,
etc.

Linas and I have discussed using each other for offsite backups, but
then he disappeared for 6 weeks and we haven't returned to the topic.


	How much data do you have that needs to be backed up?  I have 
space that I can offer, depending on how big it is.


--
Jon Daley
http://jon.limedaley.com
~~
Work is the curse of the drinking classes.
-- Rev. William Spooner
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[Derek Atkins]

Hi,

Geert Janssens  writes:

> That goes for the current wiki as well by the way. Do we have a backup in 
> place there ?

Code performs a nightly mysql dump, and I have a nightly backup of all
my servers (including code) to a backup server with storage on my
FreeNAS box.  This is all completely automated.  The only thing I do not
have, yet, is a an offsite backup plan to protect against fire, tornado,
etc.

Linas and I have discussed using each other for offsite backups, but
then he disappeared for 6 weeks and we haven't returned to the topic.

-derek
-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3

[Robert Fewell]

OK, I have been tapping away with the following progress...
I downgraded a clone VM to Gtk+3.10.8 which successfully builds and runs
but I seem to of lost some stock images, not an issue as I can temporary
replace them
 but I can use it to make sure I have not included any newer functions.

In the original VM I have built and made some changes which can be seen at My
GitHub 
I have hopefully done the following but as normal there may be some
tweaks...
Replaced RC file with CSS file, name may need changing
The dense calendar now renders with a white background but can be set with
CSS
Changed the way tabs are done and now display correctly and fixed the width
updates
Changed most widgets that had a horizontal / vertical function to the new
equivalents.  These were simple function swaps I had in existing patch file.

I was going to look at the account edit dialogue but wanted to ask how much
do you want the glade files changed ?
Change the version and replace deprecated widgets ?

There are some further deprecated widgets that I will change if able to as
I come across them.

Bob

On 6 June 2017 at 09:54, Geert Janssens  wrote:

> On maandag 5 juni 2017 12:19:24 CEST Robert Fewell wrote:
> > Hi,
> >
> > I was browsing the IRC logs and Geert mentioned his gtk3 branch, yes I
> have
> > pulled from there and recently updated my local version which was built
> > successfully.
> > I tend not to fiddle where other people are working as I would no doubt
> > just get in the way or slow down their efforts.
> >
> > If you would like me to look at some thing, just ask and I will have a
> > look, been looking at some schedule bugs but they can wait...
> >
> > What version of Gtk3 are these changes aimed at, my gtk3 development VM
> is
> > on 3.20.9 ?
>
> Hi Bob,
>
> I'm happy you're willing to jump in as well.
>
> As John already mentioned (and you could have read on IRC) I'm currently
> pretty occupied outside of the gnucash project.
>
> The Gtk3 version to target is 3.10. This is the most recent version on
> Ubuntu
> Trusty, which is the base OS for our Travis builds. Any other build
> platform
> we care about comes with a more recent version of gtk3.
>
> Feel free to clone my branch and make PR's against it.
>
> So far I've been mostly focused on
> 1. getting it to build and run (which should be accomplished)
> 2. Tweak the the register code to make it render properly
>
> For part 1 I needed do replace several Gtk2 functions that have been
> removed
> from Gtk3. The code wouldn't build otherwise. I only did minimal changes to
> get it to run. With that I mean I only replaced removed functions, not
> deprecated API.
>
> So here are a few opportunities to jump in:
> - The rendering of the custom calendar in the SX editor is wrong. I think
> the
> background isn't rendered, but there may be other things going on there.
> - Tab titles aren't rendering correctly. They are being rendered as "..."
> instead of the full (or partially elipsized) text. I suspect this has to do
> with Gtk3 new paradigm of minimal vs natural width, which we're not
> handling
> properly for the tab titles.
> - There may still be other visual issues I haven't spotted yet. If
> discovered
> these should get priority over the next point IMO.
> - There are lots of deprecated API warnings. Unfortunately Gtk3 has been
> moving target so there are new deprecations in almost every Gtk3 release. I
> propose to focus on those function calls which have been deprecated in Gtk3
> 3.10 or earlier.
>
> I will continue to focus on the register code and will communicate my
> progress
> when I get to it.
>
> Regards,
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Website Platform Discussion

[John Ralls]

> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone  
> wrote:
> 
>> 
>> On Jun 16, 2017, at 2:47 AM, Geert Janssens  
>> 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 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

Re: Website Platform Discussion

[Adrien Monteleone]

> On Jun 16, 2017, at 2:47 AM, Geert Janssens  
> 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  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 

Re: Website Platform Discussion

[Geert Janssens]

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.

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