This cuts down on the remaining difference between static files and
articles/pages. The main difference is that path-based metadata is
now parsed for static content.
Instead of just being a base class, we can use it to parse static
files. It won't actually do any parsing, but we will get path
metadata extraction from read_file, and this will make the
StaticGenerator implementation simpler.
The old get_relative_path() implementation assumed os.sep == '/',
which doesn't hold on MS Windows. The new implementation uses
split_all() for a more general component count.
I added path_to_url(), because the:
'/'.join(split_all(path))
idiom was showing up in a number of cases, and it's easier to
understand what's going on when that reads:
path_to_url(path)
This will fix a number of places where I think paths and URLs were
conflated, and should improve MS Windows support.
From the Python docs for os.sep [1]:
Note that knowing this is not sufficient to be able to parse or
concatenate pathnames - use os.path.split() and os.path.join()...
Where I touched a line, I also changed double quoted string literals
to single quotes, since they are used more often in the source:
wking@mjolnir ~/src/pelican $ git grep "'" pelican/*.py | wc -l
683
wking@mjolnir ~/src/pelican $ git grep '"' pelican/*.py | wc -l
181
[1]: http://docs.python.org/3/library/os.html#os.sep
By using "//" instead of "http://" when referring to external resources
such as fonts (e.g., from within CSS files), warnings about "insecure"
content can be avoided.
Allows users to have per-year, per-month, and per-day archives of posts
automatically generated. The feature is disabled by default; to enable
it a user must supply format strings for a period's respective
`_SAVE_AS` setting.
Sometimes the base filename doesn't have everything you need.
Remember that os.sep is platform dependent, so using it in a regular
expression for this setting may not be portable (boo MS Windows!).
For easier re-use. I also extract the path metadata first, so
metadata explicitly listed in the file contents will take precedence
over metadata parsed from the filename.
I think the conversion from native paths to URLs is best put off until
we are actually trying to generate the URL. The old handling
(introduced in 2692586, Fixes#645 - Making cross-content linking
windows compatible, 2012-12-19) converted the path at StaticContent
initialization, which left you with a bogus StaticContent.src.
Once we drop the 'static' subdirectory, we will be able to drop the
`dest` and `url` parts from the StaticGenerator.generate_context()
handling, which will leave things looking a good deal cleaner than
they do now.
Static needs a lot of the same handling as other pages, so make it a
subclass of Page. The rename from StaticContent to Static makes for
cleaner configuration settings (STATIC_URL instead of
STATICCONTENT_URL).
All currently generated Static instances override the save_as
attribute explicitly on initialization, but it isn't hard to imagine
wanting to adjust STATIC file output based on metadata (e.g. extracted
from their source filename). With this union, the framework for
manipulating URLs and filenames is shared between all source file
types.
I discussed this option in the IRC channel, because I don't think it's
very clear. When I first read the list of options I was under the
impression that Pelican could do rewriting of urls. I discovered that
this isn't the case, so I discusses this in the IRC channel and got the
encouragement to submit a pull request.
