Re: Website Platform Discussion

[John Ralls]

> On Jun 22, 2017, at 9:05 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> Sorry for the delay in responding; I was on vacation..
> 
> "David T."  writes:
> 
>> Derek,
> [snip]
>> 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.
> 
> I don't think that changing the website storage system would change
> this.  Getting the website changed is a simple "git pull request", and
> even if the underlying site changed to something else, I don't see this
> process changing.  What that says to me is that changing to a CMS wont
> make it any easier to change the content.
> 
>>   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.
> 
> Again, I dont see how changing the underlying infrastructure would help
> here.
> 
> To me, the issue is a lack of "maintainers".  We would need people who
> are responsible for the website and wiki content, monitor it, edit it,
> ensure that it remains current and up to date.
> 
> I agree that the wiki is probably easier for the majority of users
> because it doesn't use git.  But I'm perfect happy adding more people to
> the "website" commiter ACL, giving more people the ability to push
> updates to the website directly.
> 
>> 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?
> 
> Considering right now www.gnucash.org is a quazi static website that
> uses PHP for NEWS and Localization, I'm pretty sure it's immune.  The
> attack surface of the current www.gnucash.org site is fairly small.  I
> feel there's more of an attack vector against code/wiki.gnucash.org
> specifically because it's running more complicated software (namely
> mediawiki).
> 
>> 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.
> 
> Fair enough, but I would maintain that changing to a new platform that
> still gates through GIT would, in essence, not change the community
> willing to maintain a vibrant web presence.  At least I suspect it's
> "git" that's the barrier to entry and not the fact that it's a raw
> PHP-based website vs Drupal/et al.
> 
> In short -- I don't see how adding (or changing to) Drupal would
> increase the number of people willing and able to keep the website
> content up to date.

I suggested that a switch to a CMS might be necessary after David suggested and 
Geert supported having a carousel on the front page. Introducing and 
maintaining features like that in hand-maintained PHP strikes me as rather 
technical as well as error prone and likely to introduce security risks as 
AFAIK none of us are expert at that kind of code.

I don't know Drupal but I do maintain a Joomla-based website 
(http://californiaancestors.org). Joomla allows non-programmers to easily edit 
content in a more-or-less WYSIWYG editor. The editor also has a "source" mode 
for working directly with the html and css to get exactly the look you want. 
That would certainly broaden the base of potential contributors to the many who 
wig out at the very thought of opening a code editor.

The php code behind the CMS is certainly amenable to version control, but the 
content is stored in a database (typically MySQL). It would be possible to get 
that under git control but it would take a bit of work, as would implementing a 
post-update hook to convert a git diff into the necessary PHP-MyAdmin commands 
to update the content database.

Regards,
John Ralls

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

Re: Website Platform Discussion

[Geert Janssens]

On donderdag 22 juni 2017 18:05:40 CEST Derek Atkins wrote:
> Hi,
> 
> Sorry for the delay in responding; I was on vacation..
> 
> "David T."  writes:
> > Derek,
> 
> [snip]
> 
> > 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.
> 
> I don't think that changing the website storage system would change
> this.  Getting the website changed is a simple "git pull request", and
> even if the underlying site changed to something else, I don't see this
> process changing.  What that says to me is that changing to a CMS wont
> make it any easier to change the content.
> 
I disagree.

A CMS based website has several parts, to simplify:
- the CMS code with optional modules (drupal/mediawiki/...)
- the theme
- the content

The first two would be managed in git, the latter would be managed by a 
webinterface (and stored partly in a db/partly in a data directory on the 
server).

So the initial work of getting the website up and running technically and 
getting the theme right will require git interaction.

However altering content would not. From the mere reactions to this thread it 
looks like several people would definitely volunteer to help out maintaining 
the content. However I think that will only work if the content is not managed 
in a developer-centric mindset (aka via git). I would love to see those 
volunteers in come in action. If separating content management from code and 
theme management would support this, I really think we should consider it.

> >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.
> 
> Again, I dont see how changing the underlying infrastructure would help
> here.
> 
> To me, the issue is a lack of "maintainers".  We would need people who
> are responsible for the website and wiki content, monitor it, edit it,
> ensure that it remains current and up to date.
> 
And I argue this lack of "maintainers" is in part because of the way we manage 
our main site.

Note a recent thread on obsolete pages in the wiki immediately resulted in 
several people willing to go over the wiki and refresh it. The wiki has no 
"commit through git" management wrapped around it.

> I agree that the wiki is probably easier for the majority of users
> because it doesn't use git.  But I'm perfect happy adding more people to
> the "website" commiter ACL, giving more people the ability to push
> updates to the website directly.

I continue to argue allowing more people to use git is not going to bring us 
more people willing to keep the content up to date simply because git itself 
is a pretty effective deterrent for non-developers (who would otherwise be 
perfectly capable of writing good website content).

> 
> > 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?
> 
> Considering right now www.gnucash.org is a quazi static website that
> uses PHP for NEWS and Localization, I'm pretty sure it's immune.  The
> attack surface of the current www.gnucash.org site is fairly small.  I
> feel there's more of an attack vector against code/wiki.gnucash.org
> specifically because it's running more complicated software (namely
> mediawiki).

