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