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