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.
reST example of the section "Linking to internal content" had incorrect
metadata. Moreover, time was missing from the date of both markdown and
reST example.
This was pointed out by [lefromage at #pelican](https://botbot.me/freenode/pelican/msg/2235275/)
This makes it easier for StaticGenerator to walk FILES_TO_COPY, where
the input may be a directory or a bare filename.
Non-traversable file types (e.g. everything but directories and
symlinks to directories) are not checked against the exclude list.
The user-level effect of this is that explicit entries in STATIC_PATHS
or FILES_TO_COPY will override a hypothetical STATIC_EXCLUDES setting,
which seems like a reasonable approach.
I also removed the Python 2.5 compatibility check for `followlinks` in
os.walk, since Pelican is now Python >=2.7.
I noted that if you set the `ARTICLE_URL` site variable to have some depth and just create relative links, they will not link correctly.
by prefacing the link with `{{ SITEURL}}/` it seems to ensure proper links are created and works with the `make devserver` mode
I hacked some code from other modules and some quick googling, first time with py so this may need to be cleaned up.
The functionality is to have a config var in pythonconfig.py and to remove the duplicates `sorted(set())`
For sites where there are no SOCIAL links defined the FEED_ALL_ATOM and/or the FEED_ALL_RSS links are not displayed.
Also update the functional tests output.
These additions are to make it easier to disable pygments or any other
extension the user may not want. In the previous version, these plugins are
hardcoded, but by making it a variable in the config, it is possible to not use
pygments or easily load extra markdown plugins if needed; you can have multiple
plugins in one virtual environment and have different configs load them as
needed.
In my `pelicanconf.py` I then have the following:
MD_EXTENSIONS = ['extra', 'syntaxhighlighter']
where `syntaxhighlighter` is a custom markdown extension I am working on to use
syntax highlighter instead of pygments for code highlighting.
- if the output directory does not exist the 'make clean' command fails,
which also means that the 'make html' command which would otherwise
create the output directory also fails without generating the output
