Skip to main content

Ralsina.Me — Roberto Alsina's website

Posts about nikola (old posts, page 13)

Nikola Themes Repo is Now Official

As of 1 minute ago, Niko­la github mas­ter's "in­stal­l_the­me" com­mand pulls themes from http://themes.niko­la.ralsi­na.me

So, sud­den­ly, in­stead of 2 themes for down­load, you have ~65 (although of course, most of them are bootswatch vari­a­tions in 2 themes, jin­ja-de­fault looks ex­act­ly like de­fault, and or­phan is use­less ;-)

And you can con­trib­ute themes now!

How?

  1. Give me a pull re­quest at http­s://github.­­com/get­niko­la/niko­la-themes

    All you have to do is add your theme in themes/ and pull re­quest.

  2. Send me a zip of your theme and I'll do it.

Con­tribut­ing themes will take a while be­cause the theme has to be ex­am­ined for ma­li­cious code in the tem­plates, but I will process them, slow­ly but sure­ly. If you have sent me a theme in the past and I have not done it, I am ter­ri­bly sor­ry and hope you can find it in you to try one more time :-)

The themes site it­self is not ex­act­ly awe­some, but it is func­tion­al, and you can get themes from there too, and see de­mo sites for each the­me, and even look at au­to­gen­er­at­ed screen­shots (which sad­ly don't show web­fonts)

MinCSS is amazing

I had this is­sue open in the bug track­er for Niko­la (my stat­ic site gen­er­a­tor) for a long time: "Add minc­ss sup­port­".

Well, no, it does­n't have it yet, but I did some re­search on whether it would be worth adding. And boy, minc­ss im­pressed the heck out of me.

You see, Niko­la's themes tend to use unadul­tered boot­strap, which means they car­ry a large num­ber of things that are not used in their CSS. Be­sides, it us­es sev­er­al stylesheets from do­cu­til­s, pyg­ments, and more.

What minc­ss does is ex­am­ine your HTML and your CSS, and re­move all the un­used CSS. So, I wrote a script that ex­am­ines the Niko­la out­put and over­writes the CSS files with the min­i­mal things that are ac­tu­al­ly need­ed there.

And the re­sult?

Here is the be­fore/after for each CSS file in Niko­la's de­mo site:

bootstrap-responsive.min.css  16849  3251
bootstrap.min.css            106059 14737
code.css                       3670  2114
colorbox.css                   6457   774
rst.css                        6559  2581
theme.css                      1287  1061
-----------------------------------------
                             140881 24518

But wait, Niko­la sup­ports bundling all those files in­to a sin­gle large CSS file to avoid net­work re­quests (us­ing we­bas­sets). Does it work in that case too?

Well yes:

all-nocdn.css                167457 29496

But that is not al­l. The minc­ss files are not mini­fied. Pass­ing al­l-nocd­n.c­ss through Yui-­com­pres­sor shrinks it fur­ther to 20599 bytes. Which, gzipped, is a pal­try 4801 bytes. That means the com­plete styling of the whole site is a sin­gle CSS file less than 5KB in size.

That, is im­pres­sive.

(Re)Introducing Alva, a Nikola Server

Over a year ago (time flies!) I post­ed some­thing about a project called Al­va. Let me quote my­self:

Al­va is al­most the op­po­site of Niko­la. If Niko­la is about mak­ing stat­ic sites, Al­va is a dy­nam­ic site. How­ev­er, as Hegel sug­gest­s, from the the­sis and the an­tithe­sis comes the syn­the­sis.

So, Al­va is about dy­nam­i­cal­ly cre­at­ing stat­ic sites. If you want to have Niko­la in your serv­er in­stead of in your own com­put­er, and have the con­ve­nience of an on­line tool, that's the niche Al­va tries to fil­l.

So, you would in­stall Al­va, and use it like any oth­er we­b-based blog­ging tool. Yet, be­hind the sce­nes, you would have Niko­la, and all the per­for­mance and se­cu­ri­ty ben­e­fits of stat­ic sites.

And maybe some­day, I (or some­one) will put up a mul­ti­-us­er ver­sion of Al­va, and you will be able to get host­ed blogs, know­ing all the da­ta is yours and you can leave any­time and do your own thing.

The ap­proach I was tak­ing at the time proved to be un­suc­cess­ful, and there were a few oth­er fail­ures along the way. Of course, the prob­lem was in how I was ap­proach­ing the task. So I did the right thing, and learned how to do it "right".

Still not us­able, still not host­ed any­where, but al­ready semi-­func­tion­al: Al­va lives now

There's a lot of work still to be done. But I now know how to do it. To pre­vent the usu­al ar­gu­ments, here is a lit­tle ex­pla­na­tion of mo­ti­va­tion, tool­ing, etc.

Motivation

I want a way to host blogs very cheap­ly. How cheap­ly? I want at least 1000 rea­son­ably ac­tive users in a $5 VP­S. That would make Al­va a rea­son­able al­ter­na­tive to host­ed mul­ti­-us­er word­press, which means it would be a rea­son­able so­lu­tion (if set­up is easy enough) for smal­l­-­to-medi­um or­ga­ni­za­tions which don't want to set­up ex­pen­sive in­fra­struc­ture yet want to own their da­ta (think school­s, small busi­ness­es, FLOSS pro­ject­s, etc.) I al­so want to pro­vide that ser­vice, for free. Which is why an­oth­er rea­son I want it to be su­per cheap.

How does Al­va help pro­vide this su­per-cheap blog host­ing?

  1. It needs to scale fol­low­ing the num­ber of ed­its not views.

  2. If it gets too busy with ed­it­s, changes take longer to ap­­pear, but the site it­­self does­n't get any slow­er.

  3. Ed­it­ing and serv­ing can be pro­vid­ed by sep­a­rate ser­vices, so I can use some su­per-­­fast stat­ic file serv­er and a su­per-­­con­­fig­urable WS­­GI de­­ploy­­men­t.

  4. In­­di­vid­u­al pages can be heav­i­­ly op­ti­mized so that they down­load fast

Tools

One of the guid­ing prin­ci­ples here is that to de­liv­er this sort of thing, in my spare time, the de­vel­op­ment process needs to be stingy with the most lim­it­ed re­source: me. I can't spend a lot of me here. I need to be care­ful and not over-promise.

So, when­ev­er there was a 3rd-­par­ty tool that saves a sig­nif­i­cant amount of time, that's what I am us­ing.

Django

Be­cause it has a much stronger 3rd-­par­ty toolset than Flask or any mi­cro-frame­work. For ex­am­ple, the Flask equiv­a­lent of djan­go-al­lauth broke my will to live. Be­cause the ad­min in­ter­face means I can start adding da­ta to see if it makes sense be­fore I write all the re­quired views.

Django-allauth

Be­cause I don't want you to have to cre­ate ac­counts here un­less you want to, this pro­vides (op­tion­al) so­cial lo­gin and reg­is­tra­tion. This was easy to set­up and works alm­sost out­-of-the-box

Bootstrap and Django-bootstrap-toolkit

Niko­la is al­ready heav­i­ly in­vest­ed in boot­strap, so it just made sense to go fur­ther down that road. I un­der­stand boot­strap, and djan­go-­boos­t­rap-­toolk­it is easy enough (although I can't make their datepick­er work)

Django-datetime-widget

Be­cause fight­ing is bor­ing.

Django-debug-toolbar

Be­cause Djan­go's mech­a­nisms to find tem­plates and stat­ic files are many and con­fuse me.

Redis + RQ + django-rq

It's crucial for the whole approach to use job queues in order to detach the rendering from the actual Django app. This combination makes job dispatching ridiculously easy, setup is trivial (install everything, start redis, a few lines of config, ./manage.py rqworker and off you go) and they provide a django admin page where I can see the failed jobs, which is awesome.

South

Be­cause it's easy enough, and al­lows me some free­dom ex­plor­ing da­ta or­ga­ni­za­tion in my mod­els with­out com­mit­ting to it for­ev­er or recre­at­ing data­bases with test da­ta all the time.

Gatling

I will prob­a­bly serve the gen­er­at­ed sites via gatling just like my cur­rent sites be­cause it has the sim­plest named do­main con­fig­u­ra­tion pos­si­ble, it's fast and very light in re­source us­age.

Markitup

A cool, sim­ple ed­i­tor with live pre­views that sup­ports al­most ev­ery markup. Not WYSI­WYG or even WYSI­WYM so pos­si­bly I will have to add an al­ter­na­tive. I start­ed us­ing djan­go-­mark­it­up but it's not a good idea (it us­es a old ver­sion of mark­it­up which re­quires JQuery < 1.9) and am in the process of just us­ing Mark­it­up man­u­al­ly.

So, feel free to give Al­va a try and/or give me a hand, com­ments wel­come.

Here's a very big gun, there's your foot: PHP support in Nikola

I am a very big pro­po­nent of stat­ic site gen­er­a­tors. I would not have both­ered writ­ing Niko­la oth­er­wise. But there is al­ways that feel­ing that maybe there is some lit­tle thing which is hard to im­ple­men­t, like a con­tact for­m.

And let's face it, the eas­i­est way to solve some of those things is by stick­ing a few lines of PHP in your HTM­L.

So, if you re­al­ly want to, you can do it. I think Niko­la (github mas­ter) is the first stat­ic site gen­er­a­tor that sup­ports php code. Here's how:

  1. Add php to your page_­com­pil­ers (be­cause I will nev­er put it there by de­fault­):

    post_compilers = {
        "rest": ('.txt', '.rst'),
        "markdown": ('.md', '.mdown', '.markdown'),
        "textile": ('.textile',),
        "txt2tags": ('.t2t',),
        "bbcode": ('.bb',),
        "wiki": ('.wiki',),
        "ipynb": ('.ipynb',),
        "html": ('.html', '.htm'),
        "php": ('.php'),
    }
  2. Add php posts or pages to your post_­pages:

    post_pages = (
        ("posts/*.txt", "posts", "post.tmpl", True),
        ("posts/*.php", "posts", "post.tmpl", True),
        ("stories/*.txt", "stories", "story.tmpl", False),
        ("stories/*.php", "stories", "story.tmpl", False),
    )
  3. Cre­ate a php post:

    nikola new_post posts/foo.php
  4. Put php in there:

    <!--
    .. date: 2013/04/16 09:57:09
    .. title: php test
    .. slug: foo
    -->
    
    <?php
    Print "Hello, World!";
    ?>

Build the site as usu­al, and you should end up with a page with PHP ex­ten­sion, that has that PHP in the "con­tent" area, so it will fol­low your site's theme. Of course you can't do things like add HTTP head­ers and such, but hey, read the ti­tle.

Nikola version 5.4.4 is out!

Yes, ver­sion 5.4.4 of Niko­la, my stat­ic site/blog gen­er­a­tor is just pub­lished at the usu­al place, in­clud­ing the fol­low­ing im­prove­ments:

Features

  • New Ja­­pa­­nese tran­s­la­­tion.

  • Niko­la check ex­ists with 1 if there is an er­ror

  • New HIDE_UN­­TRAN­S­LAT­ED_­­POSTS op­­tion that en­­sures you don't have mixed-lan­guage pages (Is­­sue #373)

  • New theme "site-­­plan­e­­toid" for use with the plan­e­­toid plug­in.

  • New 're­tired' tag for posts that should no longer be in feed­s.

Bugfixes

  • Added post da­­ta as a up­­­to­­date check for mus­­tache (Is­­sue #456)

  • Re­build post pages when the post's tran­s­la­­tion list changes (Is­­sue #458)

  • Han­­dle "-h" (Is­­sue #460)

  • Added cor­rect help for con­­sole com­­mand (Is­­sue #460)

  • Es­­­cape twit­ter­­card da­­ta (Is­­sue #452)

  • Added mis­s­ing "twit­ter­­card" in sto­ry tem­­plate

  • Added sup­­port for per-lan­guage tags (Is­­sue #450)

  • Fix wrong path split­t­ing (Is­­sue #434)

  • Re­mem­ber lo­­cale even when set_lo­­cale failes (Is­­sue #446)

  • De­­code path ar­gu­­ment in new_­­post (Is­­sue #442)

  • task_in­dex­es had mis­s­ing con­­fig de­pen­­den­­cies (Is­­sue #441)

  • Re­­moved bo­­gus links to slides as­sets that were re­­moved

  • Com­­pressed files were seen as un­­known by "niko­la check"

  • lo­­cal search and mus­­tache plug­ins must be dis­­abled by de­­fault (Is­­sue #437)

  • Avoid fail­ure if there are no tags and USE_GZIP is en­abled (Is­­sue #439)

  • Fix as­pect ra­­tio de­tec­­tion in Vimeo videos (Is­­sue #440)

  • Blog­ger im­­porter was pass­ing wrong op­­tions to "niko­la init" (Is­­sue #408)


Contents © 2000-2020 Roberto Alsina