Use the new Jetpack Social connection on AbstractPost#25587
Use the new Jetpack Social connection on AbstractPost#25587crazytonyli wants to merge 9 commits into
Conversation
Bridge the JetpackSocial v2 connection model to the WP.com REST v1.x post-editing path by reading and writing per-connection sharing state as `_wpas_skip_publicize_<connection_id>` and `_wpas_mess` post metadata.
Source the `_wpas_skip_publicize_*` and `_wpas_mess` upload entries from the post's metadata container and stop emitting them from the keyring-keyed PostHelper builder, so the v1.x create/update requests carry the connection scheme written by the new bridge.
Seed the connection_id-keyed draft from the post metadata when the post is Publicize-eligible, and write it back through the metadata container on save. When there is no draft, leave the existing publicize metadata untouched so a user's disabled connections are not silently re-enabled.
Resolve a SiteSocialConnectionsService for eligible blogs and return a v2SocialSharing binding so the shared SwiftUI section renders in the AbstractPost editor, replacing the keyring-keyed pre-publish UI. Strip the draft when no connections service is available; keep it for private posts.
Mark the superseded keyring-keyed publicize properties, methods, and UI as deprecated now that post editing keys per-connection state by connection_id in post metadata. Left in place to avoid a Core Data migration. Also retire the obsolete sharing-limit auto-disablement, which Jetpack Social no longer enforces.
Generated by 🚫 Danger |
crazytonyli
changed the title
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 32537 | |
| Version | PR #25587 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | abe6007 | |
| Installation URL | 6e5kemshrqu2g |
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 32537 | |
| Version | PR #25587 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | abe6007 | |
| Installation URL | 4hbuemf06v4oo |
| static let messageKey: PostMetadataContainer.Key = "_wpas_mess" | ||
|
|
||
| static func publicizeEntries(in container: PostMetadataContainer) -> [[String: Any]] { | ||
| container.values.filter { entry in |
There was a problem hiding this comment.
Should we be testing _wpas_skip_ and _wpas_skip_publicize_?
There was a problem hiding this comment.
_wpas_skip_publicize_ is tested, but I decided not to care about _wpas_skip_ because it's a legacy meta key that no client (*) writes, not since the _wpas_skip_publicize_ was introduced 3 years ago.
Most importantly, there are complications around handling it properly. The id in _wpas_skip_<id> is "keyring id", which is not the same as the "connection id" in _wpas_skip_publicize_<id>. We'd need to map them if we want to handle _wpas_skip_ properly.
(*) By "client", I mean the mobile apps, Jetpack plugin, etc.
There was a problem hiding this comment.
We probably don't need to map the ids. I'll explore another way to handle _wpas_skip_<keyringID>.
There was a problem hiding this comment.
Is that part of this PR, or a subsequent one?
|
|
||
| enum PostSocialSharing { | ||
| static func isEligible(for post: AbstractPost) -> Bool { | ||
| post is Post && post.blog.dotComID != nil && post.blog.supports(.publicize) |
There was a problem hiding this comment.
I think we also need to check the feature flag here?
There was a problem hiding this comment.
I forgot to mention that I intend to remove the feature flag.
There was a problem hiding this comment.
Should the removal be part of this PR?
There was a problem hiding this comment.
It'd be a separate PR. In this PR, I also marked many no longer used APIs as deprecated (see 5a1fb6a), which will be removed in a future cleanup PR.
Posts written by older clients carry legacy skip rows that the backend still ORs into the publish-time skip decision, so ignoring them showed stale connections as enabled and made re-enabling impossible. Mirror the backend instead: probe each connection's keyring and service key shapes when reading, pin same-keyring siblings before clearing a shared legacy row, and zero cleared rows on save. The keyring ID comes from the v2 connections payload, so no Core Data publicize state is involved.
…igrate-to-jetpack-social # Conflicts: # WordPress/Classes/ViewRelated/Post/PostSettings/PostSettings.swift
4 participants
Note
I recommend reviewing by commits. The first commit is pure code format changes and can be ignored.
Description
The new JetpackSocial module was used in the Custom Posts module. This PR integrates it into the
AbstractPostediting process. That means we'll replace the existing implementation (using mix of keyring and connection based endpoints) with pure connection based endpoints.I think this should resolve most of the existing Jetpack Social issues. I'd need to dig into the backlog to be sure, though.
Testing instructions
Log in to your WordPress.com account, try the "Share to social media" setting on editing posts.