Remove WordPressData's WordPressUI and WordPressSharedUI dependencies

[jkmassel]

Description

WordPressData is a Core Data model layer, but it depended on two UI modules — WordPressUI and WordPressSharedUI. Neither dependency was necessary. This removes both.

Note

Two commits, reviewable independently: Remove dead WordPressUI import from WordPressData, then Split RichContentFormatter out of WordPressSharedUI.

• Delete the unused import WordPressUI from ManagedPerson and drop WordPressUI from WordPressData's package dependencies.
• Split RichContentFormatter so its platform-independent text methods move down to WordPressShared, and drop WordPressSharedUI from WordPressData's package dependencies.

Splitting RichContentFormatter

RichContentFormatter sanitizes post and comment HTML — stripping forbidden tags and inline styles, normalizing paragraphs, tidying Gutenberg galleries. It's plain String → String text work, but it lived in WordPressSharedUI, so everything that used it — including WordPressData — pulled in the UI layer.

Only two of its methods actually need that layer: resizeGalleryImageURL reads the screen (UIScreen.main) to size gallery images and calls PhotonImageURLHelper from WordPressSharedObjCUI, and formatContentString chains through it. Those two move to a new RichContentFormatter+DisplayPipeline.swift in WordPressSharedUI, as an @objc extension on the class. The other eight methods and the RegEx table move to WordPressShared.

ObjC callers see no change. RichContentFormatter is still one @objc class. CommentService.m already @imports both WordPressShared and WordPressSharedUI, so removeTrailingBreakTags (now in WordPressShared) and formatContentString (the WordPressSharedUI category) both resolve. WordPressData's ReaderPost+Mapping gets the pure methods from WordPressShared, which it already imported.

The tests move with the code: RichContentFormatterTests is now WordPressShared-only and runs on macOS under swift test; the single gallery-resize test stays iOS-only in the new RichContentFormatterUITests.

The WordPressUI import was dead

ManagedPerson was the only file in WordPressData importing WordPressUI, and the one symbol that looked like it needed it — AvatarURL(url:)?.canonicalURL — belongs to the Gravatar SDK, which the file already imports directly. WordPressUI supplied nothing.

What I considered

The alternative was to move the whole class to WordPressShared and gate resizeGalleryImageURL behind #if canImport(UIKit), giving WordPressShared a conditional dependency on WordPressSharedObjCUI for the Photon helper. Rejected: that pushes a UI-only ObjC dependency down into the base shared module — a layering inversion in the other direction — and scatters #if scaffolding through shared code. Keeping the screen- and Photon-dependent methods in the UI layer is where they belong. (WPImageURLHelper, the other helper resizeGalleryImageURL uses, was already in WordPressShared.)

Not in this PR

This removes WordPressData's two direct edges to the UI modules. It does not make WordPressData build on macOS on its own — it still imports UIKit and MobileCoreServices directly, and pulls WordPressSharedUI transitively through FormattableContentKit on iOS. Those are separate changes.

Testing instructions

Verified locally:

• swift test --filter RichContentFormatterTests (macOS host) — 7 text-formatting tests pass. They previously couldn't run on macOS (excluded because the file imported WordPressSharedUI); they're now in the cross-platform set.
• swift build --build-tests (macOS host) — WordPressShared compiles with the moved code.
• xcodebuild -scheme WordPressData -destination 'generic/platform=iOS Simulator' build — BUILD SUCCEEDED, with WordPressSharedUI no longer in WordPressData's dependency graph.
• WordPressSharedUI builds with the new extension; formatContentString and resizeGalleryImageURL appear in the generated WordPressSharedUI-Swift.h, so the @objc cross-module category is visible to ObjC.

Verified at runtime (Jetpack, iOS 26 simulator). The sanitization logic is a byte-identical git mv, so its behavior is covered by the unit tests above — these two checks confirm the thing the move actually changes: that the relocated class and its cross-module @objc category link, load, and dispatch in the running app.

• Reader ingestion — WordPressData → WordPressShared (Swift). Opened a post whose content carries a Jetpack tiled gallery, a grid built entirely from inline flex-basis styles the app has no CSS fallback for. It renders as a single full-width column (24 images, each at the full content width) — the inline styles are stripped — so removeInlineStyles resolves and runs from its new module. (toadilymagical.wordpress.com post 347)
• Comment path — ObjC CommentService → the cross-module @objc formatContentString. Opened a post with a comment; loading it ran mergeHierarchicalComments → sanitizeCommentContent → [RichContentFormatter formatContentString:isPrivateSite:] and the comment rendered, with no unrecognized-selector crash. This confirms the @objc category — defined in WordPressSharedUI on the class that now lives in WordPressShared — registers and dispatches at load time, the one behavior a successful compile implies but doesn't prove. (WordPress.com News "WordCamp US 2026" post)

[dangermattic]

	2 Warnings
⚠️	Modules/Package.swift was changed without updating its corresponding Package.resolved. If the change includes adding, removing, or editing a dependency please resolve the Swift packages as appropriate to your project setup (e.g. in Xcode or by running swift package resolve). If the change to the Package.swift did not modify dependencies, ignoring this warning should be safe, but we recommend double checking and running the package resolution just in case. .
⚠️	Package.swift was changed without updating its corresponding Package.resolved. If the change includes adding, removing, or editing a dependency please resolve the Swift packages as appropriate to your project setup (e.g. in Xcode or by running swift package resolve). If the change to the Package.swift did not modify dependencies, ignoring this warning should be safe, but we recommend double checking and running the package resolution just in case. .

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	33405
	Version	PR #25832
	Bundle ID	org.wordpress.alpha
	Commit	2473db9
	Installation URL	58ceofc2ftspg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	33405
	Version	PR #25832
	Bundle ID	com.jetpack.alpha
	Commit	2473db9
	Installation URL	2lmc0p9pkr5fo

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.