this feed should only show the posts with mp3 attachments but it shows all post and does not even show the attached podcasts on the posts that have them. All posts in the category Grandma Nan Log have mp3 attachments that work in the sidebar player but iTunes says “Feed contains no episodes”.
That is an unusual problem.
Do you use a file type filter or a category filter for this feed?
(Deselect any file type or category)
What is the status of the following options (podPress > Feed/iTunes Settings):
– “Include only posts with podPress attachments in this Feed”
– “Bypass the “Included in:” selection for this Feed”
Which is your current podPress version?
File Type Filter: MP3
Category Filter: Grandma Nan Log
** I have now un-selected both
Include only posts with podPress attachments in this Feed IS CHECKED
Bypass the “Included in:” selection for this Feed IS NOT CHECKED
** No changes made to those two settings
podPress Version 22.214.171.124
After making these changes and modifying so text in one of the post (to make sure I don’t get a cached feed) I refreshed the feed page and it still does not show the podPress attachments. It also still shows all of the posts (not just the ones with podPress attachments).
Any idea what the issue is?
I have looked into the other RSS and ATOM feeds of you blog. In none of the feeds do the podcast posts have attachments. That is consistent with your observation that nothing changed after altering the category and file type filter of the RSS feed with the name podcast. These filter settings affect usually only one feed.
That is why I think that something completely different causes this problem.
Are you able to tell when the attachments disappeared from the feeds? Maybe after the last upgrade of this or a different plugin?
Are you using other plugins? Which plugins?
I just installed podPress on this site this week and it was never shown the attachments or filtered the posts in the podcast feed. I only know what I should expect to see because I installed it on another blog last week and it works fine there.
I think best description for this problem is that the podcast feed or any other podPress created feeds are no differnent than the standard WordPress feed:
I even tried creating a new feed in podPress called test and it is also the same (all posts, no attachments)
I also noticed that the title of the feed is not modified (it should have the feed name after the blog name but it shows just the blog name).
Other Plugins that were already instlled:
Add Categories to Menu
Version 0.2 | By Alister Cameron
Version 2.5.3 | By Automattic
Inline Google Spreadsheet Viewer
Version 0.2 | By Mr. Meitar Moscovitz
MP3 Player plugin
Version 1.2.4 | By Thomas Norberg
Version 126.96.36.199 | By Dan Kuykendall (Seek3r)
Version 2.33 | By Marko Martinović
Simple Move Comments
Version 1.1 | By Peter Hilbring
Version 3.8.6| By Instinct Entertainment
Xtreme MP3 Player v2
Version 1.0 | By Flashtuning
The WP e-Commerce plugin interferes with the feeds and seems to be responsible for the effect.
I have tested some of the plugins from this list but this plugin removes a lot of the customizations which are made with podPress.
I have not found out yet why it behaves that way or whether it has settings which may prevent this.
I’m still not sure what WP e-Commerce does to cause that problem. It looks like the plugin modifies the rewrite rules of the blog and redirects e.g. the podcast feed (/feed/podcast or /?feed=podcast) to the default RSS feed. Furthermore it seems imaginable that it implements own templates for the feeds which don’t have the Filter or Action Hooks which podPress uses to customize the feeds.
But I’m really not sure about this because the WP e-Commerce plugin is a really complex plugin with a lot of files and lines of code.
It is probably a good idea to add the tag wp-e-commerce to this thread to make the developers of this plugin aware of this issue.
I have searched a little bit more and it is using the RSS template of WP. But some circumstance prevents podPress using the Filter or Action Hooks in this template.
But it is also possible that is something in podPress which is not resolved in an ideal way.
I’m going to take a further look.
I think I have identified the problem. But I’m not entirely sure how to proceed.
WP e-Commerce is using the pre_get_posts Action Hook as well as podPress.
But there are 2 things which are probably not a 100% okay how the usage of this Hook is implemented in WP e-Commerce:
- It is used with the function add_filter() (see wp-e-commerce/wpsc-core/wpsc-functions.php line 900 (v188.8.131.52)) although pre_get_posts is an action hook and should probably be used with add_action(). But it seems that WP is tolerant about this issue or maybe it is no issue.
- The bigger problem is how or when this filter/action gets removed later during the page load procedure see line 789 (wpsc-functions.php).
remove_filter( 'pre_get_posts', 'wpsc_split_the_query', 8 );removes the filter/action with the same priority (8) as this filter was added. Maybe because the definition of this parameter is “The priority of the function (as defined when the function was originally hooked).”. But this remove_filter() call is in the callback function which gets called by add_filter() (line 900). This leads probably to a problem.
I’m not sure why it is necessary to remove the filter at the end of the callback function. Maybe it not necessary.
But the problem which has been described in this thread could be resolved by changing the priority from
remove_filter( 'pre_get_posts', 'wpsc_split_the_query', 8 );
remove_filter( 'pre_get_posts', 'wpsc_split_the_query', 9 );
Maybe this calling remove_filter() with the same priority inside the callback function itself leads to a conflict. see the paragraph below the example for remove_filter: “[…]It is also worth noting that you may need to prioritise the removal of the filter to a hook that occurs after the filter is added.[…]”
podPress adds its action without a priority to this hook. This means the priority is by default 10 and the podPress function (which initializes all the podPress actions which are customizing the feeds) gets executed after the callback function of WP e-Commerces and if there is a problem in the function of WP e-Commerce then the podPress function does get called.
A work-a-round for this problem would be to change the priority of the podPress action:
podpress.php (v184.108.40.206) line 300:
from none or 10:
add_action( 'pre_get_posts', 'podPress_feed_content_filtering' );
to lets say 7 or higher e.g. 1
add_action( 'pre_get_posts', 'podPress_feed_content_filtering', 7 );
@eli, if you change one of these numbers you can resolve this problem for your blog. In my opinion it is more correctly to adjust the priority in the file of the WP e-Commerce file (e.g. because of the note from the remove_filter() function explanation page).
@the WP e-Commerce developers: Am I wrong here? What is your view? I’m one of the maintainers of podPress. (A.k.a podPress2010 @ Twitter) If something is wrong with the way podPress uses this Action Hook the I would correct that.
WOW! You have really gone above and beyond here. I really appreciate all your hard work in debugging someone-else’s code. You have solved my problem and it wasn’t even a problem with your plugin.
i have received emails from the developers of the WP e-Commerce plugin and it is a better idea to adjust the number in the podpress.php until WP e-Commerce v3.8.8 comes out. They will probably fix the problem in this version.
(Modifying the other file could lead to different problems.)
Again, you have really gone above and beyond here. I have decided not to make any changes to either one for now. I have uninstalled the e-commerce plugin for now as I don’t really need it yet.
On another issue, I noticed some error in the apache error log relating to podpress. Is this something you can help me with? should I post this as another topic?
anyway, here are the errors:
PHP Fatal error: Uncaught exception ‘Exception’ with message ‘getid3.php MUST be included before calling getid3_writetags’ in wp-content/plugins/podpress/getid3/write.php:23
thrown in wp-content/plugins/podpress/getid3/write.php on line 23
PHP Warning: require(./wp-blog-header.php): failed to open stream: No such file or directory in wp-content/plugins/podpress/optional_files/index.php on line 99
PHP Fatal error: require(): Failed opening required ‘./wp-blog-header.php’ in wp-content/plugins/podpress/optional_files/index.php on line 99
PHP Fatal error: Class ‘getID3’ not found in wp-content/plugins/podpress/getid3/extension.cache.mysql.php on line 72
PHP Fatal error: Class ‘getid3_lib’ not found in wp-content/plugins/podpress/getid3/module.audio-video.asf.php on line 16
PHP Fatal error: Class ‘getid3_lib’ not found in wp-content/plugins/podpress/getid3/module.audio-video.mpeg.php on line 16
PHP Fatal error: Class ‘getid3_lib’ not found in wp-content/plugins/podpress/getid3/module.audio-video.quicktime.php on line 16
Thanks for reporting this error message!
It is related to the getid3() library which podPress uses to retrieve the meta information (ID3 Tags and duration) from media files.
That is why I think that this error occurs when you detect the duration or the ID3 information of a media file.
Do you have time to find out whether one of these two actions is connected to this error? and which one?
I’m going to look into this matter and try to find out what is causing the problem. But I will probably have no time for podPress and such an investigation until the end of next week. If you have time then it would be a big help to narrow the number of possibilities down and save time.
should I post this as another topic?
Yes, it is a different problem and it would be the right thing to do.
I have just looked into my error.log file and could not find such entries. But on a second look these error message seem to say that it was not possible to load the file getid3.php or getid3.lib.php.
Maybe something went wrong during the last upgrade or the installation. Please control whether those files are in the sub folder /wp-content/plugins/podpress/getid3 and make sure that they have the necessary permissions. 0644 should be okay. You can check that via your FTP client software.
On the other hand this error:
PHP Fatal error: require(): Failed opening required './wp-blog-header.php' in wp-content/plugins/podpress/optional_files/index.php on line 99
says that someone or something has tried to open the file wp-content/plugins/podpress/optional_files/index.php and since some functions in it require the other function from other files the attempt to open the file ended in that error message.
But the point here is that nothing podpress calls/opens that file because it is an optional file which you may use under some circumstances. If you would want to use it then you would need to copy the file manually to different folder so that it can work.
Furthermore I think that podPress does not use the write.php functionality of getid3(). It only reads the meta information. (Maybe it will be possible in future version to edit the ID3 information.)
I think that it is possible that these errors come from attempts of web bots which have tried to open files like getid3/write.php, optional_files/index.php or e.g. getid3/module.audio-video.asf.php.
If these errors are not connected to the duration or ID3 tag detection then you may check the permissions for these files and folders (644 or 755 should be enough). It might also help to rename the index.php in the optional_files/ folder e.g to _index.php (or delete it) and to put an empty file with the name index.php into all the sub folders of podPress. You may find such a file in /wp-ontent/plugins (or /wp-content/).
I will add such empty index.php file to all sub folders of podPress with the next release.
I have managed to make my server log all PHP errors and it seems not to be a problem of the ID3 or duration detection. But I get very similar looking error message when I open these php files directly in my browser.
If you can confirm that then copy empty index.php files into the sub folder and check the file permissions.
ps: Let us talk about this problem in this thread and open next time a new thread.
I think that it is possible that these errors come from attempts of web bots which have tried to open files like getid3/write.php, optional_files/index.php or e.g. getid3/module.audio-video.asf.php
I think you’re right about the direct pathing to these files. I have not yet nailed down when this is happening or by whom. But it is not me and it doesn’t seem to be coming from normal usage of the site.
I will try to debug more and figure out where the errors are originating from but it seems clear that it is not an issue with the plugin.
Thanks for all your help!
- The topic ‘[Plugin: podPress] podcast feed not showing attached MP3 files’ is closed to new replies.