Move WordPressData to the Modules package#25631
Open
crazytonyli wants to merge 13 commits into
Open
Conversation
Collaborator
Generated by 🚫 Danger |
Contributor
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 32574 | |
| Version | PR #25631 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | cd78310 | |
| Installation URL | 5cvb6c1gr841g |
Contributor
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 32574 | |
| Version | PR #25631 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | cd78310 | |
| Installation URL | 1mug6g7sfdfp8 |
When WordPressData was a dynamic framework, importing it implicitly exposed WordPressKit types to targets without a bridging header (the Keystone framework compile path). The Swift package module does not re-export its dependencies, so files using WordPressKit types need the explicit import.
Same implicit-visibility issue as the previous commit: these files use WordPressKit types but relied on the WordPressData framework exposing them transitively in the Keystone build. Found by sweeping app sources for WordPressKit type usage without an import, since the local Keystone build halts on a pre-existing Xcode 26.5 issue before reaching them.
…iftLint swift-format moves the opening brace to its own line when a long signature stays on one line, which violates SwiftLint's opening_brace rule. Multi-line parameter lists keep both tools happy.
crazytonyli
force-pushed
the
task/move-wordpress-data-as-module
branch
from
1f2c04f to
cd78310
Compare
jkmassel
approved these changes
Jun 12, 2026
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
4 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.
Note
I recommend reviewing this PR commit by commit. The changes are mostly moving code. The real code changes are pretty small.
Description
Mixing an Xcode framework target with SwiftPM modules duplicates symbols across binaries: WordPressData's package dependencies (WordPressKit, WordPressShared, etc.) were statically linked into both
WordPressData.frameworkand the app binary, which can cause the "Class is implemented in both" runtime issues. This PR moves WordPressData into the Modules package so it's statically linked once, like every other module.Main changes:
Modules/Package.swift. The Xcode targets and theXcodeTarget_WordPressData*shims are deleted, and theWordPressDatascheme points at the package, so the CI setup is unchanged.WordPress.xcdatamodeldis now a package resource, andBundle.wordPressDataresolves toBundle.module.@import WordPressData;, added toOTHER_SWIFT_FLAGSinCommon.xcconfigusing the same mechanism as the existing WordPressKit entries.Testing instructions
The biggest regression risk is Core Data store loading and migration at startup, since the compiled model moved into the package resource bundle. I verified both upgrade paths in the simulator: installing the trunk build over this branch's build keeps the existing store (same file, data intact), and upgrading from 26.7 (data model 157) runs the migration to 158 successfully with drafts preserved.