The new year brings with it a new release of Pelican. Well, actually, Pelican 3.7 was released last month, but it’s in these first few weeks of the new year that I find myself with some spare moments to devote to trying out the latest version — a task somewhat overdue, having paid little attention to Pelican since version 3.5. So in this post I’m going to have a look at changes in Pelican since version 3.5 that might be relevant when upgrading an existing website.
Pelican changes
In general Pelican itself tends to be fairly backwards compatible, so often all that’s required is to upgrade the Pelican version in whatever virtual Python environment you might be using. However, there are often interactions between themes and plugins that might break things when upgrading.
There were a few things that affected me and the combination of theme and plugins that I was using after upgrading to Pelican 3.7.
One is that the uppercase PAGES context variable available to themes has been removed in favour of the lowercase pages. Unfortuantely, many themes use the uppercase version and therefore need to be updated before they will work properly with Pelican 3.7.
Another is that tag cloud support has been removed from Pelican itself and moved to the tag_cloud plugin. So if your site has a tag cloud, you’ll now need to configure the plugin.
On a side note, I just recently noticed the sitemap plugin now supports excluding URLs from the sitemap via regular expressions, which I find incredibly useful, since I don’t want tag or category pages in my sitemaps.
Pelican site configuration
While there’s a variety of possible workflows with Pelican (it being a command line tool after all) I assume it’s fairly typical to have static sites originally created using the Pelican quickstart script. This means there’s a Makefile (or Fabfile) that was created with a previous version of Pelican that won’t have enhancements or features present in recent versions.
So as I usually do when undertaking a Pelican upgrade (because I’m kind of anal retentive about such things), I ran quickstart to create a dummy skeleton site, then compared it with previous versions, to see if there is anything significant enough to incorporate into my site’s existing configuration.
Only the Makefile had any differences of note.
A diff between a version 3.5 and 3.6 Makefile gives (abridged, differences in echo output ommitted):
34a35,39
> RELATIVE ?= 0
> ifeq ($(RELATIVE), 1)
> PELICANOPTS += --relative-urls
> endif
...
72a80,87
> serve-global:
> ifdef SERVER
> cd $(OUTPUTDIR) && $(PY) -m pelican.server 80 $(SERVER)
> else
> cd $(OUTPUTDIR) && $(PY) -m pelican.server 80 0.0.0.0
> endif
>
>
81,82c96
< kill -9 `cat pelican.pid`
< kill -9 `cat srv.pid`
---
> $(BASEDIR)/develop_server.sh stop
110c124
< .PHONY: html help clean regenerate serve devserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github
---
> .PHONY: html help clean regenerate serve serve-global devserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github
So the main changes are support of the new relative URLs option, along with some changes to running the development server.
A diff of the version 3.6 and 3.7 Makefiles gives:
115c115
< s3cmd sync $(OUTPUTDIR)/ s3://$(S3_BUCKET) --acl-public --delete-removed --guess-mime-type
---
> s3cmd sync $(OUTPUTDIR)/ s3://$(S3_BUCKET) --acl-public --delete-removed --guess-mime-type --no-mime-magic --no-preserve
124c124
< .PHONY: html help clean regenerate serve serve-global devserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github
---
> .PHONY: html help clean regenerate serve serve-global devserver stopserver publish ssh_upload rsync_upload dropbox_upload ftp_upload s3_upload cf_upload github
There was also a tweak to develop_server.sh in version 3.7:
69c69
< cd $OUTPUTDIR
---
> mkdir -p $OUTPUTDIR && cd $OUTPUTDIR
Comments