Publicize: Gutenberg integration missing

[c-shultz]

This issue is being created to consolidate discussion around integrating Publicize module with Gutenberg. I'll be working to address this issue.

Steps to reproduce the issue

Publish a post from Gutenberg with Jetpack setup and social accounts connected with Publicize.

What I expected

Here's the classic editor behavior that's missing with Gutenberg:

What happened instead

Publicize correctly publishes the post to all connected social accounts with Gutenberg, but there is no form provided in editor to know that Publicize is active and to edit post text.

Potential designs

@MichaelArestad proposes adding Publicize integration in one (or both?) of the following locations:

1. Gutenberg pre-publish view:
   
2. Gutenberg sidebar view (potentially with other Jetpack options down the road):
   

Proposal

I would propose taking a swing at number 1 above (add Publicize to the pre-publish view in Gutenberg) as a first iteration. At a minimum this affects the Publicize's ui.php. Gutenberg will also need hooks in place to enable this. Paging @gziolo on the best approach for this (and if there are any existing examples of this yet).

Enhancements

This may be a good chance to look at enhancing Publicize while we'll be touching it.

One concept I would like to explore is to report back the Publicize results after publishing a post. The post-publish view in Gutenberg could be a good place to list out which connections were shared to and provide links to the associated posts. This serves a couple purposes:

1. Immediate feedback to the user that Publicize is working correctly
2. Convenient for the user to open linked social posts so they can view/edit them.
   Post-publish view where the reporting could be added:
   

[jeherve]

Closing #7766 in favor of your issue.

[c-shultz]

I suggest closing WordPress/gutenberg#3264 in favor of this issue.

[gziolo]

We need to do some work on the Gutenberg side, too. See my comment here: WordPress/gutenberg#3264 (comment).

[c-shultz]

@MichaelArestad,

You mentioned a few different approaches on the design of this. I'm thinking of going with the pre-publish view in Gutenberg. For Publicize alone, this approach makes a lot of sense to me. But you may have other concerns that would push this towards a side bar?

