The ID of a feed entry should never change, but the previous method of generating the ID -- i.e., using the entry URL -- results in an ID that is not permanent and can change. Switching to the tag URI method from RFC 4151 should help improve the long-term uniqueness and permanence of entry IDs, as espoused here: <http://web.archive.org/web/20110514113830/http://diveintomark.org/archives/2004/05/28/howto-atom-id> Also added a trailing slash to the site URL inside the feed; the lack thereof was causing a feed validation warning.
The initial work on enabling feeds to be served from a different domain than the site domain focused on the feed link displayed inside the base template. But there is also a feed link inside the generated feed itself, which this commit updates to use the FEED_DOMAIN value (if defined). Also, it turns out that the FEED_MAIN_URL setting is not necessary; the existing FEED and FEED_RSS functionality is simpler and can address the targeted use case just as easily. That attribute has been removed from the settings and template, along with corresponding changes to the docs. Refs #177.
When you set ARTICLE_DIR which is not equal to PATH, ArticlesGenerator doesn't use DEFAULT_CATEGORY but use ARTICLE_DIR's dirname.
calling the module-level functions on an unitialised logging object. This allows to - simplify log.py - use one logger object for each file