This commit adds documentation to the getting started guide which describes that
articles must contain a manually set 'date' metadata attribute unless the
DEFAULT_DATE setting is specified.
This fixes some incorrect documentation behavior discussed in the ticket.
Since version 0.9 `docutils` supports `code` directive. But this directive
can generate fullname classes for the `pygments` style classes.
For example, the following code
```reStructuredText
.. code:: c++
GetFoo()->do_something();
```
generate the following output
```html
<pre class="code c++ literal-block">
<span class="name">GetFoo</span>
<span class="punctuation">()</span>
<span class="operator">-></span>
<span class="name">do_something</span>
<span class="punctuation">();</span>
</pre>
```
Note, that fullname classes were used, when we need a short one
```html
<pre class="code c++ literal-block">
<span class="n">GetFoo</span>
<span class="p">()</span>
<span class="o">-></span>
<span class="n">do_something</span>
<span class="p">();</span>
</pre>
```
The existing related posts example doesn't show properties for the collection, this could be confusing to individuals who are not programmers, because as it was the code would render five bullet points.
I am also looking to add some type of loop control or if statement to the loop to detect duplicate, I tried t a dictionary sort filter through jinja, bu that through an error, the following is not guarantted to work then:
{% set LASTARTICLE = "notset" %}
{% if article.related_posts %}
<ul>
{% for related_post in article.related_posts|dictsort(false, 'url') %}
{% if not (LASTARTICLE == related_post.url) %}
<li><a href="{{ related_post.url }}">{{ related_post.title }}</a></li>
{% endif %}
{% set LASTARTICLE = related_post.url %}
{% endfor %}
</ul>
{% endif %}
the dicsort does not work (is this not a dict, I'm not a python guy so I'm just hacking at it.
the functional tests currently fail on Python 3.3 because the feeds output
differs. (see #688)
this is a temporary fix that will make travis happy while we provide a valid
fix for this issue.
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
