janboddez/share-on-mastodon

Custom Post Type posts again when updated

Closed this issue ยท 4 comments

I use a custom post type to post photos on my site, which then get posted to mastodon automatically.
Problem:

  • the posts seem to get posted again and again when I update the post in WP (they get posted several times, so possibly even on autosaves)
  • the post meta with the ID (to indicate it had been shared before) does not get saved for this post
  • the other post meta of the plugin _share_on_mastodon: 1 is there as it should

I also use a post category for "notes" and for normal blogposts that get posted automatically, those work fine and also have the IDs saved.

Here's the filter for the format, that I use on my site:

/**
 * Customize Posts for Mastodon Sharing
 */
function claudio_customize_mastodon_post( $status, $post ) {

	// Share content + url, if it is a photo post_type
	if ( $post->post_type == 'photos' ) {
		$status = wp_strip_all_tags( $post->post_content );
		$status .= "\n\n๐Ÿ”— " . get_permalink( $post->ID );
		return $status;
	}

	// Share only the post content if it is in category "note"
	if ( has_category( 'notes', $post ) ) {
		$status = wp_strip_all_tags( $post->post_content );
	}

	// Share title + tags + url, if it is a regular post
	else {
		$status = wp_strip_all_tags( get_the_title( $post->ID ) );
		$tags = get_the_tags( $post->ID );
		if ( $tags ) {
			$temp = '';
			foreach( $tags as $tag ) {
				$temp .= '#' . preg_replace( '/\s/', '', $tag->name ) . ' ';
			}
			$status .= "\n\n" . trim( $temp );
		}
		$status .= "\n\n๐Ÿ”— " . get_the_permalink( $post->ID );
	}

	return $status;

}
add_filter( 'share_on_mastodon_status', 'claudio_customize_mastodon_post', 10, 2 );

Any ideas what I'm doing wrong?

I think the issue is we check post_type_supports( $post->post_type, 'custom-fields' ) before we save the URL/ID (or an error), whereas we don't do that check before saving _share_on_mastodon.

I.e., you could probably solve this by explicitly adding custom field support to your CPT.

And I think it's safe to remove this check from the plugin (as post meta gets saved even if the CPT "does not support" custom fields, i.e., post meta, but that's going to be for the next version.

According to https://developer.wordpress.org/reference/functions/post_type_supports/, post_type_supports() is used all over the place, but (probably) not when saving post meta. It should be safe to remove. (I mean, it's kind of obvious, _share_on_mastodon does get saved okay.)

Still, it doesn't hurt to explicitly declare support for custom fields (i.e., post meta) when defining your CPT. Other plugins might run similar checks.

Quick example:

register_post_type( 'my_custom_post_type', array(
  'labels'            => array(
    // And so on ...
  ),
  'public'            => true,
  'has_archive'       => true,
  'show_in_nav_menus' => true,
  'supports'          => array( 'author', 'title', 'editor', 'thumbnail', 'custom-fields' ), // Notice the `'custom-fields'` there.
  'capability_type'   => 'post',
  'map_meta_cap'      => true,
  // Etc.
) );

@crimann (What's hopefully the fix was) delivered in v0.10.1.

(Unrelated, but me know if you have update issues, not sure what happened on one of my sites but I had to deactivate before it would update. Or maybe it just took a bit of time for WordPress's servers to get up to speed.)

Ah nice catch โ€“ makes sense.

I'll add the custom fields support just in case, but the update fixed it โ€“ Thanks!