I’m having two separate issues that both began with the recent update to podPress 8.8.8:
1. 8.8.8 is building my podcast RSS feed incorrectly. it’s adding in all posts instead filtering out posts only with the “podcast” slug. the URL i’ve been using since first installing podPress on my site in 2007 is http://www.audioshocker.com/?feed=podcast — however, the feed podPress is creating at http://www.audioshocker.com/feed/podcast is correct, but that feed seems to be a recent creation of the altered Feed/iTunes Settings Page that came with 8.8.8. i read the readme file with 8.8.8 to try and figure out what the deal is with this, but i didn’t see anything in there that helped. the only fix i know of for this is to revert back to 188.8.131.52, which is fine, except that doesn’t help fix this next issue:
2. if you load my blog’s main page http://www.audioshocker.com/ in Firefox, it automatically sends the browser window down to the last podcast on the page. it seems to be directly related to the Flash podPress player, because hiding the player is the only solution i’ve been able to find. IE and Chrome load the page fine, but Firefox religiously does this — even for older pages of posts. and the problems persists in 8.8.8 and 184.108.40.206 and 220.127.116.11 alike.
any help is greatly appreciated! i can fix the feed if needs be, but i’m not crazy about the solution. the only other thing i can think of to remedy these issues is to switch to Powerpress.
thanks for this detailed report!
The first problem is indeed a bug in v8.8.8. I’m gong to fix this until tomorrow. The feed with the name podcast should contain only posts with podPress attachments.
http://www.audioshocker.com/?feed=podcast and http://www.audioshocker.com/feed/podcast are two addresses for the same feed. The first one is the URL of the default Permalink setting and the second one is the URL with a different Permalink scheme. The first one works always (independently of the Permalink scheme).
I can also reproduce the second issue. But it is caused at least not solely by podPress. I’m using the FF Add-On NoScript and I have tested your by confirming each script one by one. After a first test I can say that this effect occurs when I allow scripts from the domain of your blog and additionally from brightcove.com.
(When I allow e.g. only scripts from the domain of your blog then the effect does not occur (besides the fact that the podPress scripts are working))
So it seems to be an interference maybe with different plugin. Can you tell me which plugin needs scripts from brightcove.com? I like to investigate this a little bit further.
Which plugin do you use to insert these Brightcove videos?
no plugin for Brightcove content — it comes from embedded video included in the body content of some of my podcast posts.
i don’t know if this observation affects the way Brightcove code and podPress interact, but i know that the page loading issue isn’t only attracted to podcast posts including Brightcove code — it just seems to gravitate to whatever podcast post is the closest to the bottom.
thx for the help!
no plugin for Brightcove content — it comes from embedded video included in the body content of some of my podcast posts.
You have copied the <object> element and all of these <params> into the HTML view of the post editor of your. Am I right?
In this case I’m going to test a little bit with <object> element from your source code in my test blog.
I will report back if I find something helpful.
it just seems to gravitate to whatever podcast post is the closest to the bottom
.. or maybe to the Flash object that is loaded last.
yeah, the code is copied into the HTML view of the editor. it’s taken directly from the embed code given out by Brightcove for their Marvel video content. (for example http://marvel.com/videos/watch/771/x-men_1992_-_season_1_episode_11 )
i wouldn’t normally do something like that, but we’re reviewing X-Men episodes on the podcast and i want to create a rich media experience for our listeners that also visit the blog and read the posts.
I think it is okay that you insert the code this way. It works in general.
There are several parameters in the embedded code. One of them is allowscriptaccess. You can find it two times in the code. Both times it is set to “always”. If you set this value to “samedomain” or “never”, the scrolling effect disappears.
In the linked Adobe tutorial article it says: “[…] In Flash Player 8, the default for an unspecified allowScriptAccess value remains “always” when the main SWF in Flash Player is version 7 or earlier, but changes to “sameDomain” when the main SWF is version 8 or later.
The allowScriptAccess parameter allows an HTML page to include Flash content but prevents it from executing scripts in the HTML page.
[…]” (… if it is set to “never” or to “samedomain”)
This scrolling effect is probably made by a script which the player loads from a remote server and is maybe intended to set the focus on this player. (Who knows …) When you block this script, this scrolling effect should not occur and the video or the player should work as before.
I have tried this and I have had no problems watching the X-Men episode and using player elements. The player seems to work well with the changed parameters.
(It is likely that you need to change the parameter for all videos on your current blog page to let the effect disappear.)
Tim, the feed is working great and the “never” parameter did the trick for the page loading issue. many MANY thx!
I’m experiencing the same issue it seems.
Our podcast feed at http://anamericanatheist.org/?feed=podcast has worked through all podPress versions but broke with the most recent update. It now features every post, whereas before it was only posts marked ‘Broadcast’ (or perhaps only posts with podPress content – those two criteria return the same results).
Also, while I like the concept of multiple feeds which seems to have been introduced, I don’t understand how it works with the old, single, default feed. By default, I had the feed, enhanced feed, and torrent feed turned on, though I’ve never seen those settings before. I turned them all off, and then my broken feed at /?feed=podcast stopped working! I thought these were extra feeds, dissimilar from the basic feed. If so, why does unchecking the ‘Feed podcast’ at the bottom take /?feed=podcast offline? And if it’s meant to be the same, why I am asked about iTunes metadata twice, once above the feed settings-accordion, and once again within it.
Also, until I can get these issues sorted out, is it safe to downgrade podPress? Just deactivate the plugin, delete it and install an older version?
I very much enjoy podPress and encourage you to keep it up but these issues are show-stoppers right now for us.
It now features every post,
Yes, that is a bug and I’m working on a version that will fix this. But since my last estimation of the time I need for the repairs, I have found one or two more problems which are related to the category feeds and which I would also like to fix with the next release. I will probably release a bug fix version this week.
to the “multiple feeds concept”:
By default a WordPress blog has one RSS, RSS2 and ATOM feed for posts and for comments. It also gives you feeds e.g. for each category.
But the feed with the slug name podcast is (and has always been) an additional feed to a WP blog. podPress has added also a feed with the slug name premium. Since v8.8.5 beta 3, podPress offers also a feed with the name enhancedpodcast and torrent. Both feeds were ATOM feeds by design to allow multiple episodes per post element in a feed. Furthermore their had have a file type filter. The enhancedpodcast feed contains only .m4a and .m4v files and the feed with the name torrent only post with attached .torrent files.
But until 8.8.8 there was no way to change for instance these file type filter rules. It was also not possible to adjust values like the title of these feeds to give the listeners a better understanding of the content of these feeds. It was only possible to change the title and the description for all the feeds with the exception of the category feeds. podPress had (and still has) for those feeds individual configuration pages like the Feed/iTunes settings pages for the main blog feeds.
The idea behind these new feeds options is the possibility to have e.g. a feed with posts with attached audio files and a different feed with video posts or maybe a feed with .m4a files and one with .mp3 files. Furthermore this new option section should give the podcaster the ability to control and customize these additional feeds.
For instance if you have feeds ith different file types like one for audio and one for video then you can have different description and feed images which helps the listeners to differentiate the podcasts better. Also it is now possible to change slug names of these feeds (Same podcasters have asked in this forum for a way to rename these feeds.).
I turned them all off,
That is also possible for the first time. But you are right, the feed with the name podcast is your /?feed=podcast feed and if you deactivate it, it is offline.
And if it’s meant to be the same, why I am asked about iTunes metadata twice, once above the feed settings-accordion, and once again within it.
You should do that because the form above the feed settings-accordion is from now on only for the main blog feeds and the feed settings-accordion is for the additional feeds which are added by podPress.
It would have been probably be a good idea to copy the data from the old form to the new ones during the upgrade process. I’m sorry for the confusion and I will try to add further information and explanations to the readme file and the changelog page.
is it safe to downgrade podPress?
Yes, but you should save the Permalink settings and the widgets settings after downgrade. Because the widgets are working differently in v8.8.8.
You report and your question helped me to understand the problem better. So, thank you!
I’m working on it and I will report back as soon as I finish the patches.
I have implemented patches which should make that e.g. the “podcast” feed contains only posts with attached podcast files again. The mentioned category feed problems should also be fixed.
These patches are parts of the current Development Version (listed below “Other Versions”).
I would appreciated it, if you could test it, too.
Before your Development Version post, I did copy much of the metadata from the general feed area and selected the ‘MP3’ file type only. This fixed my feed but left me with only a single entry instead of the usual 5-8 we like to keep up. I’m guessing this was because it was grabbing X latest entries and then filtering it to MP3 entries, instead of grabbing X MP3 entries.
I applied your Development Version and the feed at http://anamericanatheist.org/?feed=podcast looks correct again.
I do like the new changes/changes I’ve just discovered, but I’m still a little unclear on how I’m to be organizing them.
Let’s assume I only want one regular podcast feed to be a feed of only posts which have podPress data – with the fixed 8.8.8 version, that will be the WordPress general ATOM/RSS feed at /?feed=podcast and /feed/podcast, right? But then if I want to make other feeds, perhaps with certain criteria like “feeds by Tom with m4v files”, I would use the accordion interface below to establish a second feed, right?
But, the first feed in the accordion is also the WordPress built-in /?feed=podcast ? Or is the first feed in the accordion /feed/podcast ? Does /?feed=podcast exist without podPress, in which case, what is it populated by?
I know some of this isn’t podPress specific but I’m guessing you’re one of the better folks I could possibly ask. 🙂
Thank you for the tests!
Before your Development Version post, I did copy much of the metadata from the general feed area and selected the ‘MP3’ file type only. This fixed my feed but left me with only a single entry instead of the usual 5-8 we like to keep up.
That sounds odd indeed. I will investigate that.
But, the first feed in the accordion is also the WordPress built-in /?feed=podcast ?
No, /?feed=podcast and /feed/podcast are not built-in a clean WP installation. podPress adds this feed to your blog as long as it is activated. (/?feed=podcast and /feed/podcast are parts of two URLs which are leading to the same feed (the feed with the slug name podcast).)
podPress adds e.g. this feed but it also adds these iTunes tags to all other RSS feeds of the blog. The settings in the “Feed Settings” section of the “Feed/iTunes Settings” page of podPress are for customizing the iTunes tags and other elements of those feeds.
So, you could use simply the main posts feed of the blog (preferaly the RSS feed) in iTunes.
But podPress adds also these additional feeds to the blog which should give you the chance to publish your content in more individualized ways. to customize those feeds you use the accordion interface.
One characteristic of these additional podPress feeds is that they contain only posts with podPress attachments (files which are added to posts via the podPress box below the post editor). That is also valid for category feeds with activated CategoryCasting.
… and you are right. If you want to have a feed with posts which have m4v file attachments then you would use one of these additional feeds. But if you have podcasts of two different authors e.g. Tom and Joe and you like to publish them in separate feeds then it is a good idea to add those posts to certain categories and use the CategoryCasting feature to add custom information to those feeds. (You can reach this CategoryCasting feature only if you edit an existing category).
I’m guessing this was because it was grabbing X latest entries and then filtering it to MP3 entries, instead of grabbing X MP3 entries
Yes, that is right and I’m going to change that, too. But if you want to use this filter now, you could use in the mean time the “Syndication feeds show the most recent X items” setting at the Readding Settings of your blog to regulate the number of posts in the feed. But changing this value influences also the number of items in all feeds.
- The topic ‘podPress 8.8.8 feed creation and page loading issues’ is closed to new replies.