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 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

On 08/19/2015 10:06 PM, Kasim Ahmic wrote:

you could get a simple, lightweight blogging engine like Chyrp

Written in PHP. And probably doesn't create a fully static site.

We already have Python running on the server, we want a static site, and we want the site content in a version control system.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

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 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 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 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

On Wed, Aug 19, 2015 at 07:15:58PM +0000, Pat David 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.

[...]

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

Very good work.

My only concern is about using markdown (see my other post and my little research:
https://github.com/ciampix/kicad-doc/tree/master/doc_alternatives), and BTW:

1) Pelican works with asciidoc too:

http://karanmalhi.blogspot.it/2014/03/how-to-setup-pelican-and-asciidoc.html

2) github (as you see by my link) render asciidoc nicely

my 2 cents

--

Marco Ciampa

I know a joke about UDP, but you might not get it.

+------------------------+ | GNU/Linux User #78271 |
| FSFE fellow #364 |
+------------------------+