I think arguments that "Such new versions will be similar in spirit to
the present version", in my own reading and readings such as in
https://www.draketo.de/software/gpl-or-later, convince me for now that
it is acceptable to allow the "or later" for compatibility and future
problem's sake
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this removes Flask, reworks a number of library methods accordingly, and
adds generators and build commands to process the instance directory
(largely unchanged, except config.py is now config.json) and spit out
files suitable to be served by a web server such as Nginx.
there are probably some rough edges here, but overall this works.
also note, as this is no longer server software on a network, the
license has changed from AGPLv3 to GPLv3, and the "or any later version"
allowance has been removed
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
I will need the domain name for feed stuff, and I'm already crudely
using the title suffix in the nav as if it was a domain name, so let's just be
explicit in the case I ever change my mind on domain-in-title styling
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
moving this allows for per-instance customizations later, but that won't
be practical until serving styles from the instance dir is also allowed.
but, this sets the ground work and does allow for removing some styles
(e.g. if someone wanted to only allow 'plain').
also I still need to add the ability to present the themes list dynamically
I didn't like the other figure + figcaption parsers, they either assumed
a lot about usage (e.g. images only), or they were inline parsers that
either wrapped the figure in a paragraph tag (which is incorrect syntax)
or did span trickery (annoying)
so, this handles images and maybe other things, and does things properly
with figures as their own blocks. incomplete but it works with my
images, and should allow for looping (for multi-line content) in the
future?
the footnote extra expects to only parse one document over the Markup's
lifetime, and writes the footnotes to the bottom of every page that is
rendered (again assuming only one) with links back to the reference
having one parser for the entire app, naturally, introduced
ever-increasing footnote links and every footnote on the site showing up
on every page. this was not intended
in some light testing, doing this per-request has a nominal effect on
performance
