publication time and date and the last modified time and date
independently.
This makes it possible to access the last updated date with {{ article.locale_modified }} in templates.
Additionally, an already delivered feed entry can be corrected by changing the modified date and time, as it is used for atom:update
/ rss pubDate field now.
The `slugify()` function used by Pelican is in general very good at
coming up with something both readable and URL-safe. However, there are
a few specific cases where it causes conflicts. One that I've run into
is using the strings `C++` and `C` as tags, both of which transform to
the slug `c`. This commit adds an optional `SLUG_SUBSTITUTIONS` setting
which is a list of 2-tuples of substitutions to be carried out
case-insensitively just prior to stripping out non-alphanumeric
characters. This allows cases like `C++` to be transformed to `CPP` or
similar. This can also improve the readability of slugs.
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 dictionary is accessed by plugins (like `summary`) which add new
settings, so it should be public (i.e. no prefixed underscore).
The changed name length would have led to a re-indenting of the
default contents anyway, so I shifted them all to four spaces.
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.
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.
Making everything consistent is a bit awkward, since this is a
commonly used attribute, but I've done my best.
Reasons for not consolidating on `filename`:
* It is often used for the "basename" (last component in the path).
Using `source_path` makes it clear that this attribute can contain
multiple components.
Reasons for not consolidating on `filepath`:
* It is barely used in the Pelican source, and therefore easy to
change.
* `path` is more Pythonic. The only place `filepath` ever show up in
the documentation for `os`, `os.path`, and `shutil` is in the
`os.path.relpath` documentation [1].
Reasons for not consolidating on `path`:
* The Page elements have both a source (this attribute) and a
destination (.save_as). To avoid confusion for developers not aware
of this, make it painfully obvious that this attribute is for the
source. Explicit is better than implicit ;).
Where I was touching the line, I also updated the string formatting in
StaticGenerator.generate_output to use the forward compatible
'{}'.format() syntax.
[1]: http://docs.python.org/2/library/os.path.html#os.path.relpath
For reasons that are unclear to me, StaticContent introduces the
`filepath` attribute rather than using the existing (and semantically
equivalent) Page.filename. This has caused confusion before [1], and
it's probably a good idea to merge the two.
While I was touching the line, I also updated the string formatting in
StaticGenerator.generate_output to use the forward compatible
'{}'.format() syntax.
[1]: https://github.com/getpelican/pelican/issues/162#issuecomment-3000363
Python 2.7 chokes on Unicode locales:
$ python2.7
>>> import locale
>>> locale.setlocale(locale.LC_ALL, u'ja_JP.utf8')
Traceback (most recent call last):
...
ValueError: too many values to unpack
With the addition of:
from __future__ import unicode_literals
to tests/test_contents.py in:
commit bebb94c15b
Author: W. Trevor King <wking@tremily.us>
Date: Tue Jan 15 22:50:58 2013 -0500
test_contents.py: Add URLWrapper comparison tests
the locale strings in TestPage.test_datetime are interpreted as
Unicode. Rather than fixing the encoding there, this patch updates
Page to handle Unicode locales automatically.
There have been earlier attempts to sort categories and authors
[1,2,3], but they either sorted based on the object id [3], or only
sorted the main author and categories list.
This patch uses rich comparisons (keyed off URLWrapper.name, but
easily adjustable in subclasses) to make the objects sortable without
specifying a key for each sort. For example, now
{% for tag, articles in tags|sort %}
works as expected in a Jinja template.
The functools.total_ordering decorator fills in the missing rich
comparisons [4,5].
[1]: 877d454c8f
[2]: 7f36e0ed20
[3]: d0ec18f4db
[4]: http://docs.python.org/2/library/functools.html#functools.total_ordering
[5]: http://docs.python.org/3/library/functools.html#functools.total_ordering
I want to add `directory` metadata to each page in `content/pages/` to
place my non-article pages by hand:
PAGE_URL = '{directory}/{slug}'
PAGE_SAVE_AS = '{directory}/{slug}/index.html'
To do this, I need the `directory` metadata for formatting the URL.
This allows users to organize their files in ways where the subfolder name
would not make a good category name (i.e. /2012/09/). Set this to ``False``
and the subfolder will no longer be used as a standard category,
`DEFAULT_CATEGORY` will be used instead.
Reverted templates back to checking author object, since a None object is possible. Name could be checked for blank if required
ATOM spec states an author element should be provided, so passes a blank name if not specified
Updated unit test
