Since PDF Generation is no longer a core feature, these settings are irrelevant. If the `pdf` plugin from pelican-plugins is used, it disregards the `PDF_GENERATOR` setting anyways.
There was an issue with static path watchers, where they were watching wrong paths.
They need to be prefixed with the 'content' path. So, they were not working at all.
It was also possible to overwrite default watchers like 'content', 'settings' and
'theme' by mistake if any of them were present in `STATIC_PATHS`. This is fixed
by adding a prefix to static watchers.
And static watchers were "too static", meaning, they stayed the same even if
`STATIC_PATHS` was changed in the settings during autoreload. Now static watchers
reflect those changes (i.e. new paths are added to watch list, and removed ones
are no longer watched).
This is helpful for mobile testing of Pelican sites by allowing
broadcasting on the local network. Using port 80 requires
running as root on most machines.
- Remove gratuitous Unixisms so that fabfile will work on Windows
- Docstrings for tasks so `fab --list` is more useful.
- Add `gh_pages` task for publishing to GitHub Pages
using [ghp-import](https://github.com/davisp/ghp-import)
Until now, making static files end up in the same output directory as an
article that links to them has been difficult, especially when the article's
output path is generated based on metadata. This changeset introduces the
{attach} link syntax, which works like the {filename} syntax, but also
overrides the static file's output path with the directory of the
linking document.
It also clarifies and expands the documentation on linking to internal content.
The old code was naively comparing the strings in PAGE_EXCLUDES to the
subdirectory names produced by os.walk(). (Same with ARTICLE_EXCLUDES.)
This had two surprising effects:
Setting PAGE_EXCLUDES=['foo'] would exclude all directories named foo,
regardless of whether they were in the top-level content directory or
nested deep within a directory whose contents should not be excluded.
Setting PAGE_EXCLUDES=['subdir/foo'] would never exclude any directories.
In other words, there is no way to exclude a subdirectory without risking
the accidental exclusion of other directories with the same name elsewhere
in the file system.
This change fixes the problem, so 'subdir/foo' and 'foo' will be distinct
and both work as expected. If anyone out there is depending on the old
behavior, they will have to update their settings. I don't expect it to
affect most users yet, since Pelican doesn't yet make nested directory
structures very useful. When it does, this fix will become important to
more people.
This change partially addresses issue #1019, by teaching Pelican to distinguish
between static files and content source files. A user can now safely add the
same directory to both STATIC_PATHS and PAGE_PATHS (or ARTICLE_PATHS). Pelican
will then process the content source files in that directory normally, and
treat the remaining files as static, without copying the raw content source
files to the output directory. (The OUTPUT_SOURCES setting still works.)
In other words, images and markdown/reST files can now safely live together.
To keep those files together in the generated site, STATIC_SAVE_AS and
PAGE_SAVE_AS (or ARTICLE_SAVE_AS) should point to the same output directory.
There are two new configuration settings:
STATIC_EXCLUDES=[] # This works just like PAGE_EXCLUDES and ARTICLE_EXCLUDES.
STATIC_EXCLUDE_SOURCES=True # Set this to False to get the old behavior.
Two small but noteworthy internal changes:
StaticGenerator now runs after all the other generators. This allows it to see
which files are meant to be processed by other generators, and avoid them.
Generators now include files that they fail to process (e.g. those with missing
mandatory metadata) along with all the other paths in context['filenames'].
This allows such files to be excluded from StaticGenerator's file list, so they
won't end up accidentally published. Since these files have no Content object,
their value in context['filenames'] is None. The code that uses that dict has
been updated accordingly.
Typogrify interferes with certain sections of the output that it should not touch (see #1407 for more details).
This feature adds a setting called TYPOGRIFY_IGNORE_LIST which is a list of tag for Typogrify to ignore.
The following was updated:
1. readers.py - if TYPOGRIFY_IGNORE_TAGS is present, then use it
2. settings.ps - default TYPOGRIFY_IGNORE_TAGS to []
3. contents/article_with_code_block.rst - an article with a code block for typogrify to ignore
4. updated tests
5. updated documentation
