Previously, if you had a '/' or some other character recognized by sed
as a special regex character in the title or description of a page, that
page would fail to build. This adds a couple lines that runs those bits
of text through a separate sed command to escape any such special
characters and prevent those issues.
The title and description variables were not being unset before each
invocation of the build() function so pages would have incorrect titles
and descriptions, since those variables would only be set if they were
not already set (from a Gemini conversion).
If a gemini link points to a .jpeg, .jpg, or .png file, translate that
link into a Markdown-style image link (i.e. a link with a ! preceding
it) so that it will be compiled into an <img> tag for better viewing in
web browsers.
These changes allow one to build a page without having to go back up to
the root directory of the website. This should reduce deployment
friction when quickly iterating on a page or series of pages.
According to the gemtext specification, it's completely fine for there
to be zero or any number of spaces between the '=>' that denotes a link
and the following URL. This change allows that, instead of assuming
there will always be just one space after the '=>'.
Previously, if a Gemini link did not have a label, then sbs would skip
converting it to a Markdown-style link. For example:
=> /this/is/a/link.gmi
would not get converted whereas:
=> /this/is/a/link.gmi Link
would get converted. Since the label is optional according to the
gemtext specification, we need to support these situations.
If a link was something like:
=> git.gmi A Page About Git
Then sbs wouldn't convert the link to "git.html" since it was looking
for links that had a leading slash.
sbs can now convert gemtext to markdown which allows mixing gemini and
markdown in the same site directory and easy publishing of gemini
content for the web.
A modification of the build command was also added to allow building the
entire site without specifying any paths.
Embedded content type was set to `text` when it should have been `html`
to tell clients that HTML was the format of the embedded content. It was
previously `text` because either the documentation for Atom feeds
(https://validator.w3.org/feed/docs/atom.html#text) is terrible or all
the clients do their own thing when it comes to parsing content.
Links to content weren't being properly munged so links included
`/content/blog` instead of just `/blog` and that resulted in broken
links.
Config parsing was done too early so the code had to be refactored to
allow new site and post creation without worrying about the contents of
the config file since neither of them depend on it.