- checking text against google natural language api: the strict classification it offers is better, than free folksonomy, if I ever want to connect entries based on topic
unfortunately they don't support Hungarian yet.
The short summary is that while I still sort of believe in what GPL stands for, reality is not that simple to immediately open source everything.
Because GPL is scary, many people avoid it, and one of the main achievements of open source should be that nobody has to reinvent the wheel.
- fixing google disagreements on what is needed in a hatom/hentry
- adding a bit of invisible contact information in json-ld to see if anything picks it up
- fixing border issue in menu css
- removed the abomination experiment (aka microdata)
- added svg source icomoon for the possibility to extend later
- rsync moved into nasg.py itself, so the ordering of render - sync - webmentions is ok
- fixed gone_re php regexes
- better nav header layout
- follow page instead of direct RSS link
- logger in settings for nasg instead of direct logging
- prism.js only for articles with language code blocks
- added webmention.io webhook to email template
So, Python Markdown is a bottomless pit of horrors, including crippling parsing bugs,
random out of nowhere, lack of features. It's definitely much faster, than
Pandoc, but Pandoc doesn't go full retard where there's a regex in a fenced code block,
that happens to be a regex for markdown elements.
Also added some ugly post string replacements to make Pandoc fenced code output work
with Prism:
instead of the Pandoc <pre class="codelang"><code>, Prism wants
<pre><code class="language-codelang>, so I added a regex sub, because it's 00:32.
While Pandoc was generating something sane, the output of CodeHilite puts silly amount of extra text and makes the HTML output completely unreadable.
In the end, it still looks like prism.js is a nice and solid solution, even if it's JS.
I'll explore other options, but so far, it's either back to Pandoc, or sticking with Prism.
for the search functionality, it's better to keep this contained instead of
adding one more black magic (eg. nginx rules)
Note: I've sort of exhausted client-side JS search options; the smallest index
I was able to build was still a few megabytes, way to large for my taste, hence
the SQLite FTS4 python + PHP solution. Yes, it's ugly, but it works, and PHP
is available nearly everywhere. Nearly.
Without something that can set headers properly, it's impossible to do real
HTTP 410 Gone, and even HTTP 301 or 302, so it's very likely I'm stuck with the
minimal PHP solution.