Yes, CMS systems are a complex body of code and hence have a bigger potential 
for security issues. At the same time they are constantly monitored  by a 
larger number of people as well.

The suggestion was made that drupal could be configured to behave similarly to 
a wiki (while other parts of the same website are still typical CMS pages). 
That is a very tempting idea to me. It would reduce that attack surface again 
to one CMS as it could then replace mediawiki, it would be very nice to theme 
the wiki and more static pages using the same theming engine,...

Of course it would still remain a complex piece of code requiring frequent 

Re: Website Platform Discussion

[Jim DeLaHunt]

Derek:

Welcome back. And by the way, thank you for all your work on Gnucash. I 
benefit greatly from the work of everyone who makes this wonderful product.


On 2017-06-22 09:05, Derek Atkins wrote:

...At least I suspect it's "git" that's the barrier to entry and not the fact 
that it's a raw
PHP-based website vs Drupal/et al
I have a different opinion. I see the barriers to entry for a new 
contributor to the website being (in decreasing order of importance):


1. not feeling empowered or capable: "such a big website", "not sure
   where to start", "afraid I'll screw up"
2. hard to express the change I want to make in raw HTML: "how do I
   format the table just right?" "What's the right URL for this link to
   another part of the site?" "How do I keep my change visually
   consistent with the rest?"
3. difficult to make changes that affect multiple pages on the site:
   "how do I add another item to the navigation panel?"
4. how to open the website for editing, save changes, commit to
   production: "how do I use git?"

 A content management system helps #1 somewhat: the system will prevent 
you from making a class of stupid mistakes if merely editing content. 
It's a big help for #2 and #3.   It's somewhat of a help for #4, 
especially for simple changes.


The use of git seems to me to be a barrier primarily for #4, and not all 
that relevant for #1, #2, and #3.


--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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

Re: Website Platform Discussion

[Derek Atkins]

Hi,

Sorry for the delay in responding; I was on vacation..

"David T."  writes:

> Derek,
[snip]
> 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.

I don't think that changing the website storage system would change
this.  Getting the website changed is a simple "git pull request", and
even if the underlying site changed to something else, I don't see this
process changing.  What that says to me is that changing to a CMS wont
make it any easier to change the content.

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

Again, I dont see how changing the underlying infrastructure would help
here.

To me, the issue is a lack of "maintainers".  We would need people who
are responsible for the website and wiki content, monitor it, edit it,
ensure that it remains current and up to date.

I agree that the wiki is probably easier for the majority of users
because it doesn't use git.  But I'm perfect happy adding more people to
the "website" commiter ACL, giving more people the ability to push
updates to the website directly.

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

Considering right now www.gnucash.org is a quazi static website that
uses PHP for NEWS and Localization, I'm pretty sure it's immune.  The
attack surface of the current www.gnucash.org site is fairly small.  I
feel there's more of an attack vector against code/wiki.gnucash.org
specifically because it's running more complicated software (namely
mediawiki).

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

Fair enough, but I would maintain that changing to a new platform that
still gates through GIT would, in essence, not change the community
willing to maintain a vibrant web presence.  At least I suspect it's
"git" that's the barrier to entry and not the fact that it's a raw
PHP-based website vs Drupal/et al.

In short -- I don't see how adding (or changing to) Drupal would
increase the number of people willing and able to keep the website
content up to date.

> 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

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

Re: Website Platform Discussion

[Adrien Monteleone]

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

Re: Website Platform Discussion

[Jim DeLaHunt]

David:

I love your question:

> How would translations be handled in a CMS?

For the case of Drupal, there are mature and capable tools for hosting 
multilingual content on a Drupal-based website. See e.g. 
 I know those tools and 
would be happy to help with this aspect of a new GnuCash site.


Eric Theise suggests Jekyll. I don't know Jekyll, but based on a quick 
look I can see why people would like it. I don't know how easy it is to 
host multilingual content on a Jekyll-based site, but others have 
explored this. See e.g. 
. Again, I 
would be happy to help with this aspect. It would be a good learning 
exercise for me.


  --Jim DeLaHunt, Vancouver, Canada


On 2017-06-15 10:57, David T. via gnucash-devel 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


--
  --Jim DeLaHunt, j...@jdlh.com   http://blog.jdlh.com/ (and jdlh.com)
multilingual websites consultant. GnuCash 2.6.11 on MacOS X 10.10.

  157-2906 West Broadway, Vancouver BC V6K 2G8, Canada
 Canada mobile +1-604-376-8953

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

Re: Website Platform Discussion

[Eric Theise]

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

Website Platform Discussion

[David T. via gnucash-devel]

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