ARTICLE_ORDER_BY wasn't doing anything because the ArticlesGenerator
was sorting articles after ARTICLE_ORDER_BY was applied. This fixes
that by adding the ability to reverse metadata order by adding the
option prefix 'reversed-' to metadata and changing the default value
to 'reversed-date'.
Relevant documentation is also updated and moved into a more appropriate
place ('Ordering Content' instead of 'URL settings').
* remove content_object_init section from docs
* improve content_object_init test
The content_object_init signal used to set its class as sender and pass
the instance as additional arg in 6100773. Commit ed907b4 removed this
behaviour to bring it inline with other signals, on the basis that
you can test for the class of the object anyway.
We also had a test in place, checking this behaviour, but it was poorly
implemented, not actually checking if the function ever got called.
closes#1711
ref #1689
* set default settigns in settings.py to False for
- LOAD_CONTENT_CACHE
- CACHE_CONTENT
* remove AUTORELOAD_IGNORE_CACHE and add deprecation warning
* update settings.rst to reflect the new default values
* update test_cache to enable caching options
* break out cache into cache.py
* break out cache-tests into test_cache.py
* fix broken cache tests
* replace non existing assert calls with self.assertEqual
* fix path for page caching test (was invalid)
* cleanup test code
* restructure generate_context in Article and Path Generator
* destinguish between valid/invalid files correctly and cache accordingly
* use cPickle if available for increased performance
This requires a significant overhaul because we want to be able to have
IGNORE_FILES apply at every level of a recursively copied directory
(e.g. the theme static directory). Since I was overhauling it anyway
I changed it to use os.walk, which should be more efficient.
Idea borrowed from Docutils. This allows one to write author lists in
lastname,firstname format. The code change also means that readers with
fancy metadata that can natively represent lists (e.g. Docutils itself,
or MD-Yaml) don't have to merge 'em back together for process_metadata's
sake.
Adds exception type to the exception logging.
Removes the extra logging for autoreload in debug mode, since `raise`
will make it caught by the global `try/except` below and it'll be
logged there.
This replaces #1723 and also removes extra exception logging caused
in #1718.
This replaces all `http://` and `//:` links with `https:`. The protocol-
relative URL scheme is now deemed to be an anti-pattern. There are
security advantages to using HTTPS, and there are no significant
performance concerns.
In short, if the asset we need is available via HTTPS, then that asset
should always be loaded via HTTPS.
Fixes#1736
Main goal is to delay `slugify` call until `slug` is needed. `slugify`
can be expensive depending on the input string (see #1172). Changing it
to a property gives plugins time to place custom `slug`s before `name`
is unnecessarily slugified.
With this change, default behavior is same except the time slugification
happens. But if you set custom slug, `slugify` won't be used at all.
So, this is a partial solution to #1172. The rest, setting a custom slug,
would best be handled by a plugin.
* move all metadata tests to use a single function call (assertDictHasSubset)
* add tests for assertDictHasSubset
* correct some tests that iterated over metadata instead of expected metadata, resulting in metadata that was expected to be there but was not
* correct resulting broken tests
* add additional tests for EXTRA_PATH_METADATA
* make MdReaderTest fail if Markdown is not available instead of skipping each method individually
`fab serve` and `make devserver` use different HTTP Handlers and as a
result they behave differently. This makes sure `fab serve` also uses
the Handler defined in `pelican.server` in order to get rid of the
inconsistency.
Some metadata values cause problems when empty. For example, a markdown file
containing a Slug: line with no additional text causing Pelican to produce a
file named ".html" instead of generating a proper file name. Others, like
those created by a PATH_METADATA regex, must be preserved even if empty,
so things like PAGE_URL="filename{customvalue}.html" will always work.
Essentially, we want to discard empty metadata that we know will be useless
or problematic. This is better than raising an exception because (a) it
allows users to deliberately keep empty metadata in their source files for
filling in later, and (b) users shouldn't be forced to fix empty metadata
created by blog migration tools (see #1398).
The metadata processors are the ideal place to do this, because they know
the type of data they are handling and whether an empty value is wanted.
Unfortunately, they can't discard items, and neither can process_metadata(),
because their return values are always saved by calling code. We can't
safely change the calling code, because some of it lives in custom reader
classes out in the field, and we don't want to break those working systems.
Discarding empty values at the time of use isn't good enough, because that
still allows useless empty values in a source file to override configured
defaults.
My solution:
- When processing a list of values, a metadata processor will omit any
unwanted empty ones from the list it returns.
- When processing an entirely unwanted value, it will return something easily
identifiable that will pass through the reader code.
- When collecting the processed metadata, read_file() will filter out items
identified as unwanted.
These metadata are affected by this change:
author, authors, category, slug, status, tags.
I also removed a bit of now-superfluous code from generators.py that was
discarding empty authors at the time of use.
Otherwise, `RELATIVE_URLS` in the config file is ignored and
`RELATIVE_URLS` is set to `False` if `--relative-urls` is not
specified.
Fixes an issue introduced in #1592
