hgh001

The solution was actually further down the chain. The mime type of the image was not resolving to the correct extension, thus the file type check failed on adding the post thumbnail.

The fix for missing auto-generated thumbnails is as follows:

Change the get_image_type function in class-backend.php as follows:

private static function get_image_type( $filename ) {
	if ( function_exists( 'exif_imagetype' ) ) {
		return exif_imagetype( $filename );
	} else {
		$img = getimagesize( $filename );
		if ( !empty( $img[2] ) ) {
			return $img[2];
		}
	}
	return false;
}

Note removal of the call to image_type_to_mime_type.

I experienced this problem after upgrading WordPress as well. (Strange since the image type determination uses PHP library functions, unless prior versions of WordPress were doing something different?)

Anyhow, the fix seems to be to change the get_image_type function in class-backend.php as follows:

private static function get_image_type( $filename ) {
		if ( function_exists( 'exif_imagetype' ) ) {
			return exif_imagetype( $filename );
		} else {
			$img = getimagesize( $filename );
			if ( !empty( $img[2] ) ) {
				return $img[2];
			}
		}
		return false;
	}

Note removal of the call to image_type_to_mime_type.

Some FVP features stopped working for me after upgrading to WordPress 4.5. Our theme uses the API to embed videos, i.e. we are not using auto-replace from the post thumbnail (‘Manual’ setting in the Dashboard). In this scenario, the video embedding seems to work fine.

However, if you are using any of the auto-replacement settings I can foresee issues if your blog is not able to generate thumbnails. We are no longer able to auto-generate thumbnails from YouTube. From my current diagnosis, this is due to new security settings for allowed file types. The plugin downloads the thumbnail image from a URL, which is saved to a temporary file (*.tmp) before being added as the post thumbnail. My install is giving an error message

Sorry, this file type is not permitted for security reasons

I am continuing to work on this and will post a solution here if I find one.

Hi Jan,

Thanks for the addition info over email. Just to confirm, my test case now works in the new version 1.9 of the plugin. I am exporting custom types and fields settings from one blog to another in the same multisite install.

I noticed that the problem field
<set_value>C&ocirc;te d&Ivoire</set_value>
is now encoded as
<set_value>C?te d'Ivoire</set_value>

I noticed that the import feature allows you to set the encoding but the export does not. I suppose that as long as I have everything in UTF-8 (as it should be) this is fine.

Just to note this resolved itself in the latest version of WordPress (4.4.1) and plugin (1.8.11).

I was finally able to find the problem – a failed update of wp-includes/rewrite.php which contained the class definition in my prior version. Why this file in particular was not correctly updated, I do know, but I was able to finally detect the issue by running the upgrade on a clean copy of the code and then checking the diff.

I would like to “upvote” this as well. I wrote my own shortcode function based on yours to include this and some other improvements in the attribute handling (see this helpful thread).

See what you think (and feel free to use all or some):

function my_custom_post_widget_shortcode( $atts ) {
    $args = shortcode_atts( array(
        'id' => '-1',
        'slug' => '',
        'class' => 'content_block',
        'suppress_content_filters' => 'no',
        'title' => 'no',
        'title_tag' => 'h2'
    ), $atts, 'custom_post_widget_shortcode' );

    $suppress_content_filters = filter_var($args['suppress_content_filters'], FILTER_VALIDATE_BOOLEAN);
    $show_title = filter_var($args['title'], FILTER_VALIDATE_BOOLEAN);

    $query_args = array(
        'post_type' => 'content_block'
    );

    if ( !empty($args['slug']) ) {
        $query_args['name'] = $args['slug'];
    } else {
        $query_args['p'] = $args['id'];
    }

    $output = "";
    $content_post = get_posts( $query_args );

    foreach( $content_post as $post ) :
        $output .= '<div class="'. esc_attr($args['class']) .'" id="custom_post_widget-' . $id . '">';
        if ($show_title) {
            $output .= '<'.$args['title_tag'].'>';
            if ($suppress_content_filters) {
                $output .= $post->post_title;
            } else {
                $output .= apply_filters('the_title', $post->post_title);
            }
            $output .= '</'.$args['title_tag'].'>';
        }
        if ( $suppress_content_filters ) {
            $output .= $post->post_content;
        } else {
            $output .= apply_filters( 'the_content', $post->post_content);
        }
        $output .= '</div>';
    endforeach;

    return $output;
}

For anyone who would like to use this, simply override the shortcode in your own plugin or theme. I found the ‘wp_loaded’ action worked fine, but will admit there may be a better choice – you just have to make sure the plugins are loaded and activated:

function override_cpw_shortcode(){
    add_shortcode( 'content_block', 'my_custom_post_widget_shortcode' );
}
add_action('wp_loaded', 'override_cpw_shortcode');

Yes, which is why I would like to avoid it. I was hoping for some help in figuring out why the rewrite rules are not registered at the correct time in the first place.

I would also like to point out that adding

add_action('init', 'flush_rewrite_rules', 100);

makes them work, but this is poor form.

Yes, that is perfectly clear, but I fail to see what that has to do with enabling rewrites for custom post types.

Kindly reconsider my question before marking this resolved.

Let me clarify – I believe what I am trying to achieve is not mutually exclusive.

For the CPT and taxonomies, I want the following permalink structure:
[common_slug]/[cpt_slug]/[post_name]
[common_slug]/[tax1_slug]/[tax_term]
[common_slug]/[tax2_slug]/[tax_term]

For ‘regular’ posts, obviously I have the aforementioned permalink structure configured.

I have verified that the following params are being passed from register_post_type and register_taxonomy to WP_rewrite (via a quick var_dump):

add_permastruct -->common_slug/tax1/%tax1%

array (size=5)
'with_front' => boolean false
'hierarchical' => boolean false
'ep_mask' => int 0
'enabled' => string '1' (length=1)
'slug' => string 'common_slug/tax1' (length=17)

add_permastruct -->common_slug/tax2/%tax2%

array (size=5)
'with_front' => boolean false
'hierarchical' => boolean false
'ep_mask' => int 0
'enabled' => string '1' (length=1)
'slug' => string 'common_slug/tax2' (length=5)

add_permastruct -->common_slug/cpt_slug/%cpt%

array (size=7)
'enabled' => string '1' (length=1)
'slug' => string 'common_slug/cpt_slug' (length=22)
'with_front' => boolean false
'feeds' => boolean false
'pages' => boolean false
'ep_mask' => int 1
'feed' => boolean false

As far as I can tell this is correct. However, the corresponding rewrite rules are not included in WP_Rewrite if I inspect it at various points. I believe they should be. Please let me know if I am missing something or there is another setting I should look into.

Meanwhile, I patched it by adding the following filter:

function my_eo_format_datetime($datetime, $end, $format, $post_id, $occurence_id) {
    // Return unchanged if string, return copy of object otherwise
    if (is_string($datetime)) {
        return $datetime;
    }
    else {
        return clone $datetime;
    }
}
add_filter('eventorganiser_get_the_end', 'my_eo_format_datetime');

Thanks for the tip leading to this!

Thanks for the quick response, Stephen! Any thoughts on timing of that update? ??

An additional note: I have further noticed that the date shift only occurs when the widget occurs on a page together with a shortcode list including the same events.