I want to nail this down a little, so I can work with @gziolo to sort out the Gutenberg integration (see WordPress/gutenberg#3264)

What do you think?

[MichaelArestad]

@c-shultz I think for Publicize, post-publish will be the most useful place for it for our users. There isn't much precedent for post-publish in Gutenberg, but I think it's worth making the effort to try it out. I posted the mockups and mentioned you on them.

Here's the prototype for reference, but I highly recommend reading the post before jumping in.

[c-shultz]

Per @MichaelArestad and discussion elsewhere, there's a desire to make this happen through post-publish. I did some investigation about if this is possible and what will take. It was a little bit of rabbit hole, so please bear with me on the long post.

How things work right now:

Currently, when a user publishes (either from the classic editor, Gutenberg, or an API), the same sequence occurs:

1. The post is published (no really?):
   
   I hope you feel enlightened

2. The Publicize plugin hooks into an action and flags the post for publicizing:
   

3. WP.com then publicizing all posts that are flagged by Publicize

Challenges:

Using the post-publish flow moves the Publicize action to after Gutenberg publishes (as post-publish obviously implies). There's a couple challenges to making this work:

1. We'll need to not automatically publicize any post being published from Gutenberg (and preserve backwards compatible with the Classic Editor and API publishing)
2. We'll need a way to later publicize a post when/if the user decides to push the "Share" button

Proposal:

To address challenge number 1 (don't automatically publicize Gutenberg posts), we could extend the Gutenberg publish behavior to set a post-meta field right before actually publishing:

The Publicize plugin would then watch the post-meta field and not publicize any post coming from Gutenberg:

These two changes prevent automatic publicizing of posts coming from Gutenberg and maintain backwards compatibility.

For challenge number 2 (publicize a post at some point after it's already been published), there exists an undocumented end point in the wpcom/v2 REST api: wpcom/v2/sites/{site id}/posts/{post id}/publicize. Calypso uses this to publicize posts. This endpoint immediately publicizes the given post id with a provided message. The "Share" button action in the post-publish screen could trigger a call to this endpoint to publicize the post.

Current status:

I've duct-taped together some code to test out both proposals above. I was able to successfully disable publicizing of posts via Publicize's callback for the 'jetpack_published_post_flags' action. I was also successfully able to publicize a post from the blog after it was published using the WP.com REST API publicize endpoint: wpcom/v2/sites/{site id}/posts/{post id}/publicize. I authenticated the request with Jetpack's authentication token.

Open questions:

Overall, I need some guidance on if these solutions are seriously misusing anything:

• Is it reasonable to update a post-meta field with the wp REST API prior to publishing a post (and can Gutenberg be extended to allow for this)?
• I didn't see any precedent precedent for calling the WP.com REST api from Jetpack. Are there any potential pitfalls to doing this?

[georgestephanis]

Commenting to remind myself to follow up in more detail, but if we're already doing a post publish publicize process, perchance it would be possible to permit re-Publicize more easily for Professional plan purchasers?

[georgestephanis]

I'm unsure if it would be beneficial to multiple plugins (Yoast SEO as well, perhaps) to register pre-publish things that will pause publishing until they're completed (selecting publicize options or content reviews or the like) -- and if that functionality were available as something in core Gutenberg that plugins could hook into for JIT flows.

We'll also need to consider mobile app workflows, and what will happen to a post started in Gutenberg but finished in non-gutenberg editor. Would the meta key prevent it from getting publicized? Would it get publicized twice?

[c-shultz]

We'll also need to consider mobile app workflows, and what will happen to a post started in Gutenberg but finished in non-gutenberg editor. Would the meta key prevent it from getting publicized? Would it get publicized twice?

That's a good point, @georgestephanis. In the proposal, the meta key is added when the user pushes the final 'publish' button just before the real publish action is committed. In most cases, the meta key would only be added to posts that are immediately published, but there's a very real possibility something will happen on the client that will cause the meta key to be written and the publish action to fail. The later result is that, if the post is published from some place other than Gutenberg, the post will not be publicized. It's a corner case, but it's bound to happen.

Another similar approach that avoids this risk would to be move this sequence out of the client. Publicize could register a custom REST endpoint that does this on the backend. Gutenberg would need to route its publish action to this new endpoint (instead of the normal action). The new endpoint would then: (1) Set the meta key and (2) publish the post.

[georgestephanis]

Replacing the entire core publish endpoint is probably a bad idea as it would set a bad example for other plugins on how to do things -- if multiple plugins try to do this, they're then fighting over which one gets called, instead of using actions or filters as needed to modify the behavior collaboratively.

[c-shultz]

Replacing the entire core publish endpoint is probably a bad idea as it would set a bad example for other plugins on how to do things.

Ah, but I liked that idea. 😄.That makes sense though.

Over the weekend, I made a pass at creating the replacement publish endpoint. I'm going to pull the publish action out of it and go back to the approach of using the endpoint to write the meta key just before Gutenberg does it's normal publishing. I'm going to try handling the incomplete publish corner case mentioned above by writing a timestamp to the "publish_from_gutenberg" meta key value so it can expire after a short time in case the request to publish fails.

I think that should handle it pretty well without making it unnecessarily complex.

[gziolo]

Replacing the entire core publish endpoint is probably a bad idea as it would set a bad example for other plugins on how to do things -- if multiple plugins try to do this, they're then fighting over which one gets called, instead of using actions or filters as needed to modify the behavior collaboratively.

Agreed on that one. Hooks should be enough to handle it. There needs to be an easy way to detect if the request comes from Gutenberg powered editor. The old/classic editor doesn't use REST API.

[gziolo]

See also my latest comment related to the UI changes: WordPress/gutenberg#3264 (comment).

[kraftbj]

Noting that there is an API in Gutenberg now to extend the publish metabox: WordPress/gutenberg#6798

[boblmartens]

Any news on this?

[kraftbj]

@boblmartens No need to ask for updates. If there are any, they would be indicated here.

[markman641]

This needs to happen. reverting back to the classic editor for now.

[Hikage]

There was a lot of activity on this thread back in March, and now nothing. Why is this issue still open 7 months later? Does anyone have any workarounds? I'd like to adopt Gutenberg, but this and other issues are forcing me to revert to the classic editor.

[jeherve]

We've worked on adding Gutenberg support to Publicize here:
Automattic/wp-calypso#26389

The block is not yet part of Jetpack, but it will be ready by the time WordPress 5.0 is released. It will look a bit like this:

Until then, you should be able to use Publicize with Gutenberg, but you will need to revert to the classic editor for some of the Publicize settings unfortunately.

[jeherve]

Closing as this was implemented in Calypso:
https://github.com/Automattic/wp-calypso/issues?q=label%3A%22%5BGoal%5D+Gutenberg%22+publicize+is%3Aclosed+sort%3Aupdated-desc

[ms-studio]

So... the only way to edit posts with Jetpack Publicize is to use the Calypso desktop app?

[MichaelArestad]

@ms-studio Oh no! I can see how that looks like the case. It is available in Jetpack, WordPress.com, and the desktop app. We use Calypso to build the code that we use in all three places. Jetpack currently has Publicize and has since the 6.8 release. It's not perfect, but it works well. We have also iterated on it to improvement and those improvements will be shipped in the near future to make scheduled post + publicize flows a bit nicer. I hope this clears things up. Let us know how it works for you and what we can do to improve it.

[Alex9001]

I still don't see publicize settings on block editor posts in 2023. My websites that use classic editor have the option showing in the top right.

How it should look:

How it actually looks:

If I enable classic editor the field shows up. What gives? This issue is marked as closed. But I don't see that anything is resolved at all.

[jeherve]

@Alex9001 If you click on the Jetpack icon here, you'll see the Publicize options for the post:

You'll also see them in the Pre-publish panel, if you have enabled it.

You can read more about the feature here:
https://jetpack.com/support/jetpack-social/social-sharing-new-posts/