Re: [Gimp-web] Update on New Site

[Pat David <patdavid gmail com>]

To minimize attack vectors and server resource requirements.  We literally
have zero requirements for any server-side scripting, particularly during
client requests.

More to the point - what benefit does any CMS/blog system provide for us
over what we're doing here?

The benefit of using a static-site is that contributors will need to test
what they write before sending patches/pull-requests.  With Pelican, they
can compile entirely into a local directory, and use a simple lightweight
http server to see the results.

With Chyrp they cannot.  I don't like the idea of letting just anyone write
things to a production server, and if they want to test locally, they'll
have to get a full installation going as well... :(

There's not need for PHP, or a database, on the server side for what we do.
:)

On Wed, Aug 19, 2015 at 3:06 PM Kasim Ahmic <kasim ahmic gmail com> wrote:

> I really only have one question about this whole thing: why go through the
> trouble of hacking together a Pelican based website when you could get a
> simple, lightweight blogging engine like Chyrp to handle all the blog
> functions while every other page is hard coded. I may be missing something
> here but from what I see, with Pelican, you hard code a page, run pelican,
> and it compiles it to a directory where it's viewable to others. I seems
> unnecessary and a bit redundant to me. What exactly are the benefits to
> using Pelican?
>
> Kasim Ahmic
>
> Sent from my iPhone
>
> > On Aug 19, 2015, at 9:15 PM, Pat David <patdavid gmail com> wrote:
> >
> > Michael made a comment on the previous thread about the dev update posts
> > from Karine.  I _think_ he meant gimp-dev vs. gimp-web, but I'm going to
> > update everyone anyway.
> >
> > I've been sort of off in the corner playing around with my own stuff for
> a
> > while.  It was previously on my list to eventually get around to updating
> > the site to modernize it a bit, but the (relatively) recent post from
> > Cristobal and others comments made me decide to go ahead and give it a
> shot.
> > I made my initial notes, assumptions, and thoughts on the WGO Redesign
> page
> > on the wiki: http://wiki.gimp.org/index.php?title=WGO_Redesign
> >
> > That page contains thoughts and rationale behind using a static site,
> using
> > Python, Pelican (a Python SSG - static site generator), and helping to
> > lower the barrier to entry for contributors.
> >
> > So I ran off, learned some Python, grabbed Pelican, played with a simple
> > mockup, and started hacking.  It wasn't hard to get up to speed
> relatively
> > quickly (mostly because I am still fresh off of building pixls.us using
> an
> > SSG in node.js).  The idea is simple:
> >
> > Input folder of files + assets.  Process certain files (markdown,
> > restructured text, html), save new files + assets in new directory, ready
> > to be pushed onto a web server.  Everything self-contained and no need
> for
> > anything on the server side other than some sort of simple http server.
> >
> > This makes it really, really easy to develop or hack at the site locally,
> > and to check that it works easily.  The mockup and front page has been
> the
> > smallest part of the whole endeavor.  More involved was porting the old
> > site data, and getting Pelican to output in a similar (exact) type of
> > output that already exists on the site.
> >
> > Getting the input directory structure to output the same way required a
> bit
> > of hacking at a plugin on my side.  Once that was done, the source
> > directory structures would then be mimicked on the output side (expected
> > and same behavior as previous site).  So that now
> > "content/tutorials/test-tutorial/index.md + assets" would be located at
> "
> > gimp.org/tutorials/test-tutorial/index.html + assets".  Simple.
> >
> > A nice change from the previous site is that news/blog/article objects
> have
> > permalinked URL's, and are aggregated nicely on a simple "News" sub-page
> (
> > gimp.org/news).  This makes it easy to link/refer to news items
> > individually.  I just finished getting these to work as expected.
> >
> > At the moment, the front page is a static page that I will be working on
> to
> > fulfill the assumptions listed on the wiki page.  _Most_ of the static
> page
> > structure is ported, with the exception of a bunch of tutorials that I'm
> > slowly working through.
> >
> > If anyone is curious, I ran a listing of all of the old URL's from the
> > current site, and have been slowly going through and re-creating them in
> > the new infrastructure.  The list can be found here:
> >
> > http://static.gimp.org/about/meta/file-list.html
> >
> > That page can only exist because Michael was patient with my persistent
> > pestering to get the build requirements in place for Pelican.  So thank
> you
> > x100000000000 Michael.
> >
> > Speaking of which, the test site builds on a schedule, and can be
> accessed
> > here while I am working:
> >
> > http://static.gimp.org
> >
> > I have started a series of pages under the about/ section that deals with
> > this new site build and migration:
> >
> > http://static.gimp.org/about/meta/
> >
> > This gives further insight into what I've been doing, why, and how I'm
> > pretty sure I've screwed something up.  A hint: I've added a section at
> the
> > end of almost every page that lists all parent & children of that page.
> > This works well as a simple navigation method for pages that may not show
> > up on the nav bar at the moment.
> >
> > I'm not sure of the best way to solicit further comment/information on
> > this. I am fine going through the ML, which makes the most sense for
> those
> > already on it.  I _may_ also start a thread up on PIXLS.US for others to
> > chime in if they'd like.
> >
> > On that note, is there any thought/problems/advice on possibly hosting
> the
> > new site data on something like github for easier collaboration with
> > interested folks?  I don't mind managing this and acting as an
> > arbiter/filter for submissions.  It has at least the benefit of being a
> > little less scary than going through gnome, and adds at least a layer of
> > abstraction/safety from the repo.  I'm just not 100% of the best way to
> > keep github in sync with what we do on gimp-web-static, but can figure it
> > out I guess...
> >
> > Sorry this was so long!
> > pat
> > _______________________________________________
> > gimp-web-list mailing list
> > gimp-web-list gnome org
> > https://mail.gnome.org/mailman/listinfo/gimp-web-list