Re: [Gimp-web] Update on New Site

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 <[email protected]> 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
> [email protected]
> https://mail.gnome.org/mailman/listinfo/gimp-web-list