Re: [Gimp-web] Update on New Site



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]