This adds the lstrip_blocks Jinja parameter and removes unnecessary
whitespace from a few notmyidea templates.
Note: The lstrip_blocks parameter requires Jinja 2.7+, which has been
noted in Pelican's setup.py.
Credit for this commit goes entirely to Russ Webber, who has earned my
eternal thanks for discovering and applying this useful Jinja parameter.
Refs #969
Using self.__dict__ is fine, but when its mutated it changes the
object's state. Creating a new dict avoids needing to think about
that, and doesn't introduce Python 3 issues (ie, where self.number is
accidentally set to '').
This commit adds optional fabfile.py generation during the
pelican-quickstart process. Reasons include:
* "make" is cumbersome to install on Windows
* Fabric runs in any Python environment
* fabfile is just Python and thus more flexible and extensible
This is an initial implementation and does not currently provide as many
upload options as its Makefile counterpart.
Refs #584.
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 DELETE_OUTPUT_DIRECTORY is set to True, all files and directories are
deleted from the output directory. There are, however, several reasons
one might want to retain certain files/directories and avoid their
deletion from the output directory. One such use case is version control
system data: a versioned output directory can facilitate deployment via
Heroku and/or allow the user to easily revert to a prior version of the
site without having to rely on regeneration via Pelican.
This change introduces the OUTPUT_RETENTION setting, a tuple of
filenames that will be preserved when the clean_output_dir function in
pelican.utils is run. Setting OUTPUT_RETENTION = (".hg", ".git") would,
for example, prevent the relevant VCS data from being deleted when the
output directory is cleaned.
The change to the "make clean" task in 764a2cf from "rm -rf" to instead
relying on GNU "find" appears to have broken cross-platform portability,
likely causing problems on *BSD and other platforms. This commit reverts
that change back to the previous "rm -rf" behavior.
This change removes the "clean" task from the "html" and "regenerate"
tasks in the default Makefile generated by pelican-quickstart. The
previous behavior ignored whether the DELETE_OUTPUT_DIRECTORY
setting was set to True or not and deleted everything in the output
directory every time the "make html" or "make regenerate" task was run.
In addition to violating the Principle of Least Astonishment, there was
also the potential for data loss if the user wasn't careful when
defining the output directory location in the Makefile.
The new behavior therefore relies primarily on the
DELETE_OUTPUT_DIRECTORY setting to control if and when the output
directory is cleaned. The default settings and Makefile generated by the
pelican-quickstart command, for example, no longer clean the output
directory when the "make html" task is run. If the user wants to change
this behavior and have the output directory cleaned on every "make html"
run, the recommended method would be to set DELETE_OUTPUT_DIRECTORY to
True in pelicanconf.py. Alternatively, the user can manually run "make
clean", with the caveat that the output directory and its contents will
be entirely destroyed, including any otherwise to-be-retained files or
folders specified in the OUTPUT_RETENTION setting. It is for that reason
that relying on the DELETE_OUTPUT_DIRECTORY setting is instead
recommended.
As before, DELETE_OUTPUT_DIRECTORY is set to True in the publishconf.py
settings file generated by the pelican-quickstart script. This way, any
potentially old and irrelevant files will be automatically removed
before the latest version of the site is transferred to the production
server environment.
In summary, this change allows for the sanest possible default settings,
while still allowing end users to customize output cleaning to their
preferred behavior with a minimum of confusion.
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.
