feed_enclosures not rendering custom field containing mp3

Blarg- I’ve never used the feed encloser plugin- but that’s got to be where it’s borking. Any difference if you switch the parse_list?

And I may shift to ‘plugins’ because it’s looking like that’s where the issue is. Might be a simple tweak to someone who knows the code.

parse_list=y or =n both yield the same empty line…

OK- let me shift to plugins- and I’ll tweak the title to note it’s an issue with the enclosure plugin. Might also check if there’s an updated version of it.

When I get a chance, I’ll download the plugin and take a closer look at it. But I’d drop the author a heads up- they’ll know the code best.

thx!

Any resolution to this?

I am having the same problem with the blank line where the enclosure tag should be. I am NOT getting any curl messages. We have our own virtual server, but I’m not a sysadmin, anyone know how to test to see if safe_mode is on?

I have printed the file uri in a test element, to make sure it’s working. It’s not turning into a link and the formatting is set to none, so it’s not enclosed in tags either.

Same here. Hosting at EH. This plugin doesn’t seem to work any longer and has always been a bit problematic.

Got mine working, I’m afraid I can’t remember how any longer since I’ve moved on to other issues but I did leave some notes in my change log…maybe this will help?

Per this thread I turned off safe_mode and set open_basedir to none in my vhosts.conf file. (We have dedicated virtual server on MediaTemple). Then I remember turning on error logging and testing outside EE quite a bit to make sure CURL was working outside of EE. Basically, keep googling error codes till you get this working. Here’s the code I used to test that…perhaps of use to someone:

<?php

    if (function_exists('curl_init'))    // but if it is...
        {                                    //
            print ('We have curl_init!
');            // let's use it!
 
        }
    if (function_exists('curl_setopt'))    // but if it is...
        {                                    //
            print ('We have curl_setopt!
');            // let's use it!
 
        }     
    if (function_exists('curl_exec'))    // but if it is...
        {                                    //
            print ('We have curl_exec!
');            // let's use it!
 
        }   
  if (function_exists('curl_getinfo'))    // but if it is...
        {                                    //
            print ('We have curl_getinfo!
');            // let's use it!
        }  
  if (function_exists('is_resource'))    // but if it is...
        {                                    //
            print ('We have is_resource!
');            // let's use it!
        }  
     $ch = @curl_init();                // let's use it!
        //example url to mp4 file...use your own!
        $href = 'http://zonaemanuel.mymovi.es/-transformers.mp4';
     print ('URI:' . $href . '</br>');
        
                if (is_resource($ch))    // we have cURL!
            {
                curl_setopt($ch, CURLOPT_URL, $href);
                curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
                curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
                curl_setopt($ch, CURLOPT_NOBODY, true);
            curl_exec($ch);
                $http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
                $content_type = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);
                $content_length = curl_getinfo($ch, CURLINFO_CONTENT_LENGTH_DOWNLOAD);
            print ('http_code: '.$http_code.'
');    
        print ('content_type: '.$content_type.'
');    
                print ('content_length: '.$content_length.'
');    
                
            }
?>

After that was working, I noted:

Used AddType directive in .htaccess file to remedy EE’s mangling of them.

And then added the following to the beginning of my root .htaccess file:

AddType video/mp4 mp4

Thanks for such great notes. Our client hosts their MP3 files at LibSyn so we’re using the “remote=’y’” parameter.

I don’t think managing local MIME Types would be an issue? Would that thinking be in error?

Mimetypes wouldn’t prevent the plugin from working, but in my case it was showing locally stored mp4’s as text/plain in the feed, which is incorrect and iTunes doesn’t like it. EE may not mangle mp3s. This was also on EE 1.6.4…maybe fixed?

Agreed. We sometimes have to add MIME Types to htaccess or the httpd.conf file depending on where a site is hosted. But that’s only true for locally served media. The server serving the media is the one that needs the correct MIME Type declarations.

This plugin was working prior to upgrading to EE 1.6.7. Now it returns nadda.

Guess I have to do as you did and see what it’s doing both inside and outside EE.

Thanks again for your input.

Good luck. FWIW I’m on 1.6.7 and it seems to still be working for me.

http://mithun.com/news/itunes_podcast/

That’s good to know.

Can I ask what your “feed_enclosure” tag code looks like in your template?

Here’s the exciting part…let me know if you need the whole thing:

{exp:weblog:entries weblog="video" limit="10" rdf="off" dynamic_start="on" rdf="off" disable="member_data|trackbacks" status="Featured|Published"}{if itunes_url}  <item>
     <itunes:block>no</itunes:block>
     <title>{exp:xml_encode protect_entities="yes"}{title}{/exp:xml_encode}</title>
     <itunes:author>Mithun</itunes:author>
     <itunes:subtitle>{exp:xml_encode}{video_subtitle}{/exp:xml_encode}</itunes:subtitle>
     <itunes:summary>{exp:xml_encode}{video_summary}{/exp:xml_encode}</itunes:summary>
     {exp:feed_enclosures type="rss" parse_list="y" remote="y"}{itunes_url}{/exp:feed_enclosures}    <guid>{title_permalink="news/video"}#{entry_date format="{DATE_ATOM}"}</guid>
    {gmt_entry_date format="%r"}</pubDate>
    <itunes:duration>{video_duration}</itunes:duration>
    <itunes:keywords>{exp:xml_encode}{video_keywords}{/exp:xml_encode}</itunes:keywords>
  </item>{/if}{/exp:weblog:entries}

Mahalo (thanks) Mahalie (I recognize you from Brandon Kelly’s Get Satisfaction 😊

Actually, after more testing with local and other remote media files, it appears to be LibSyn. The client has setup some kind of dynamic pre-roll that causes their server to take over 30 seconds to reply after several redirects. This Feed Enclosure plugin simply ignores the non-answer from the server.

Sorry to request so much info from you and take up so much of your time today. But perhaps this will help others with similar issues…