To minimize attack vectors and server resource requirements. We literally
have zero requirements for any server-side scripting, particularly during
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
> > 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
> > I made my initial notes, assumptions, and thoughts on the WGO Redesign
> > on the wiki: http://wiki.gimp.org/index.php?title=WGO_Redesign
> > That page contains thoughts and rationale behind using a static site,
> > 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
> > quickly (mostly because I am still fresh off of building pixls.us using
> > 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
> > 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
> > 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
> > 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
> > 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
> > fulfill the assumptions listed on the wiki page. _Most_ of the static
> > 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
> > x100000000000 Michael.
> > Speaking of which, the test site builds on a schedule, and can be
> > 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
> > 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
> > 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
> > 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
> > firstname.lastname@example.org
> > https://mail.gnome.org/mailman/listinfo/gimp-web-list
gimp-web-list mailing list