Always send comment_status when creating a post#25492
Draft
Always send comment_status when creating a post#25492
Conversation
When creating a new post, the app previously skipped sending comment_status and ping_status if the discussion settings matched the app's hardcoded default (comments and pings enabled). This meant the server's own default was used instead of the user's explicit choice, which could result in comments being disabled on sites where the server default differs from the app's. Fixes #25480
Collaborator
Generated by 🚫 Danger |
Verifies that create-post encoders (both XML-RPC and WP.com REST) always include discussion settings in the encoded output, and that update-post encoders only include them when explicitly set.
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 32007 | |
| Version | PR #25492 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 5473c55 | |
| Installation URL | 5h2muoqvne5fg |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 32007 | |
| Version | PR #25492 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 5473c55 | |
| Installation URL | 6jm5cbjf8v5ng |
Contributor
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
- BlogServiceRemoteCoreREST.mapSiteSettings now maps defaultCommentStatus and defaultPingStatus from the Core REST API (/wp/v2/settings) instead of setting them to nil. This ensures self-hosted sites' discussion preferences are synced to the device. - Blog.createPost() now initializes allowComments from the blog's synced settings (falling back to true if settings haven't been synced yet), so new posts respect the server's default_comment_status. - Add tests for the discussion settings mapping.
WordPress core's wp.editPost defaults comment_status to "closed" when the field is omitted (Trac #36462). This means any post update that doesn't explicitly include comment_status — even a simple status change from draft to publish — silently disables comments. Fix this by consulting the blog's synced discussion settings in PostRepository._sync and always including them in update parameters. The values come from BlogSettings.commentsAllowed and pingbackInboundEnabled, which are synced from the server's default_comment_status and default_ping_status. Also fix BlogService.m to not overwrite discussion settings with false when RemoteBlogSettings returns nil (since [nil boolValue] == NO in Obj-C), and initialize allowPings from blog settings in createPost().
The XML-RPC `wp.getOptions` response includes `default_comment_status` and `default_ping_status`, but the app never mapped them. This meant pure XML-RPC self-hosted sites (no application passwords, no Jetpack) had nil discussion defaults, causing `Blog.createPost()` to always fall back to the hardcoded `true` regardless of the site's actual setting.
Adds a Swift extension on BlogSettings that applies a SiteSettingsWithEditContext directly, giving callers a clean path from the Rust networking layer to Core Data without routing through the ObjC RemoteBlogSettings intermediary.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes comments being disabled on newly created posts on self-hosted WordPress sites.
Root Cause
The create-post encoders (
RemotePostCreateParametersXMLRPCEncoderandRemotePostCreateParametersWordPressComEncoder) skipped sendingcomment_statusandping_statuswhen the discussion settings matched the app's hardcoded default (.default= comments and pings enabled). This triggered a WordPress core bug (Trac #36462):comment_status(because settings match.default)wp.newPostinternally creates an auto-draft viaget_default_post_to_edit(), then updates it with the provided datawp_insert_post()sees an existingIDfrom the auto-draft, treats this as an update, and defaultscomment_statusto"closed"when the field is omitteddefault_comment_statusis"open"This was confirmed by testing against a clean WordPress 6.9.4 Docker instance and verified against the WordPress 6.9 source on GitHub:
wp.newPostwithoutcomment_status→closed(bug)wp.newPostwithcomment_status=open→open(correct)wp.editPostwithoutcomment_status→ preserved (safe —wp.editPostandwp_update_postboth merge existing data before callingwp_insert_post)Note:
ping_statusis not affected by this bug —wp_insert_post()always callsget_default_comment_status($post_type, 'pingback')for pings regardless of create/update, but it hard-codes"closed"forcomment_statuson updates.Changes
comment_statusandping_statusin both XML-RPC and WP.com REST create encoders, removing the guard that skipped them when they matched.defaultdefault_comment_statusanddefault_ping_statusfrom the self-hosted REST API (/wp/v2/settings) so new posts are initialized with the site's actual defaultsdefault_comment_statusanddefault_ping_statusfrom XML-RPC (wp.getOptions) — previously these keys were returned by WordPress but never mapped, so pure XML-RPC self-hosted sites always fell back to the hardcoded defaultPostRepository) as a defensive measure, since WordPress core's update path also defaults to"closed"whencomment_statusis omittedBlogService.mwhere[nil boolValue]was silently convertingcommentsAllowed = niltofalseFixes #25480
Test plan