Why did I write another generator of static sites
First, I think I need to introduce myself. I am not a programmer, programming is more of a hobby for me, and from modern languages at the time of writing my bike I knew only Java Script (and a bit of Java). So, I’m not sharing programmer developments, but a look at the generators of static sites from the user side.
I had a website with little traffic and articles in the style of “me and my ... nice cat”, which I regularly updated. And, of course, I tried to fasten some CMS to it. At first it was a wiki engine, then something more blogging. With a little traffic and weak hosting resources, of course, I thought about translating the site to 100% static.
I was hoping to find a suitable generator, convert records from the database of the engine into files, and rejoice. But it was not there. Webgen was the first to come to hand, but the phrase “the source file may contain several blocks of text, for example, the main text and marginal text”, immediately turned away from it. It was important for me to separate content and presentation, and this approach did not suit me.
Then I tried almost everything that was “on the market”, and a list of important “not” began to form for me.
Many engines require a specific file name format, and perhaps 70% of all use the extension to indicate a simplified markup language (.md - Markdown, for example). The file name is just the identifier of this piece of data, do not put too much on it.
It’s more convenient for me to specify all the metadata in the same way, and the file header is suitable for this. Or a site configuration file. At this stage, for example, the beautiful Jekill fell away.
Why then in general a static site? In principle, making links like “/top-level/dir/file.html” is easier for programming, but this eliminates the possibility of viewing the site, say, from a flash drive. And it requires starting the server for preview. So I made the links relative to myself.
The site structure is just directories and files in them. The conclusion of the menu is the work of the template engine. A separate function for setting the menu, of course, can facilitate the creation of a template, but makes the process less flexible. Then many engines disappeared at once ...
It would seem simpler - you write a text file. I liked setting the metadata at the beginning in YAML format, but all this is great, as long as your native language is English. The interface of ordinary CMS is Russified, why when I switch to the generator of static sites I have to write:
It is, after all, ugly. On the other hand, it is better for the template engine to have unified names, so in my generator I made a translation from localized field names to internal ones.
At one time, I really liked the TAL language. Against this background, other template engines looked a bit poor, and, most importantly, TAL is the most friendly to the designer. In the process of developing a template, you can simply watch it in a browser, and “revitalizing” the finished one takes no more than half an hour. I even found a static site generator that uses TAL (PubTAL), but it’s a lot of blogging and ...
And even for a blog, “calendar” navigation is not very convenient (in my opinion). So I did not consider the engines organizing posts mainly by dates.
In my opinion, storing the code and source codes of a site in one directory is not good. There is an installation directory of the program, all plugins should go there, and only the configuration file for them should remain in the directory of the site. However, for some reason, this decision did not occur to all developers of such projects. In addition, I planned to launch more than one site on my engine, but to monitor, in fact, several installations of the program are too lazy for me.
Although the ability to add some site-specific code to the site’s directory that solves local problems, I added later, so as not to clutter the plugin’s directory with too “private” tasks.
Whatever programmer’s structure the site thinks, the user will want another. Therefore, in my opinion, all the features of the directory structure - both the source code and the finished site - to make customizable, and, if possible, arbitrary.
For example, categories and tags are inconvenient to paint in advance, at the same time, it is not difficult to do all the necessary work to generate them with a simple list of tags in the file header.
It is more likely “yes” than “not”, but still important. For example, if the tag “Cat” is assigned to one article, and “CAT” the other, they, of course, are listed under the same tag, but when the tags for a specific article are displayed, the spelling must be preserved.
It turned out that there would be no freebies, and any of the dozens of generators needed to be finished, or endured. So I thought that writing your bike would not complicate things too much. It just turned out to be a lot of free evenings ...
At first I tried to write in PHP because I thought that it would be nice to study it better for the web (I read it with a dictionary), but it didn’t work for me at all. He piled the first version on Pearl, then switched to the third Python. In a fully operational state, the generator spilled only somewhere in a year. Now on this generator has launched a working website.
Of the things that I (probably) myself have come up with, I will mention the user rules for transliterating tags (for simplicity, I use transliteration as a primitive "stemming"). That is, it seems to me a good idea if you can set the tags “game” and “games” to be accepted by the system as one and the same.
Here is an example of the source file:
Where did it go
I had a website with little traffic and articles in the style of “me and my ... nice cat”, which I regularly updated. And, of course, I tried to fasten some CMS to it. At first it was a wiki engine, then something more blogging. With a little traffic and weak hosting resources, of course, I thought about translating the site to 100% static.
And it started
I was hoping to find a suitable generator, convert records from the database of the engine into files, and rejoice. But it was not there. Webgen was the first to come to hand, but the phrase “the source file may contain several blocks of text, for example, the main text and marginal text”, immediately turned away from it. It was important for me to separate content and presentation, and this approach did not suit me.
"NOT"
Then I tried almost everything that was “on the market”, and a list of important “not” began to form for me.
File names should not affect the appearance of the site, as well as their extensions
Many engines require a specific file name format, and perhaps 70% of all use the extension to indicate a simplified markup language (.md - Markdown, for example). The file name is just the identifier of this piece of data, do not put too much on it.
It’s more convenient for me to specify all the metadata in the same way, and the file header is suitable for this. Or a site configuration file. At this stage, for example, the beautiful Jekill fell away.
The site should not require a server to view
Why then in general a static site? In principle, making links like “/top-level/dir/file.html” is easier for programming, but this eliminates the possibility of viewing the site, say, from a flash drive. And it requires starting the server for preview. So I made the links relative to myself.
The engine should not have the functions “menu”, “sidebar” and so on
The site structure is just directories and files in them. The conclusion of the menu is the work of the template engine. A separate function for setting the menu, of course, can facilitate the creation of a template, but makes the process less flexible. Then many engines disappeared at once ...
Creating an article should not be complicated. Not at all
It would seem simpler - you write a text file. I liked setting the metadata at the beginning in YAML format, but all this is great, as long as your native language is English. The interface of ordinary CMS is Russified, why when I switch to the generator of static sites I have to write:
title: В лесу родилась елочка
date: 01-01-2012
It is, after all, ugly. On the other hand, it is better for the template engine to have unified names, so in my generator I made a translation from localized field names to internal ones.
Simplified template engines are not needed
At one time, I really liked the TAL language. Against this background, other template engines looked a bit poor, and, most importantly, TAL is the most friendly to the designer. In the process of developing a template, you can simply watch it in a browser, and “revitalizing” the finished one takes no more than half an hour. I even found a static site generator that uses TAL (PubTAL), but it’s a lot of blogging and ...
Not Every Website Is A Blog
And even for a blog, “calendar” navigation is not very convenient (in my opinion). So I did not consider the engines organizing posts mainly by dates.
No need to interfere with code and text
In my opinion, storing the code and source codes of a site in one directory is not good. There is an installation directory of the program, all plugins should go there, and only the configuration file for them should remain in the directory of the site. However, for some reason, this decision did not occur to all developers of such projects. In addition, I planned to launch more than one site on my engine, but to monitor, in fact, several installations of the program are too lazy for me.
Although the ability to add some site-specific code to the site’s directory that solves local problems, I added later, so as not to clutter the plugin’s directory with too “private” tasks.
CMS developer should not come up with a site structure
Whatever programmer’s structure the site thinks, the user will want another. Therefore, in my opinion, all the features of the directory structure - both the source code and the finished site - to make customizable, and, if possible, arbitrary.
No need to do in advance what can be generated in the process
For example, categories and tags are inconvenient to paint in advance, at the same time, it is not difficult to do all the necessary work to generate them with a simple list of tags in the file header.
No need to think over for the user
It is more likely “yes” than “not”, but still important. For example, if the tag “Cat” is assigned to one article, and “CAT” the other, they, of course, are listed under the same tag, but when the tags for a specific article are displayed, the spelling must be preserved.
What happened
It turned out that there would be no freebies, and any of the dozens of generators needed to be finished, or endured. So I thought that writing your bike would not complicate things too much. It just turned out to be a lot of free evenings ...
At first I tried to write in PHP because I thought that it would be nice to study it better for the web (I read it with a dictionary), but it didn’t work for me at all. He piled the first version on Pearl, then switched to the third Python. In a fully operational state, the generator spilled only somewhere in a year. Now on this generator has launched a working website.
PS
Of the things that I (probably) myself have come up with, I will mention the user rules for transliterating tags (for simplicity, I use transliteration as a primitive "stemming"). That is, it seems to me a good idea if you can set the tags “game” and “games” to be accepted by the system as one and the same.
PPS
Here is an example of the source file:
Заголовок: Моя славная кошка
Дата: 2012/3/1 10:18
Метки: кошка, фотографии, веселые картинки
id: 115 #это я от фонаря написал
Это "выдержка" из статьи, используется при выводе списка статей. Строка, состоящая из дефисов
ниже отделяет ее от основного текста
---
Это основной текст статьи ... ссылка по id на какой-то файл