Add site settings for third-party blocks and theme style gating#22785
Add site settings for third-party blocks and theme style gating#22785
Conversation
Generated by 🚫 Danger |
|
|
|
|
jkmassel
force-pushed
the
jkmassel/site-settings-rust
branch
3 times, most recently
from
540e9af to
d50de44
Compare
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
jkmassel
force-pushed
the
jkmassel/site-settings-rust
branch
from
937ccc1 to
1ed0f7a
Compare
Project dependencies changeslist! Upgraded Dependencies
rs.wordpress.api:android:alpha-2026-04-20, (changed from trunk-0d94794142482d1b7f9395c0afef57ac991c452e)
rs.wordpress.api:kotlin:alpha-2026-04-20, (changed from trunk-0d94794142482d1b7f9395c0afef57ac991c452e)tree +--- project :libs:fluxc
-| \--- rs.wordpress.api:android:trunk-0d94794142482d1b7f9395c0afef57ac991c452e
-| +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
-| +--- com.squareup.okhttp3:okhttp-tls:5.3.2
-| | +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
-| | +--- com.squareup.okio:okio:3.16.4 (*)
-| | \--- org.jetbrains.kotlin:kotlin-stdlib:2.2.21 -> 2.3.21 (*)
-| +--- net.java.dev.jna:jna:5.18.1
-| +--- rs.wordpress.api:kotlin:trunk-0d94794142482d1b7f9395c0afef57ac991c452e
-| | +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
-| | +--- com.squareup.okhttp3:okhttp-tls:5.3.2 (*)
-| | +--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.10.2 (*)
-| | \--- org.jetbrains.kotlin:kotlin-stdlib:2.1.21 -> 2.3.21 (*)
-| \--- org.jetbrains.kotlin:kotlin-stdlib:2.1.21 -> 2.3.21 (*)
+| \--- rs.wordpress.api:android:alpha-2026-04-20
+| +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
+| +--- com.squareup.okhttp3:okhttp-tls:5.3.2
+| | +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
+| | +--- com.squareup.okio:okio:3.16.4 (*)
+| | \--- org.jetbrains.kotlin:kotlin-stdlib:2.2.21 -> 2.3.21 (*)
+| +--- net.java.dev.jna:jna:5.18.1
+| +--- rs.wordpress.api:kotlin:alpha-2026-04-20
+| | +--- com.squareup.okhttp3:okhttp:5.3.2 (*)
+| | +--- com.squareup.okhttp3:okhttp-tls:5.3.2 (*)
+| | +--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.10.2 (*)
+| | \--- org.jetbrains.kotlin:kotlin-stdlib:2.1.21 -> 2.3.21 (*)
+| \--- org.jetbrains.kotlin:kotlin-stdlib:2.1.21 -> 2.3.21 (*)
-\--- rs.wordpress.api:android:trunk-0d94794142482d1b7f9395c0afef57ac991c452e (*)
+\--- rs.wordpress.api:android:alpha-2026-04-20 (*) |
jkmassel
force-pushed
the
jkmassel/site-settings-rust
branch
9 times, most recently
from
5ff6521 to
50fca51
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #22785 +/- ##
==========================================
+ Coverage 37.15% 37.17% +0.01%
==========================================
Files 2314 2317 +3
Lines 124297 124462 +165
Branches 16882 16894 +12
==========================================
+ Hits 46188 46274 +86
- Misses 74366 74444 +78
- Partials 3743 3744 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jkmassel
force-pushed
the
jkmassel/site-settings-rust
branch
from
6fad2fb to
694d6d1
Compare
Add a new "Use Third-Party Blocks" toggle in Site Settings, gated behind GutenbergKit and editor assets support. Enhance the existing "Use Theme Styles" toggle with contextual warnings when the site lacks editor settings support or uses a non-block theme. Includes SiteSettingsProvider interface for injectable access to site settings from the local DB, replacing static SiteUtils calls for block editor default detection. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Gate the "Use Third-Party Blocks" toggle behind the remote gutenberg_kit_plugins feature flag in addition to the existing GutenbergKit and editor assets checks. Also simplify the summary string by removing "and styles" per reviewer feedback. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tion Add ThemeRepository to fetch the active theme via WP API and determine if it is a block theme. Add EditorSettingsRepository to discover editor settings and editor assets route support via manifest/API root queries. Wire SiteSettingsFragment to use EditorSettingsRepository for gating theme styles and third-party blocks toggles. Also adds manifest route fetching methods to WpApiClientProvider for discovering available REST routes on WP.com and self-hosted sites. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove fetchWpComManifestRoutes and fetchSiteManifestRoutes from
WpApiClientProvider. EditorSettingsRepository now uses the standard
WpApiClient.request { it.apiRoot().get() } for all site types,
which already handles WP.com vs self-hosted URL resolution.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Call `EditorSettingsRepository.fetchEditorCapabilitiesForSite` when the user lands on My Site so the route-discovery and theme-detection results are available by the time they open Site Settings. On failure, a snackbar is shown and cached prefs retain their previous values so settings degrade to disabled rather than crashing.
12 tests covering pref delegation, route discovery persistence, theme detection, API errors, transport-level error isolation (one fetch failing doesn't block the other), and the both-fail case. Also fix MySiteViewModelTest for new constructor param.
Points at Automattic/wordpress-rs#1285 which fixes route discovery on WP.com simple sites so editor-assets and editor-settings routes appear in the API root response. Also adapts StatsDataSourceImpl to the new StatsUtmKeys API (String replaced with List<StatsUtmKey>).
Switch from hasRoute (exact path match) to hasRouteForEndpoint
(namespace + endpoint) so that WP.com sites — whose route keys
include a sites/{site_id} prefix — are correctly detected.
Requires wordpress-rs PR #1285 which adds hasRouteForEndpoint
to WpApiDetails and the ApiUrlResolver parameter.
jkmassel
force-pushed
the
jkmassel/site-settings-rust
branch
from
694d6d1 to
305ccc3
Compare
jkmassel
added
[Type] Enhancement
Gutenberg
|
It looks like |
I logged into vanilla.wpmt.co but I don't see any notice of things not looking right. 
|
It's what the preloader will use to get its data. |
Sorry about this! The theme changed at some point between my writing the review steps and the the review. I switched it back so it should repro as expected now. |
|
@jkmassel Claude found a few issues that are worth investigating:
|
|
This is quite wordy and doesn't really explain the setting to the user. How about, "Your site isn't using a block theme. For the editor to appear correctly, it's recommended to either use a block theme or leave this setting disabled." 
|
| override fun isBlockEditorDefault(site: SiteModel): Boolean { | ||
| val editor = site.mobileEditor | ||
| if (editor.isNullOrEmpty()) return true | ||
| val isWpComSimple = site.isWPCom && !site.isWPComAtomic |
There was a problem hiding this comment.
Can we use site.isWPComSimpleSite() here?
| * Returns `true` when both checks complete without | ||
| * transport-level failures. | ||
| */ | ||
| suspend fun fetchEditorCapabilitiesForSite( |
There was a problem hiding this comment.
I think this can be simplified to:
suspend fun fetchEditorCapabilitiesForSite(
site: SiteModel
): Boolean = withContext(ioDispatcher) {
val results = awaitAll(
async { fetchRouteSupport(site) },
async { fetchThemeBlockStyleSupport(site) }
)
results.all { it }
}
| themeRepository.fetchCurrentTheme(site) | ||
| if (theme != null) { | ||
| AppLog.d( | ||
| T.EDITOR, |
There was a problem hiding this comment.
This is nitpicky, but why is this split into five string fragments?
There was a problem hiding this comment.
I think it was originally four (the main one, plus a line per variable), then I added the non-variable line. 4bf1903 restores my original intent.
Two consecutive KDoc blocks had been left above the function when its return type changed from Unit to Boolean. Only the second was attached; fold the return contract into the existing KDoc as @return.
A failed remote fetch in onFetchError was calling getActivity().finish(), kicking the user out of the screen. Cached settings are already loaded earlier via mSiteSettings.init(false), so the screen remains usable — just show the toast and stay put.
site.isWPCom && !site.isWPComAtomic is exactly what SiteModel#isWPComSimpleSite() returns. Use the named predicate so the Simple-site definition stays in one place.
This seems like a good idea – WDYT about my filing a separate PR for it?
I think this is a followup PR as well – probably a banner along the top of the "My Site" screen that's more generic like "Unable to connect to your site. Some functionality might be limited" with a "Retry" button. The issue here is that the user can launch the editor from this screen so we need to pre-fetch the site settings. But if that fails, things might not work right. Once they're in the editor, it's too late. LMK if that plan seems ok?
Fixed in 60e34fe |
Replace supervisorScope + var bookkeeping with awaitAll over two async blocks. Both helpers shield non-cancellation exceptions themselves, so coroutineScope semantics (sibling-cancel-on-failure) are equivalent here — no behavior change.
The five-fragment split was harder to read than the underlying sentence. Group the static prefix and put each labelled variable on its own line.
The previous string was wordy and partially redundant with the summary it gets concatenated with. Trim to three short sentences. Avoid "look off" — it would clash with the toggle's off state.
Updated in a6b3b94 to be much shorter – I started with your suggestion and ended up trimming it down a tiny bit more :) |
I think that would be fine.
That also sounds fine.
Definitely better! |
4 participants
Summary
Extracts the site settings changes from #22579 and layers them on top of #22765.
GutenbergKitPluginsFeatureand editor assets route support, with DB migration (v70→71), full data model plumbing (SiteSettingsModel,SiteSettingsInterface,WPComSiteSettings), and preference XMLSiteSettingsProviderinterface — injectable abstraction overSiteSettingsTablefor reading site settings and determining block editor default, replacing staticSiteUtilscallsEditorSettingsRepository+ThemeRepository— discovers editor settings / editor assets route support viaWpApiClient.apiRoot().get()and fetches the active theme to detect block theme support; results cached in per-siteAppPrefsMySiteViewModel.onResume()triggersfetchEditorCapabilitiesForSiteso results are available before the user opens Site Settings; failures show a snackbar when there's no cached data, otherwise fall back silentlyTest plan
Theme Style Tests:
Before testing, ensure that the following feature flags are enabled:
When the app is not signed into WP.com:
When the app is signed into WP.com:
Third-Party Blocks Tests:
Before testing, ensure that the following feature flags are enabled:
When the app is not signed into WP.com:
When the app is signed into WP.com: