Änderungsprotokoll

2.7.19

We are now compatible to the new WordPress 5.0 Gutenberg block editor.
You can choose to use the new editor or stay with the classic editor for now by installing the classic editor plugin by WordPress.

• feed: do not include <itunes:summary> tag if it is empty (Apple Podcast requirement)
• adjustments for Gutenberg compatibility:
  • Shows metabox moved from sidebar to main area
  • remove broken form field autogrow behavior
  • fix contributors UI initialization

2.7.18

• improve feed generation time when seasons are used (#1010)
• title migration module:
  • remove „episode type“ selector, always use „full“
  • add warning when there might be too many form fields
• new PHP constant PODLOVE_DISABLE_TAG_AND_CATEGORY_SEARCH (#1017)
• feed item limit: „1“ is now an option
• add missing contributor template accessors: organisation, department, jobtitle
• ensure Gutenberg editor is not used for episodes

2.7.17

Downloads Data Export

Download data per episode can now be exported as JSON and CSV.
On the Analytics page you will now find a simple export interface.
Select the episodes you want in the export or don’t select any to export them all at once.

WP REST API Support

Backbone for the data export is an implementation of the WP REST API.

Endpoint for the episode custom post type:

• /wp-json/wp/v2/episodes

Custom endpoints for episode analytics:

• /wp-json/podlove/v1/analytics/episodes/
• /wp-json/podlove/v1/analytics/episodes/123
• /wp-json/podlove/v1/analytics/episodes/123,82

All analytics are available as CSV by adding ?format=csv as parameter, for example /wp-json/podlove/v1/analytics/episodes/?format=csv

Analytics endpoints require the podlove_read_analytics permission, the same as viewing analytics in the admin.

Please read https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/ if you want to use these endpoints.

Other

• Fix deprecation warning when using multiple categories (#1009)

2.7.16

• update Podlove Web Player 4

2.7.15

• automatically abort stuck background jobs
• contributors now appear in feeds even if they don’t have a URI #939
• Shows: custom language is now used for Podlove Subscribe Button

2.7.14

• update Podlove Web Player 4

2.7.12/13

• use wp_enqueue_script instead of inline JS when calling PWP4, improving compatibility to other plugins (#1000)
• uninstall: be more specific which options are deleted (#997)
• new filter podlove_network_module_activate to force-enable network module (#995)
• new social services: Mastodon, Fediverse, Friendica (#987, #968)
• fix related episodes disappearing when using post scheduling (#980)
• fix seasons error when there are no episodes (#963)
• related episodes: order by post date (#947)

2.7.10/11

• update Analytics JS frameworks, fixing #982
• add download location analytics chart
• remove weekday chart
• add option to disable average episode display

2.7.9

Too much slimming in 2.7.8. Undo.

2.7.8

• fix release workflow
• slim down plugin size by removing unnecessary files from release
• update Podlove Web Player 4

2.7.7

Update 2.7.5 changed the way download tracking works to comply with GDPR. We tried the radical approach and anonymized IPs. As it turns out, this is not viable. Download numbers are skewed by this change and often much lower than they realistically should be. If you saw a drop in downloads since updating to 2.7.5 or 2.7.6, this is the reason.

The good news is that this update changes download tracking again and new download numbers should get back to normal. The bad news is that the data since the GDPR update cannot be fixed/restored because it’s missing data granularity — which was the point of the change; just not anitcipating the effect on the actual download numbers.

So what’s the new tracking approach?

Podlove Publisher now stores the request_id again just like before the update: a hash based on the actual IP address and the user agent. What’s new is that now once a day, all request_ids older than 24 hours are salted again, making it impossible to restore IPs from them. This 24 hour window is enough to determine download numbers exactly as before the GDPR update.

To be clear, IPs are never stored in plain text. But since IPs could be restored by brute force attack from the temporary unsalted request_id hashes, they have to be treated like plain IPs. The text snippet for your privacy page has been updated in the docs and you should update it on your site: https://docs.podlove.org/podlove-publisher/guides/dsgvo-gdpr.html

2.7.6

No changes.

2.7.5

Preparation for GDPR/DSGVO

If you are using Podlove Publisher Tracking/Analytics, an update to this version is highly recommended.

Tracking uses a request_id to be able to determine when two requests came from the same user and should be counted as one unique access. This request id used to be a hash of the original IP address and the user agent. This approach however is vulnerable to a brute force attack to get the IP address back from the hash. Here’s what we are doing about that:

First, we anonymize the IP before generating the hash. So instead of using 171.23.11.209, we use 171.23.11.0.

Second, you need to deal with the existing request_ids. There is a new „DSGVO“ section under „Tools“ with a button that will rehash all existing request_ids with a randomly generated salt. That way it will become unfeasible to determine the original IP address but your analytics will stay the same.

In case you have a lot of downloads (let’s say much more than 50.000), you may want to do this via command line because that will be much quicker than via the tools section. You need wp-cli, then simply call wp eval 'podlove_rehash_tracking_request_ids();'. On a multisite, pass the blog id as a parameter: wp eval 'podlove_rehash_tracking_request_ids(42);'.

Other

• fix Podlove Subscribe Button language parameter
• fix rel="self" link in show feeds
• fix Podlove Subscribe Button not delivering show feeds
• templates: handle episode.show access when there is no show
• templates: allow episode filtering by show, for example: {% for episode in podcast.episodes({show: "example"}) %}

2.7.4

No changes, but the previous release is not delivered correctly by WordPress, so this is simply a re-release attempt to fix it.

2.7.3

• fix: geo database updater
• update Podlove Web Player 2: remove Flash Fallback
• update Podlove Web Player 4

2.7.2

• fix: itunes:image tag in show feeds
• fix: „Debug Tracking“ choosing wrong media files to check availability
• enhancement: „Debug Tracking“ now suggests disabling SSL-peer-verification if URL cannot be resolved and https is used
• system report: include active plugins

2.7.1

• fix: PHP warning when the_title filter is called with only one parameter
• fix: handle colons in migration tool
• fix: PWP4 warning when using shortcode
• new service: letterboxd

2.7.0

New Module: Shows

With shows you can offer feeds to subtopics of your podcast. Here’s how it works: You create a show and define show meta, similar to a podcast: title, slug, subtitle, summary, image and language. These fields override your podcast settings. All other settings are the same as your podcast.

For each episode, you decide which show it’s in. Each show has its own set of feeds that listeners can subscribe to. The main feed remains unchanged, containing all episodes from all shows.

The Podlove Subscribe Button can be configured to subscribe to a show by referencing the show slug. Use the shortcode [podlove-subscribe-button show="show-slug"] or the template tag { podcast.subscribeButton({show: 'show-slug'}) }}.

We do not recommend using Shows and Seasons at the same time.

Updated Metadata for Podcast/Episode/Seasons according to iOS11 Specification

Apple announced an updated specification for feed elements. These changes enable the Apple Podcasts app to present podcasts in a better way. But since these feed extensions are readable by any podcast client, we expect others to take advantage of these new fields soon. Here is how we implemented the specification:

• The podcast has a new „type“ field where you can select between „episodic“ and „serial“, which may affect the order of episodes. The field <itunes:type>episodic</itunes:type> appears in the feed.
• Episodes have a new „title“ field. It defaults to the episode post title but can be set separately now, allowing you to define different titles for the website and podcast clients. The field <itunes:title>Interview with Somebody Infamous</itunes:title> will appear in the feed.
• Episodes have a new „type“ field where you can select between „full“ (default), „trailer“ and „bonus“. This won’t have any effect in the Publisher but may be used by podcast clients. The field <itunes:episodeType>full</itunes:episodeType> appears in the feed.
• Episodes have a new „number“ field. If used, <itunes:episode>42</itunes:episode> will appear in the feed.
• Episodes in seasons will have an <itunes:season>2</itunes:season> field in the feed automatically.

We decided to complement these changes by introducing a podcast mnemonic/abbreviation field. Now we can autogenerate blog episode titles, based on the episode number and title, if you like. The mnemonic can be set in podcast settings. The setting to autogenerate blog episode titles is an expert setting in the „Website“ section.

To help existing podcasts to conform to these new fields we made a „Title Migration“ module which will greet you with a notice once you update the Publisher. It will try to extract episode numbers and titles from your existing titles, saving you time and effort updating each episode one by one.

Template API Changes

• episode.title now returns the new episode title field, if it is set, but has a fallback to the post title. If you want a specific version, use episode.title.clean or episode.title.blog.
• the post title of an episode can still be accessed via episode.post.post_title
• new accessor: episode.number
• new accessor: episode.type
• new accessor: podcast.mnemonic
• new accessor: podcast.type
• new accessor: season.mnemonic

Podlove Web Player 4

The Shortcode [podlove-web-player] accepts several parameters, increasing its versatility.

With post_id you can embed episodes on any page, for example [podlove-web-player post_id="1234"].

Every config parameter available can be overridden using shortcode attributes. The only difference from the linked documentation page is the notation. For nested configs like show.title use underscores (_) instead. For example, display a green player with custom title like this: [podlove-web-player show_title="Special Title" theme_main="#00ff00"]

You can now also display a player with live content like this: [podlove-web-player mode="live" audio_0_url="http://mp3.theradio.cc/" audio_0_mimeType="audio/mp3" title="Livestream" link="https://theradio.cc"]

You can choose to deliver Podlove Player via Podlove CDN (Content Delivery Network) or via your WordPress server. CDN is the default for new setups but if you are already using Podlove Publisher we continue delivering Podlove Player via your WordPress server unless you explicitly change it.

Podlove Web Player 4 is the new default player.

Other

• analytics: show download totals for last 24 hours and last 7 days in overview
• Podigee Player: add support for transcripts
  • create a Podigee Transcript asset
  • set this asset in Expert Settings > Web Player
  • See https://cdn.podigee.com/ppp/samples/transcript.txt for an example transcript
• Podlove Web Player 4: support contributors
• player settings: when no episode or files are available, use a „Podlove“ demo sound
• reduce Podlove Template Cache duration from 1 day to 1 hour for the following change:
• new template accessor: {{ episode.total_downloads }}
• New in „Global Feed Settings“: An option for how the episode title should be displayed. It defaults to „Blog Post Title“, so that after the iOS 11 title migration, the output does not actually change — following the principle of least surprise. However, the setting can be changed to „Episode Title“, which is the new clean title, or „Custom Template“, which is a title template with the same capabilities as the blog post title template.
• when using the Podlove Subscribe Button CDN and the CDN is not reachable, fall back to the locally hosted script
• fix Geo DB Updater: use our own Podlove CDN as download source
• fix quotes in contributor fields
• fix WordPress conditionals in episode archives
• fix deleting related episodes (#907)
• fix network admin bar now does not include broken links if Publisher is not activated network-wide (#933)
• fix import getting stuck issue (#910)
• Bitlove module: remove all frontend functionality because it has been dysfunctional for a long time
• fix Auphonic module showing wrong status message after file upload
• fix Audacity chapter import when times contain commas
• fix email notification issue where not emails were sent (#938)
• fix feed redirect issue for HTTP/1.0 clients
• fix network module: only activate when the plugin is activated network-wide, not when the plugin in active within a multisite
• fix calculation of contribution counts
• Fix various issues in the download table display. Until now, new downloads were calculated hourly, which provides a good estimate but often not exact numbers. The calculation could also get stuck, leading to missing data display. From now on, the estimates are still calculated hourly but additionally a full, precise aggregation is done once a day, which should lead to more consistent numbers overall.
• enhance email error reporting
• enhance open graph module: detects WP SEO plugin and does not output any tags to avoid conflicts
• social services: add SlideShare
• show warning if upload directory is not fully qualified
• remove download section from default template (because it is included in PWP4)
• image cache: instead of returning invalid URLs with 0 width and 0 height when something goes wrong, return the source URL instead
• episode list: add display option to display episode number as a column
  add Liberapay as donation service
• display current season in episode form

Changes for previous versions can be found in the changelog.txt.