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 guess this proves that the old structure still works with the new
code, though it creates IDs that have the file path in them
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>
