I'd added them earlier to test that a configuration edit could
preserve the original output locations. However, it is likely that
you have quite a number of static files, and we shouldn't recommend
listing explicit paths for all of them. With this configuration
change, the pictures will be copied into the output directory using
their original relative path (e.g. `pictures/Fat_Cat.jpg` without the
`static`). Any |filename|-style links will be updated automatically.
If you *want* the pictures to end up in a `static` directory, it's
easier to just organize your source that way.
The broken code came from my 1d4d86c (settings: Rework the
LESS_GENERATOR removal warning for easy extension, 2013-03-24), where
I put formatting placeholders ({}) into the warning message, but
forgot to fill them in :/.
All paths should be relative to Generator.path unless we're actively
accessing the filesystem. This makes the argument less ambiguous, so
we have less likelyhood of joining paths multiple times.
In situations where I've cleared ARTICLE_DIR, I've done so to ensure
that there are no directories that will override the DEFAULT_CATEGORY
due to USE_FOLDER_AS_CATEGORY.
We no longer instantiate the Static object in the StaticGenerator, so
we can't set the save_as argument anymore. If you want to adjust the
output path, use the upcoming EXTRA_PATH_METADATA setting.
The assorted generators all use read_file() to read in the file
contents and metadata. Previously, they sometimes parse additional
metadata, fire off signals, and initialize a pelican.contents.Content
subclass on their own. We can reduce duplicated code and increase
consistency by shifting all that stuff into read_file() itself, and
this commit is a step in that direction.
We'll get better failure messages if we use an assertion method that
understands the comparison we're trying to make. If you make the
comparison by hand and assertTrue(), you don't get much constructive
feedback ;).
Support the forms listed by the W3C [1]. I also removed the
'%Y-%d-%m' form, which can be confused with the '%Y-%m-%d' ISO form.
The new ISO forms can use 'Z' to designate UTC or '[+-]HHMM' to
specify offsets from UTC. Other time zone designators are not
supported.
The '%z' directive has only been supported since Python 3.2 [2], so if
you're running Pelican on Python 2.7, you're stuck with 'Z' for UTC.
Conveniently, we get ValueErrors for both invalid directives and
data/format missmatches, so we don't need special handling for the 2.7
case inside get_date().
[1]: http://www.w3.org/TR/NOTE-datetime
[2]: http://bugs.python.org/issue6641
If a setting exists in DEFAULT_CONFIG, assume it will be there
(instead of checking and/or providing a local default). The earlier
code was split between the two idioms, which was confusing.
This avoids harcoding test-specific overrides, and makes it easy to
setup a settings dictionary based on DEFAULT_CONFIG for testing.
Because you can trust Pelican to use settings based on DEFAULT_CONFIG,
you are free to go about using:
settings[my_key]
instead of:
settings.get(my_key, some_fallback)
or:
if my_key in settings:
...
if you know that `my_key` is in DEFAULT_CONFIG.
Setting migration is something that will happen for multiple settings,
and the more we can standardize the reporting procedure, the easier it
will be to add new warnings.
