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.
Sent from my iPhone
> On Aug 19, 2015, at 10:40 PM, Pat David <patda...@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.ah...@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 <patda...@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
>> > email@example.com
>> > https://mail.gnome.org/mailman/listinfo/gimp-web-list
gimp-web-list mailing list