Making This Site (Part III)

Published on: 2020-10-18

It's been a bit busy recently but, now, I return to the blogosphere mainly as an escape from the insanity of modern life!

There are a few things that I'm keen to solve, which I must admit I've not found intuitive to get my head round in Lektor just yet. I've not tried hard, but definitely if it's not immediately intuitive (or is outstanding from part 1 or part 2) then I fancy having a crack at wrapping it up in this post. At least from the website point of view.

The final post will focus on the underlying Ansible provisoning I've put in place which, to be honest, I'm hoping others might benefit from. Anyway, the remainder of this post will focus on what I consider to be the final bits required to make this a usable site!

Querying the project settings from Lektor in templates

Data bags are in fact the manner by which to approach this, but you can query the core site settings too. This was an outstanding thing I wanted to find the solution too, it's just about RTFM :-)

Site settings

This really did baffle me a little bit, though in the end it was quite trivial:

{{ config.PROJECT.url }}

Will pull the url out of the project group in the lektorproject file for the site. This was clearly spelled out on this documentation page so no criticism there! What I don't really understand is the uppercasing of configuration groups, and of course that wasn't documented. One day I'll figure out why that is.

Data bags, and considering "dev" alternate data

Data bags turn out to be the other very useful element of Lektor. I configure the comments settings (see the next section) using these INI based configuration settings. That, coupled with the above finishing of looking up project settings, is awesome.

One thing that has made me think is that there is no accounting for alternate settings when, for example, you're using lektor serve to view/edit the site. Therefore when using comments it'd be great to be able to alter the endpoint, which of course is contained in the static HTML as you might expect.

What I'd like to be able to do is use lektor deploy to dynamically either:

• index different databags on deployment for the output files from a command line setting
• allow execution of arbitrary build actions with the static file generation from the command line

This might seem odd, but I noticed with Isso that I really wanted the dev, staging and production instances to point at their respective Isso backends. Unfortunately that does not seem possible because the data is not obviously easy to reference based on the deployment/serving environment.

Comments with Isso

This I thought would be much more of a mission than it's ended up being, but actually I really rate the Isso project. It's simple and unintrusive, and it's nice to know that I'm not feeding peoples data to an external party.

I think there's an entire article able to be devoted to this, an Isso role for ansible has been created as part of the provisioning setup I use to build out the VPS. So the provisioning article will start me off on that one! :-P

All of this needs a bit more documentation, so please forgive how messy those links look! I also don't think the mail subsystem for isso is playing nicely with Postfix yet. For the moment, here's the macro, and that's really all you need for the frontend!

    <script data-isso="{{ bag('comments.url') }}"
            data-isso-vote-levels="true"
            src="{{ '/static/js/embed.min.js'|url }}"></script>
    <section id="isso-thread"></section>

Image Gallery

This was fun. Again maybe a little article on its own. Basically I wanted to start the process of sharing the amazing Antarctic experiences I am privileged to have, and hopefully continue having, as a result of my work.

I have a lot of love for the lightSlider and lightGallery projects. :-)

As with Isso, the galleries are all about taking advantage of Lektors captioning (via attachments) and thumbnailing capabilities with a nice and simple macro:

{% macro render_gallery(item, id="gallery", title="Photos") %}
  <ul id="{{ id }}">
    {% for image in item.attachments.images|list|sort(attribute='path') %}
    <li data-thumb="{{ image.thumbnail(300) }}"
        data-src="{{ image|url }}"
        data-sub-html="{{ image.caption }}">
        <img src="{{ image.thumbnail(300) }}" alt="{{ image.caption }}">
    </li>
    {% endfor %}
  </ul>
  <script language="javascript">
    $(document).ready(function() {
      $('#gallery').lightSlider({
          mode: "slide",
          thumbItem: 6,
          currentPagerPosition:'left',
          controls: true,
          pager: true,
          loop: true,
          auto: true,
          speed: 800,
          enableTouch: false,
          enableDrag: false,
          onSliderLoad: function(el) {
            el.lightGallery({
              selector: '#{{ id }} .lslide'
            });
          }
      });
    });
  </script>
{% endmacro %}

Issue with Relative Links

So this does not work:

[Next post in this series...](/blog/making-this-site-ii)

But this does:

[part 1][1]
...
[1]: /blog/making-this-site/

The former is the case for the original post in this series (which at the moment has the FQ URI associated), the latter is used in this article. In the first case I use .../blog/blog/... which is a bit odd. Removing blog doesn't work, I end up with no blogs at all!

I need to look into this more, but if you suffer the same problem, use the second option... :-)

Issue with cache not responding to macro changes

Another thing I've noticed is that updating HTML macro files in the templates/macros directory does not trigger caching. Another thing to have a look into on my part, but do let me know if you've noticed something similar!

Conclusion

Most of the items in this article were the items I thought needed sorting out prior to offering the site out for people to view. Obviously it's indexable by search engines and wotnot, but I might push this out somewhere as I hope some of my experiences and write ups will help someone at some point! I didn't want to do that until people could look at some pictures and/or comment on things.

You may ask about the backend. Well, the provisioning is going to be a future write up. Analytics are not my bag. I don't want people to visit the site and worry about whether it's another vector for their browser information to be ingested.

I'm certain there's nothing on here or any analysis being done that compromises peoples privacy. I intend it to stay that way.

Ultimately, Lektor has more than proven it's worth. The fact it's so easy to write this with a beer is the only reason I ever do. Hopefully, this is the start of much more in spite of lifes distractions. I'm looking forward to writing about the provisioning system I use, one of many I've developed/worked on.

I'm also keen to write a bit more about what I do during 95% of the time, when I'm not drinking beer (which is when I work on this site.) :-P