Automattic
[Tracking] Publicize: Adding features to publishing threads to Twitter
The ability to publish threads to Twitter via Publicize is being developed in #16699.
This issue is for keeping track of potential features that could be included in the future, ranging from "required for initial release", through to "speculation on nice features to have in the indeterminate future". Most of these features will likely need to be spun out in to their own issues, once they're picked up.
A feature listed here doesn't guarantee the order that it'll be built, or even if it will be built at all. Everything here should be treated as a speculative brain dump.
Must Have for Initial Release
- [x] Size Limits: This feature could turn really spammy, we should warn the author when they're about to publish a large thread (say, more than 20 tweets), and prevent publishing oversized threads (say, more than 100 tweets). Future features (in particular, adding to threads after publishing, and rate limiting) could potentially lift these hard limits, as they help provide a more natural flow to the thread. (#17352)
Nice to Have for Initial Release
- [ ] Handle words that are too long for a single tweet.
- [ ] Performance: Only send blocks for parsing when the tweet they're in may have changed.
- [ ] Performance: Don't re-parse blocks when the changes since last parse won't have caused boundary changes.
Support for Blocks
- [ ]
core/cover - [ ]
core/media-text - [ ] VideoPress
core/embed: We can upload the actual video file, rather than just treating it as yet another embed. - [ ]
jetpack/amazon - [ ]
jetpack/calendly - [ ]
jetpack/eventbrite - [ ]
jetpack/map - [ ]
jetpack/opentable - [ ]
jetpack/pinterest - [ ]
jetpack/slideshow - [ ]
jetpack/tiled-gallery
Potential v2/v3/v_n_ features
- [ ] Plugin support: While it's easy enough to add appropriate filters so a 3rd-party block can add their own support in the parser, it's going to be challenging to then pass that information back to WPCOM for inclusion in Publicize, where the 3rd-party block probably isn't installed. (#17295)
- [ ] Tweet numbering: While tweets are currently not numbered in the thread, it'd be nice to add the ability to number them, and potentially have different numbering formats.
- [ ] Customising the final message: The last message in the thread links back to the post where it was published, but there's no option to customise its appearance, or whether or not it's included.
- [ ] Complex blocks: The parser currently just grabs all supported blocks in the order they appear, and generates the thread from them. More complex blocks (particularly nested blocks) may wish to control this behaviour, potentially changing the order that its child blocks are included, or removing blocks that it doesn't want tweeted.
- [ ] Adding to threads after publication: If someone edits their post to add additional content, they may wish to have that additional content appended to the thread, too. This is particularly valuable for mega-threads, which are usually added to over the course of weeks or months.
- [ ] Rate Limiting: Twitter has hourly and daily posting limits. While the size limits we impose make it harder to run into Twitter's limits, it's not impossible. For high volume publishers, they could control the rate at which their threads are tweeted.
- [ ] Linking Blocks With Tweets: After a tweet is published, we could potentially store which blocks contributed to that tweet, which would allow for some interesting reader-facing features to be developed. For example, the theme could add a "Share to Tweet" button for every paragraph, which, instead of just quoting the paragraph in the tweet text, it retweets the actual tweet. (related: #7359)
- [ ] Inline Images:
RichTextfields allow inline images to be inserted. Currently, these are stripped out, but there's a potential case for tweeting these images. It would probably want to restrict the size of the images, though. A tiny image would be no use attached to a tweet. - [ ]
core/codeSupport: While it's not possible to post literal code to Twitter, there are some interesting potential workarounds: the code could be uploaded to a Gist, or a screenshot could potentially be generated using Carbon.
We've had a request via Twitter for tweets to also include image captions. I've confirmed at the moment only the image itself is included in the tweet, not the caption.
Twitter doesn't really have the concept of image captions, there wasn't a good way to make it consistently translate across.
The example you linked to is potentially an exception: when the content contains a bunch of image blocks one after the other, each new image will intentionally be in a new tweet. Putting the caption for each image as the tweet content would be a logical choice when there's no other text to include.
