themps

Had the same problem. This fix worked for me. Thanks!

So…is there any hope this will be fixed at any point? the html strip function isn’t doing anything.

Thanks!

I think i might have found it in mtphr_dnt_general_settings in the wp options database.

It also disappeared from my wp-login page as an option.

I’m getting this error now too after it was already working fine for months. Would you mind listing your plugins so I can see if there is some overlap with my plugins? I’m guessing there is an incompatibilty somewhere and it’s probably one of the popular ones.

So I just checked the php in podcast-functions again. (I’m not a coder so bear with me)

It definately is supposed to be stripping out the html wp_filter_nohtml_kses is listed in the podcast functions. Which is a standard built into wordpress function. Is it possible SM isn’t using it correctly somehow?

Oh okay. So podcast-functions is still in use? That was first one I referenced with the code. It seems as though it’s trying to filter the html with use of wordpress’s wp_filter_nohtml_kses but the end result shows every html code in the description which then invalidates the feed. I wish I could just leave the desription as text but at this point it’s stuck in my presentation so it’s either no podcast or have only the audio on the page without the active content. I find it strange that it started happening all the sudden when it was working fine before. Any ideas? I’m fully willing to play guinea pig. I know how to restore if it goes south haha.

• This reply was modified 8 years, 1 month ago by themps.

It’s like wp_filter_nohtml_kses is broken?

Thanks Allen! So this is actually the itunes:summary part of the XML that I’m talking about. It worked fine and validated with the html previously then at the end of July (i think) it was being rejected by iTunes. I looked at the code and it looks like it is supposed to stripping html

‘podcast-functions.php’

// add itunes specific info to each item
function wpfc_podcast_add_item(){
	
	global $post;
	
    $audio = get_post_meta($post->ID, 'sermon_audio', 'true');
	$speaker = strip_tags( get_the_term_list( $post->ID, 'wpfc_preacher', '', ' & ', '' ) );
	$series = strip_tags( get_the_term_list( $post->ID, 'wpfc_sermon_series', '', ', ', '' ) );
	// Sermon Topics
	$topic_list = wp_get_post_terms( get_the_ID() , 'wpfc_sermon_topics' );
	$topics = false;
	if( $topic_list && count( $topic_list ) > 0 ) {
		$c = 0;
		foreach( $topic_list as $t ) {
			if( $c == 0 ) {
				$topics = esc_html( $t->name );
				++$c;
			} else {
				$topics .= ', ' . esc_html( $t->name );
			}
		}
	}

	$post_image = wp_get_attachment_image_src( get_post_thumbnail_id( $post->ID ), 'large' );
	$post_image = ( $post_image ) ? $post_image['0'] : null;
	//$enclosure = get_post_meta($post->ID, 'enclosure', 'true');
	

	$audio_duration = get_post_meta($post->ID, '_wpfc_sermon_duration', 'true');
	if ($audio_duration == '' ) $audio_duration = '0:00'; //zero if undefined
	?>
	<itunes:author><?php echo $speaker ?></itunes:author>
	<itunes:subtitle><?php echo $series ?></itunes:subtitle>
	<itunes:summary><?php wp_filter_nohtml_kses( wpfc_sermon_meta('sermon_description') ); ?></itunes:summary>
	<?php if ( $post_image ) : ?>
	<itunes:image href="<?php echo $post_image; ?>" />
	<?php endif; ?>
	<?php if ( $audio !== '' ) : ?>
		<enclosure url="<?php echo $audio; ?>" length="0" type="audio/mpeg"/>
	<?php endif; ?>
	<itunes:duration><?php echo esc_html( $audio_duration ); ?></itunes:duration>
	<?php if( $topics ) { ?>
		<itunes:keywords><?php echo esc_html( $topics ); ?></itunes:keywords>
	<?php } 
}

and also in the podcast-feed.php

So I take it I’m the only one that html is not being stripped out of the description and getting delisted from podcast stores and directories because the feed is not validating?

or can you still edit and it just saves it automatically?

shadiadi did you update to the latest version of Wordfence? I’ve noticed a great improvement in RAM usage. Wfasa spoke about it above….

Thanks Jeremy and Richard. They made an internal change and it’s working fine now.

Thanks!

Looks like the auto scan failed this morning. Back to square one.

i did submit the ticket 2 days ago….do you suppose it would be safe to whitelist that IP for now? I mean the odds of a brute attack from that particular IP on my site would be fairly low right?