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
