when this project *wasn't* a SSG, it could serve up redirects, which is
something that was only rarely needed, and looking now, I don't do it at
all on any of my current sites, so I'm just going to remove the tiny bit
of code for it that remained in the SSG project
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
I have many things floating to the right on the ttrpg site, where the
first would be most right, the second would be right but left of the
first thing, and so on. this forces those to clear their respective side
and create a quasi-column of things rather than making a bizarre ratchet
of content.
.......... A
.......... A
.......... B
(good)
vs.
.......... A
........ B A
(bad)
I can't see why I'd want the bad behavior on my other sites, but I'll
just mention that I didn't check to see what they were doing
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
to aid viewing the raw markdown source in e.g. a gitlab source browser,
or to aid navigation in vim with "gf" style commands to jump between
files, allow the markdown source to specify foo.md or whatever/index.md
explicitly, yet generate the clean URLs for linking in the HTML output
this assumes that nginx is serving "foo" with foo.html, and "bar/" with
bar/index.html
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
the code meant to make symlinks relative to the output directory, but
only actually succeeded at it for targets in the root of the output
directory; since we already check that the target is not breaking out of
the instance, we can generate the output symlink relative to itself and
fix the subdirred-symlink behavior
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
os.chdir was getting confusing and hurting the log output, and
potentially the cause of a couple bugs left to fix, so this removes it,
but it means we need to pass around the pages/ absolute path into the
markdown parser, because it relies on knowing both the absolute path
now (to open files), and also the path relative to the pages dir in
order to know where to stop reading parent files/how to generate proper
URL-like references to other files.
probably this should be refactored at some point to inherit the pages/
path from the SSG somehow, rather than passing it through a bunch of
methods, but this seems to work for now
fixes#22
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
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>
they're just more static files among all the static files we serve, they
should go into pages/ like everything else
fixes#20
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this fixes stuff like og:urls of https://foo/./ or https://foo/./page
and also removes an extra layer of depth in the breadcrumb hierarchy,
just by suppressing the '.' in relpath output at the root of pages/
fixes#21
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 don't think there's any need for a million directories, on second
thought, so just put YYMMDD prefixed files in the feed/ directory
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this provides a somewhat unconfigurable (at the moment) feed module
which provides Atom and RSS feeds. entries are determined by symlinks to
content pages, because my core CMS usage is still more general and not
blog-like. the symlinks allow for arbitrarily adding entries as I see
fit.
this also moves core Markdown parser stuff to the library module, since
that's used by the feed as well as normal pages
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>
for some reason bandit wasn't earlier catching the SubElement usage but
now it is, but it's harmless anyway so we'll just suppress it.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
