Good news everyone: Podlove Publisher 2.4 was released today.
Yeah, it’s been a while – but while development on Podlove Publisher was slow it was never coming to a halt. We have constantly improved little things, put some polish on existing features and added a bunch of stuff under the hood.
So we are happy to have 2.4 available to you now and want you to update as soon as possible. But please take a moment to read about the changes.
There are significant changes to how the Publisher does things in the background. Most importantly, the whole subsystem on how background jobs are handled has been replaced with a new model that should be far more reliable for some environments and in particular for episode-rich podcasts. This is the basis for improvements done to the Publisher’s Analytics feature which was a focus for this new version.
Be aware that the new Analytics might bring some disappointments. We have used the time to review the system under half a year of real world use and have found that the Publisher was tricked into believing some traffic to be true download activity while it wasn’t. Turns out that those on the Dark Side™ are hitting all our servers with a lot of bots to find security holes. While we are not aware of any security breaches in our software, the Publisher did count many of these shady requests as legitimate download intents.
Well, no more. The downside is that after a quick recalculation (which will be kicked off automatically when upgrading), your statistics might look slightly more bleak than they did before. In our tests we experienced an up to 20% drop in the reported numbers. Sorry, not much we can do about that.
When releasing the Analytics feature we told you not to make too much out of these numbers as they need to pass the real world test. So here is the result of that. However, we are hopeful that you won’t see anything like this in future updates to the Publisher.
To compensate for this, we have improved that Analytics dashboard presenting the data in a much more meaningful way. Numbers are now presented in a cumulative way allowing for easy comparison of individual episodes. You can look at summaries on a daily basis for the first week, then weekly (for the first month), then monthly (for the first quarter), then quarterly (for the first year) and then yearly (up to three years). Not all of these columns will be visible immediately: just head up to the standard WordPress Screen Options on the top of the page to set your preferred viewing configuration.
The “Downloads per Day” chart on the top of the Dashboard should also be much clearer now, showing the top episodes downloaded in the recent two weeks. We have also updated the list of known Podcast Clients making the episode analytics more useful.
In addition to some global statistics being shown everything should also load MUCH faster than it did before as things are computed in the background now and cached for quick display.
Podlove Web Player 2.1
We have also included a fresh copy of the recently updated Podlove Web Player that received some technical and some visual updates to keep up with the fast pace of the Web. We have also added the Podigee Player to be used optionally if you prefer to do so.
New Tools menu
In order to make the Publishers UI more meaningful and easier to understand, we have created a new Tools page that contains helpful tasks that might be useful when things look stuck or confusing data is presented. We think these need to be invoked only every now and then or possibly never. But PHP web systems can get messy sometimes so we thought it’s better to have a toolbox ready to take action before having to rely on external support.
The logging section in the dashboard has always been confusing so we cleaned up the mess to make it more helpful. We moved it to the Support page (to make clear when you might want to use it at all) and added some filtering options when you want to look for past errors and warnings. More needs to be done in this area but hopefully these changes will be helpful already. We also dropped some messages that polluted the log file for no good reasons.
Moving to HTTPS
Moving web sites to HTTPS should be a no brainer, but doing this for podcasts has a caveat: for reasons unknown to intelligent beings on this planet the iTunes Podcast Directory still has weird limitations when dealing with HTTPS-enabled podcast web sites. While claiming having full HTTPS support in their backend Apple is effectively limiting iTunes to TLS certificates that are given out by a short list of apparently hand-picked providers on the Internet.
This rules out using the by far most popular and most recommendable approach on the net these days: getting a free and automatically renewing certificate from the great folks of Let’s Encrypt (read about this in this support thread). But also other certificates are excluded.
We have no clue why this limitation exists but it effectively prohibits many podcast sites from moving to HTTPS. Once feeds are delivered via HTTPS and do not meet the limited requirements of the iTunes Podcast Directory, new episodes will not show up for existing podcasts and new podcasts can’t even be submitted to the store. Ouch.
But Podlove is here to help. You can now configure your web site to use HTTPS for all pages EXCLUDING your feeds (everything under
/feed) and Podlove Publisher 2.4 has a new expert setting that allows you to define this.
You can choose from the following settings:
* Don’t assume anything about the configuration (default)
* Website is run via HTTP only
* Website is run via HTTPS only
* Website is run via HTTPS (excluding feeds which use http)
Select your setup and Podlove Publisher will then do the right thing. The last option will make sure the feed URLs will be consistently displayed, delivered and redirected properly to make sure that iTunes can still access your podcast.
The iTunes FAQ says that HTTPS will “eventually be required”. Let’s hope they fix their handling of certificates before that time comes.
Goodbye, Feed Validator
We have dropped the external feed validation check with Feed Validator. While we generally think an external feed checker is a good thing, Feed Validator just didn’t cut it for us.
Not only did it (mistakingly) complain about Podlove’s (and other) name spaces being used. It also has a severe and problematic issue with the above mentioned migration towards HTTPS by not allowing URLs to use the https protocol scheme (although the original RSS 2.0 spec does not explicitly prohibit HTTPS to be used). So all https URLs were considered buggy. The team always resisted changing this behaviour so we have to remove it.
We might make use of newer validators Cast Feed Validator or Podbase in the future but for now we recommend you to do your checks with them manually to see if things are okay. Just don’t use Feed Validator anymore, it’s bad for podcasts and probably won’t ever change.
We have fixed a ton of tiny bugs and added some niceties here and there to make us all happy including more meaningful defaults for new users, using the post’s featured image as an episode image, fyyd.de podcast directory integration and best of all: Emojis in titles and descriptions are no longer swallowed ????!
Podlove Publisher 2.4 does not change its system requirements and should just work when installed.
However, we strongly advise you to keep your WordPress and PHP version up to date all the time. Some features of the Podlove Publisher rely on WordPress being updated and you should always run the latest version just for security reasons alone.
Please note that PHP 5.4 and 5.5 (while still being supported by the Publisher) have RUN OF OUT OF SUPPORT. These versions no longer get any security updates potentially making your system easy to exploit by the bad guys. Please do take this seriously. The Podlove Publisher may also increase the minimum version of PHP at any time. An added benefit of this: the faster people move to current versions of PHP the easier it will to improve reliability and add new features as the latest versions bring a lot on the table developers really like (and need).
If security alone is not enough to convince you (although it should), pleas note that moving to PHP 5.6 will probably double the speed of your system and moving to PHP 7 WILL DOUBLE THAT once more. The result is a faster less resource-intensive web site which is always a good thing.