A client wishes to move their WordPress site into Drupal, which includes a podcast site that uses PodPress. Instead of trying to get them to upgrade away from PodPress first, I went ahead and added code to import PodPress items into Drupal.

PodPress doesn't seem to store podcast files as attachments, instead it just gets the user to enter a file address for the audio file. To get around this I had to add instructions for the user to copy over the audio files into Drupal's files directory, and then enter the file prefix, e.g., sites/default/files/podcasts_to_import. Suggestions welcome for a better way to handle this. I'm new to this module's code.

There is also a dependency on file_entity for the function file_uri_to_object which I use to add the file field attachment. Should I copy the code for that function into wordpress_migrate to remove this dependency?

Patch forthcoming.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alxp’s picture

Status: Active » Needs work
FileSize
4.24 KB

Here's what I've got so far. Please offer suggestions to improve the code so it fits better with the rest of the codebase.

alxp’s picture

Oops, had some experimental code left in there, here's a cleaner patch that also checks for file_entity module.

mikeryan’s picture

I'd like to see an example of exactly how these podcasts are rendered in the XML. If the podcast files can be expressed at URLs, it will be much better to copy them directly rather than require a manual copy to the web server (only of use for users of a technical bent, with server access).

There should be a more elegant way to map things than mapping from 'postmeta', since the postmeta fields are already parsed out into $row.

The dynamic checks for file_entity are fine, we're doing similar stuff for other dependencies like media (and if you have media, you have file_entity).

Thanks.

alxp’s picture

Here's what the XML looks like:

		<wp:postmeta>
			<wp:meta_key>_podPressMedia</wp:meta_key>
			<wp:meta_value><![CDATA[a:1:{i:0;a:10:{s:3:"URI";s:101:"http://wp.drupal-dev-local/wp-content/uploads/2012/10/2008-sep-26-jw-podcast-intro.mp3";s:5:"title";s:20:"JWatch Intro Podcast";s:4:"type";s:9:"audio_mp3";s:4:"size";s:7:"1803126";s:8:"duration";s:4:"3:45";s:12:"previewImage";s:96:"http://wp.drupal-dev-local/wp-content/plugins/podpress/images/vpreview_center.png";s:10:"dimensionW";s:1:"0";s:10:"dimensionH";s:1:"0";s:3:"rss";s:2:"on";s:4:"atom";s:2:"on";}}]]></wp:meta_value>
		</wp:postmeta>
		<wp:postmeta>
			<wp:meta_key>_podPressPostSpecific</wp:meta_key>
			<wp:meta_value><![CDATA[a:6:{s:15:"itunes:subtitle";s:15:"##PostExcerpt##";s:14:"itunes:summary";s:15:"##PostExcerpt##";s:15:"itunes:keywords";s:17:"##WordPressCats##";s:13:"itunes:author";s:10:"##Global##";s:15:"itunes:explicit";s:7:"Default";s:12:"itunes:block";s:7:"Default";}]]></wp:meta_value>
		</wp:postmeta>

Unfortunately the URL reference isn't to a full URL, it can be a relative path to some part of the wordpress filesystem, and I haven't figured out a fool-proof way of getting the file without transferring them first. PodPress also doesn't verify the file so I ran into a problem where the blog poster would enter a filename with different case from the actual file name in the URL. Basically the source URLs aren't validated in PodPress.

I could add an option to try and pull the file if it's got a full URL instead of assuming they are located somewhere locally, I'll look into that.

I've also just found that in some cases the media info is doubly-serialized, lord knows why or how this happens, so I've modified the code to check for this.