Seriously-Simple-Podcasting
Seriously-Simple-Podcasting copied to clipboard
CastosHQ
HTML5 player art improvements
As confirmed by @jonathanbossenger, when finding the player art to use in the HTML5 player, it looks for the following (in order):
Option 1 : if the episode has a featured image that is square, then use that Option 2: if the episode belongs to a series, which has an image that is square, then use that Option 3: if the feed settings have an image that is square, then use that If none of the above passed, return the no-album-art image
As a result, most HTML5 players default to showing the podcast artwork from the feed settings for all episodes, as using a square image for an episode/series featured image doesn't usually fit into the design for most themes.
To make this more workable, I propose that a new image size is added to SSP, titled podcast-artwork (or something similar), that is simply a square version of the uploaded image. The HTML5 player than uses that image size for the artwork.
Considerations:
- A new image size increases the number of images on the server - there's no way around that.
- Thumbnails will need to be regenerated after the update that includes this new image size.
- In order to provide maximum control for the site owner, a setting would need to be added to the podcast settings where you can select if the player should use episode images, series images, or the feed artwork.
I would agree that having a podcast specific image is something we'd like to do. The Series or default Feed fallback is nice, but as you're pointing out the post featured image isn't ideal.
Idea is probably to have this as an upload (file picker) area in the "Podcast Episode Details" metabox just below the media file URL field. Is that what you had in mind @hlashbrooke ?
I was thinking that the player simply uses the episode featured image, but with the new podcast-artwork image size as that would crop it to a square. That would save on user having to upload an image in a separate location and would make things look more consistent on the frontend of the site.
The only concern I have around auto cropping is: what does the plugin determine as the center point to crop to. Depending on the structure of the original image, you might end up with a "nothing" cropped image. So as long as we document how the cropping takes place.
That's a good point - adding a cropping step would diminish the seamlessness of what I'm proposing and a bad crop would not be ideal.