"U" mode is redundant in py3 since "newline" argument replaces it and by default
universal newlines is enabled. As of py3.4, "U" mode triggers a deprecation warning.
On OSX, if LC_TIME and LC_CTYPE differs the output of strftime is not properly decoded
in Python 3. This makes sure that the 'utils.DateFormatter' and the related Jinja filter
'strftime' set the same value for LC_TIME and LC_CTYPE while formatting.
Also, '%a' is removed from DEFAULT_DATE_FORMAT in 'custom_locale' tests. OSX and *nix have
different conversions for '%a' ('Jeu' vs 'jeu.') and there is not a feasible way to handle
the difference for tests.
reverts getpelican/pelican@ddcccfeaa9
If one used a locale that made use of unicode characters (like fr_FR.UTF-8)
the files on disk would be in correct locale while links would be to C.
Uses a SafeDatetime class that works with unicode format strigns
by using custom strftime to prevent ascii decoding errors with Python2.
Also added unicode decoding for the calendar module to fix period
archives.
The reader would return a list of authors already, but
METADATA_PROCESSORS['authors'] expects a string.
Added a test case for this (only the HTMLReader had it).
Instead of one path a list can be given. This is due to popular request.
Should help people not wanting to use Pelican for blogging.
Maintain backward compatibility though.
Thanks to @ingwinlu for pointing out the change in StaticGenerator.
The "Getting Started" docs became overly long and unwieldy over time.
This splits it into separate sections, including:
* Quickstart
* Installation
* Writing content
* Publish your site
The Content.__eq__ method would indirectly call _update_content too
soon, resulting in failed intrasite links substitution
This effectively reverts fd77926700
for pelican/contents.py, it was unnecessary anyways.
Thanks to Strom for finding this.
CACHE_PATH can now be relative to settings file like OUTPUT_PATH.
Also add --cache-path commandline option.
Change cache loading warning to a less scary and more helpful message.
For some reason, setting names on the Settings page have long been
wrapped in single back-ticks (usually meant for linking in reST) instead
of double back-ticks (meant for denoting code). This seems to be
widespread throughout the docs, and it's not clear if this is
intentional or simply a reST formatting error that got propagated by
others in order to stay consistent. This commit applies double
back-ticks in any case where something resembling code is shown, with
the idea that single back-ticks should only be used when linking.
More importantly, the settings denoted their default values in
parentheses, which hapless users often included when copying and pasting
these values into their config files. As one can imagine, confusion —
not hilarity — ensued. Setting defaults are now shown as they would
actually appear in one's settings file, with an equal sign and without
parentheses.
During this spelunking expedition, many other minor improvements were
concurrently conducted.
Because Pelican always rewrites all output, the mtimes always change, so
rsync would always transfer all the files which defeats the purpose of
rsync. The '-c' option (--checksum) compares the checksums rather than
mtimes.
This is a reworked and improved version of content caching.
Notable changes:
- by default only raw content and metadata returned by readers are
cached which should prevent conficts with plugins, the speed benefit
of content objects caching is not very big with a simple setup
- renamed --full-rebuild to --ignore-cache
- added more elaborate logging to caching code
Previously, the error returned by Python when docutils is not installed
was not explicit, instead saying that HTMLTranslator is not defined
(needed by FeedGenerator and such), forcing the user to go into
readers.py to figure out that this happens because "import docutils"
failed.
This pull request makes the docutils dependency explicit, so that there
is an ImportError if doctutils is not found.
The _cache_open attribute of the FileDataCacher class was not set when
settings[load_policy_key] was not True, so saving later failed.
As a precaution, replaced the `if ...: return` style with a plain
if structure to prevent such readability issues and added tests.
The locale is a global state, and it was not properly reset to
whatever it was before the unitttest possibly changed it.
This is now fixed.
Not restoring the locale led to weird issues: depending on
the order chosen by "python -m unittest discover" to run
the unit tests, some tests would apparently randomly fail
due to the locale not being what was expected.
For example, test_period_in_timeperiod_archive would
call mock('posts/1970/ 1月/index.html',...) instead of
expected mock('posts/1970/Jan/index.html',...) and fail.
Under python 2, with non-ascii locales, u"{:%b}".format(date) can raise UnicodeDecodeError
because u"{:%b}".format(date) will call date.__format__(u"%b"), which will return a byte string
and not a unicode string.
eg:
locale.setlocale(locale.LC_ALL, 'ja_JP.utf8')
date.__format__(u"%b") == '12\xe6\x9c\x88' # True
This commit catches UnicodeDecodeError and calls date.__format__() with byte strings instead
of characters, since it to work with character strings
