janboddez / share-on-mastodon

Easily share WordPress posts on Mastodon.
https://jan.boddez.net/wordpress/share-on-mastodon
GNU General Public License v3.0
39 stars 5 forks source link

Customizing the post/toot #53

Closed rfischmann closed 1 year ago

rfischmann commented 1 year ago

Hi, @janboddez! Congrats and thank you for your work on this plugin.

We've just began using it and everything's looking good, however I have an important feature request to make: allow us to customize the post/toot if needed.

Whenever we post new articles on our site, we like that it's published using the default format (%TITLE% %URL% — with the featured image, of course), however it's very common that we have to update articles and we like to post about it on all our social networks. When we do that, we don't use the original title again — but a custom message about the article's update instead, with its URL.

So, the idea would be to have a checkbox that allowed us to edit the post/toot when needed, instead of using the default format every time. OneSignal's push notifications plugin does that: https://d.pr/i/dwPo6p and https://d.pr/i/b7gSwm

Cheers!

janboddez commented 1 year ago

This is a tricky one. It's definitely possible to update the "toot format" (various examples can be found at https://jan.boddez.net/wordpress/share-on-mastodon#share_on_mastodon_status), but ... doing so would affect new statuses as well.

And the way "unlinking" works is precisely that it deletes any proof of earlier "toots," so there's no way, in a share_on_mastodon_status callback function, to tell whether you're dealing with a "repost" or with a "fresh post."

rfischmann commented 1 year ago

I'm not into those technicalities, @janboddez, but on my understanding either you're able to repost or you want to make a fresh new, custom post that is indeed unlinked from the original one.

janboddez commented 1 year ago

Since the $post object is passed to the callback function, it is possible to check, e.g., if a post is x days old (just an example). So you could define two formats (or stick with the default, even, if this condition is not met), one for new posts, one for posts that were published, well, in the past.

add_filter( 'share_on_mastodon_status', function( $status, $post ) {
  if ( strtotime( $post->post_date ) >= ( time() - DAY_IN_SECONDS ) ) {
    // Post is under a day old. Stick to default format.
    return $status;
  }

  // In all other cases.
  $status = 'My custom status'; // Docs contain various examples of how to modify.
  return $status;
}, 10, 2 );

Or something (I didn't get around to testing this).

rfischmann commented 1 year ago

Thanks, @janboddez, but that's not the idea and it has nothing to do with how old the post is. Sometimes we edit and want to share an update to our social networks only minutes after the post is originally posted, sometimes days or weeks. It doesn't really matter.

The idea was for it to work the same way I showed an example from OneSignal, in which we have an interface inside the post editor that allows us to enable a checkbox and then customize the post/toot if needed/wanted for a new share.

crimann commented 1 year ago

I had a somewhat similar idea and found this issue so I thought it could fit here as well.

In my case, from time to time I would like to be able to override the text that is posted to mastodon for a post, but really only for this one post. Maybe this could work in rfischmanns case as well, to post the same post again when it's updated...

janboddez commented 1 year ago

Yes, that would be an option. If I were to add it, though, I would like to eventually make use of something like https://developer.wordpress.org/block-editor/reference-guides/slotfills/plugin-pre-publish-panel/.

But the meta box could be a temporary workaround.

if text field is empty, it falls back to the defined "format" for this post/category

Definitely, although I would always have the filter overrule whatever's going on here. Or, better yet, extend the filter hook, so that developers could themselves decide what to do.

morphtown commented 1 year ago

A little more detailed information about the usage of the filters would be helpful. class-post-handler.php around line 215 seems to be the place to look for. Is it?

janboddez commented 1 year ago

Not sure what the question is. You should never adapt plugin files directly (that's why we have filters).

You could do a search for apply_filters or do_action to find all hooks, but (nearly) all of them are described in the documentation, with code examples.

class-post-handler.php around line 215 seems to be the place to look for. Is it?

janboddez commented 1 year ago

Meanwhile, I've done some experimenting with an additional meta field that could be used to overwrite the default message just once (its contents would be deleted after posting the status).

Can always port it to Gutenberg in the future.

janboddez commented 1 year ago

I also played around with Gutenberg's PrePublishPanel and it's too easy to dismiss/overlook. A separate sidebar panel/tab/whatever it's called is probably the way to go (eventually).

The "problem" with meta boxes and Gutenberg is their values don't get updated until after all of the publish hooks have already run (they'll then run a second time). This is not the case for the classic editor.

Which isn't an issue when you first publish a post (it'll only cross-post to Mastodon on the second run, as the checkbox value will only be "seen" then).

But it is, or rather, was, an issue when you then "unlink" the existing status and modify its contents. As soon as you click "Update," it will again cross-post the default message (it won't have "seen" the custom message). Now, I've "fixed" this by also disabling the checkbox as soon as you "unlink" an existing Mastodon status. So I guess it should work again. I'll do some testing later on.

If not, I'll make this a "classic editor"-only feature.

janboddez commented 1 year ago

Which isn't an issue when you first publish a post (it'll only cross-post to Mastodon on the second run, as the checkbox value will only be "seen" then).

It is, though, when "Share always" is enabled. The checkbox check will be skipped and the custom status meta field won't have been saved and the post will get shared "normally." :-(

janboddez commented 1 year ago

This feature is now part of version 0.14. Needs to be enabled from Settings > Share on Mastodon > Advanced.

May not work with the block editor when "Share Always" (either through the setting or via the older filter) is enabled. It should just work with the classic editor.

It won't work either if statuses are being set using the share_on_mastodon_status filter mentioned above. (One could of course adapt the filter's callback to append to, rather than override, the meta box status.)

I'll focus on a more Gutenberg-friendly approach in a next version.

"Shortcodes" (e.g., %title%, %url%, etc.) are currently not supported. Literal text only.

Contrary to what was mentioned before, the status box is not cleared after cross-posting was successful. (It is no longer used anyhow, but the information is kept around. That way, it can be edited further, when one decides to "share once more." To re-share, the previously saved link has to be "broken," also via the Share on Mastodon meta box, and the checkbox needs explicitly checked again. [The latter is a bit of a change also and prevents some block editor weirdness that had always been around.])

The block editor in general might behave somewhat weird. (It doesn't immediately refresh the meta box either, for instance, when a post was submitted. As said, next version.)

rfischmann commented 1 year ago

Thank you for your work on this, @janboddez! Will test it out soon.

janboddez commented 1 year ago

"Shortcodes" (e.g., %title%, %url%, etc.) are currently not supported. Literal text only.

This is now implemented as part of v0.15.0.

Tested rather extensively, in combination with both the block editor and the classic editor, and it seems to just work.

There is one potential super-rare edge case where it might not work (i.e., the plugin could ignore what's in the meta box) due to Gutenberg being, well, very weird. (This will eventually be addressed by a block editor-specific sidebar panel, but it'll initially be more limited than the "classic" meta box, so ... not the highest prio.)