Articles from 1 to 4
Hi everyone, I just developed a new way to update my blog. I am just using my mailer (which is currently Thunderbird for a lack of a better alternative). As you may know, I already manage my own server. I have a nginx web server and my website is just plain old static pages generated from markdown using my own version of webgen.
My code is available at two locations:
I just developed a few scripts which does the following:
- hooked in /etc/aliases, receive e-mail from a special e-mail address. Put this mail in an inbox directory on the server
- another daemon (a shell script run by daemontools actually) run as the www-data user is monitoring the inbox using inotifywait. When a mail comes, or every 60 seconds, it process the mail using a ruby script that convert the mail to a markdown page, and run webgen on the website. It also commit and push the changes.
And that's all.
The one thing I couldn't automate is the creation of the private key to push the changes back to the git server.
All the code is there. I just don't know if I have a public URl for these repos :)
This website is made of static pages. I see two good reasons for that: first, there is no need to recompute endlessly the same information. Then, with static pages, you can leave your web site online forever without having it defaced.
So, how to create a modern web site with that? First, I have to start with what I want:
- A blog, with the recent posts on the front page
- An atom feed with the recent posts as well
- Older posts on other pages
- Each posts categorized in tags
- Each tag having a page with posts in it
- The tags pages must have atom feeds as well
- And tag pages must be splitted in pages
- Posts can have comments, anyone can add a comment
Some features can be easily provided:
- The atom feed can be created using a helper included in nanoc
- The tags can be easily crafted using page attributes.
- Tag pages can be created on the fly using a hand-made helper
- Pagination can be done the same way
Now, a word about design:
Pagination, this is frowned upon by the nanoc author as demonstrated on the guide:
First, a word of caution: I am not a fan of paginating items. Even though pagination is fairly easy to do in nanoc, I recommend not doing it, for one specific reason. Every time an object is added to a paginated collection, one object shifts from one page to the next. When a paginated page is bookmarked, it may show entirely different content a month later, and when a paginated page turns up as a result on a search engine, it may no longer contain the content that the person was looking for anymore. To avoid these issues, I recommend creating separate pages for each category, tag or year. Having said all this, I’ll nonetheless show you how to do pagination in nanoc, so you can get an idea of how it can be done.
In order to avoid having the object shifting pages, the most simple solution is to have the pages remain static. Say you want to have 10 items per page, the first page starts empty until it has 10 items. When an 11th item is added, a second page is created with one element. For blogs, it might seem to be in reverse order, but for archives, this is not a bad solution.
The pagination system must be uniform and available for any page on the website. This way, the index page and tag page can have the same pagination system. The pagination system must also support creating atom feeds. This way, we can have a feed for the whole blog and a feed per tag. In nanoc, this can be done using alternative representations for an item.
- Proxy the foreign resource on the local server. This unfortunately requires
mod_proxywhich is not available on my server.
- Another solution is to use Cross Origin Resource Sharing, a W3C recommendation that is still a draft unfortunately, but is started to be implemented.
- Or to use an iframe with a page of the foreign server, and use the postMessage method to communicate with it, for example with the easyXDM library.
- Or use HTML
<form>element to post the comment on the the API server. The server would then include the comment on the static page and publish it. This unfortunately requires a server with more than a simple php scripting ability. I don't have this.
For now, I am using the XmlHttpRequest solution with the CORS mechanism on the API server to allow communication. Here is where I'd like to move:
- First, integrate easyXDM for wider browser compatibility, at the cost of the design.
- Then, use a variation of the static HTML form.
For the static form, here is what i'm thinking of:
- First, the client can POST the form on the PAI server. If XmlHttpRequest with CORS is available, this can be done using Ajax, else we have to deal with a page reload.
- The server would store this message on the database with a unique UUID.
- Other clients can access this message accessing the API server as usual.
- Frequently, on my computer, I would dump the messages on the API server database and put them in a local yaml file. Comments i'd like to remove can then be removed here.
- The script that fetches comments would ignore received comments that are already present statically on the page, based on the UUID.
This way, comments would be available for everyone.
How does it work?
I have a php script somewhere that understand two methods:
GET will return all the posted objects associated with a tag passed as a REQUEST_URI (the thing after the question mark in URL)
POST will add an item to this series.
All of this in JSON of course, using jQuery.
Now, feel free to comment :)