Re: [Gimp-web] Update on New Site

Ok now I see the logic in this approach. This is just entirely new to me so I'm kind of lost. I guess I'll be 
able to help more once I look through how Pelican works and how the site is laid out a little more.

Kasim Ahmić

Sent from my iPhone

On Aug 19, 2015, at 10:40 PM, Pat David <patdavid gmail com> wrote:

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 

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:

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 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/ + assets" would be located at " + 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 (  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:

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:

I have started a series of pages under the about/ section that deals with
this new site build and migration:

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!
gimp-web-list mailing list
gimp-web-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]