Website Platform Discussion

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Website Platform Discussion

GnuCash - Dev mailing list
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <
[hidden email]> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Jim DeLaHunt-3
In reply to this post by GnuCash - Dev mailing list
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.
<https://www.drupal.com/feature/multilingual> 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.
<https://www.sylvaindurand.org/making-jekyll-multilingual/>. 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
   --Jim DeLaHunt, [hidden email]   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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Adrien Monteleone
In reply to this post by Eric Theise
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 <[hidden email]> 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 <
> [hidden email]> 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
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Geert Janssens-4
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 <[hidden email]> 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 <
> >
> > [hidden email]> 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
> >> [hidden email]
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> > _______________________________________________
> > gnucash-devel mailing list
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Adrien Monteleone

> On Jun 16, 2017, at 2:47 AM, Geert Janssens <[hidden email]> 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 <[hidden email]> 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 <
>>>
>>> [hidden email]> 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
>>>> [hidden email]
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> [hidden email]
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

John Ralls-2

> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone <[hidden email]> wrote:
>
>>
>> On Jun 16, 2017, at 2:47 AM, Geert Janssens <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Derek Atkins
In reply to this post by Geert Janssens-4
Hi,

Geert Janssens <[hidden email]> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

gnucash-10
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Adrien Monteleone
In reply to this post by John Ralls-2
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 <[hidden email]> wrote:
>
>>
>> On Jun 16, 2017, at 8:30 AM, Adrien Monteleone <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>>
>>> On Jun 16, 2017, at 2:47 AM, Geert Janssens <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> My (limited) experience is with drupal as well.
>>>
>>> Regarding your first question (how to map version management on a cms driven
>>> website): usually only the cms code, modules and themes are version managed.
>>> The data resides in a database which is not well suited for version
>>> management. So code, module and theme updates would be done in much the same
>>> way as is done for the current website. One clones the git repository holding
>>> all the website code, make changes, create a PR/push upstream. The only
>>> additional step would be to run db updates right after this. Perhaps even that
>>> could be scripted.
>>> The actual content needs something else, just like we need something else for
>>> our wiki pages. Both mediawiki (for our wiki pages) and drupal support "page
>>> revisions". So just as in the wiki we could follow the history of changes made
>>> to each page.
>>>
>>> A side effect of the content being in a db rather than in git is it is no
>>> longer stored in a distributed way. So it will be important to implement a
>>> backup plan for the data.
>>
>> The site host should provide a facility for this either through cPanel/Plex, or you can set a cron job via SSH. Many have options to schedule backups to an offsite FTP server.
>>
>> You’d need to regularly back up both the db and the site structure.
>
> Adrien,
>
> Our “hosting provider” is Linas Vepstas, one of the original developers of GnuCash, on a machine at his home. There is no CPanel or Plex interface and AFAIK nobody has remote shell access to it. OTOH he knows how to set up backups, we'll just need to tell him what to back up. An obvious offsite location would be code.gnucash.org <http://code.gnucash.org/> hosted at Derek Atkins’s house, which is where the wiki and canonical git repositories live.
>
> Regards,
> John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Adrien Monteleone
In reply to this post by gnucash-10

> On Jun 16, 2017, at 11:54 AM, Jon Daley <[hidden email]> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Adrien Monteleone
In reply to this post by Geert Janssens-4

Adrien Monteleone
[hidden email]
337-593-8208
103 Rosalind street
Lafayette, Louisiana

> On Jun 16, 2017, at 2:47 AM, Geert Janssens <[hidden email]> 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 <[hidden email]> 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 <
>>>
>>> [hidden email]> 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
>>>> [hidden email]
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>>> _______________________________________________
>>> gnucash-devel mailing list
>>> [hidden email]
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> [hidden email]
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Geert Janssens-4
In reply to this post by Adrien Monteleone
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Geert Janssens-4
In reply to this post by Adrien Monteleone
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Derek Atkins
In reply to this post by Adrien Monteleone
Adrien Monteleone <[hidden email]> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Derek Atkins
In reply to this post by Adrien Monteleone
Adrien Monteleone <[hidden email]> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

Derek Atkins
In reply to this post by gnucash-10
Jon Daley <[hidden email]> 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           Size    Used   Avail Capacity  Mounted on
freenas-0/backups    5.3T    645G    4.6T    12%    /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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

gnucash-10
In reply to this post by Adrien Monteleone
On Fri, 16 Jun 2017, Adrien Monteleone wrote:

>> On Jun 16, 2017, at 11:54 AM, Jon Daley <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

gnucash-10
In reply to this post by Derek Atkins
On Fri, 16 Jun 2017, Derek Atkins wrote:

> Jon Daley <[hidden email]> 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           Size    Used   Avail Capacity  Mounted on
> freenas-0/backups    5.3T    645G    4.6T    12%    /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.5G gnucash-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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Website Platform Discussion

gnucash-10
On Fri, 16 Jun 2017, Jon Daley wrote:

> On Fri, 16 Jun 2017, Derek Atkins wrote:
>> Jon Daley <[hidden email]> 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           Size    Used   Avail Capacity  Mounted on
>> freenas-0/backups    5.3T    645G    4.6T    12%    /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.5G gnucash-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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
12
Loading...