Merge release/26.8 into trunk (#22943)

* Bump version number

* Update draft release notes for 26.8

* Update draft release notes for Jetpack 26.8.

* Release Notes: add new section for next version (26.9)

* Use wordpress-rs 0.4.0

* Merge strings from libraries for translation

* Freeze strings for translation

* Keep JNA/UniFFI classes so wordpress-rs survives R8 in release builds (#22916)

AGP 9's R8 strips the @com.sun.jna.Structure.FieldOrder annotation that
wordpress-rs JNA bindings read reflectively at runtime, causing a launch
crash in minified release builds. Keep the JNA classes, UniFFI bindings,
and the annotation so native struct layouts still resolve.

* Add temporary release notes

* Merge release_notes/26.8 into release/26.8 (#22917)

* Update WordPress `PlayStoreStrings.po` for version 26.8

* Update Jetpack `PlayStoreStrings.po` for version 26.8

* Update translations

* Update translations

* Update WordPress metadata translations for 26.8

* Update Jetpack metadata translations for 26.8

* Bump version number

* Merge release_notes/26.8 into release/26.8 (#22922)

* Update editorialized release notes

* Update WordPress `PlayStoreStrings.po` for version 26.8

* Update Jetpack `PlayStoreStrings.po` for version 26.8

---------

Co-authored-by: Tony Li <tony.li@automattic.com>

* Update WordPress metadata translations for 26.8

* Update Jetpack metadata translations for 26.8

* Bump version number

* Bump version number

* Fix Czech confirm_remove_site translation breaking release lint

The 26.8 translation sync introduced a doubled backslash (\\") in the
Czech confirm_remove_site string. Android reads \\ as an escaped literal
backslash, which hides the %s placeholder from lint, so StringFormatMatches
fails: ChooseSiteActivity supplies 1 argument but the string is seen as
requiring 0.

Use a single-backslash escape (\") to match the English source and every
other locale.

* Fix Czech delete-confirmation translations breaking release lint

term_delete_confirmation_message carried the same doubled backslash (\\")
as confirm_remove_site, hiding its %1$s placeholder so lint sees 0 args
while TermsDataViewActivity supplies 1 (StringFormatMatches). It was the
second such error; lint prints only the first failure, so it surfaced
once confirm_remove_site was fixed.

Also fix the two identical siblings delete_menu_item_confirmation_message
and delete_menu_confirmation_message, which share the defect.

Verified locally: :WordPress:lintWordpressRelease BUILD SUCCESSFUL, 0 errors.

* Bump version number

* Merge release_notes/26.8 into release/26.8 (#22937)

* Update release notes

* Update WordPress `PlayStoreStrings.po` for version 26.8

* Update Jetpack `PlayStoreStrings.po` for version 26.8

---------

Co-authored-by: Tony Li <tony.li@automattic.com>

* Fix false connectivity banner on private Atomic sites (#22926)

* Fix false connectivity banner on private Atomic sites

Editor capability detection on Atomic sites probes the direct host via
unauthenticated REST API discovery (added in #22883). Private Atomic
hosts gate anonymous requests, so discovery fails and the My Site
"Unable to connect to your site" banner appears even though the site is
reachable. Fall back to an authenticated app-password probe against the
same host when discovery fails and credentials exist.

* Log authenticated direct-host probe failures for diagnosability

The authenticated app-password fallback previously returned a silent
`false` on a non-success response, and the no-credentials path was also
silent. Log both (mirroring the discovery-failure log) so a recurrence
of the connectivity banner can be diagnosed from AppLog rather than
being indistinguishable from "discovery failed, no creds".

* Suppress the connectivity banner while the app password is being minted

On first login an Atomic site's application password is minted
asynchronously on the My Site screen, so the connectivity capability
fetch can race ahead of it and fail purely for lack of credentials —
flashing a false "unable to connect" banner that clears on the next
refresh. Treat a credential-less fetch as pending rather than a
connection failure, mirroring the existing offline suppression; the
application-password card already owns the no-credentials state.

* Re-detect editor capabilities when an app password is established

The connectivity banner's capability fetch and the application-password
mint both run on the My Site screen with no ordering, so on first login
the fetch loses the race and capability flags aren't detected until the
next resume/refresh. Add an app-scoped CredentialsChangedNotifier that
both credential-establishment paths (headless mint and interactive
login) emit to, and have the connectivity slice re-run detection on it —
re-reading a fresh site so it observes the just-persisted credentials.
This also closes the asymmetry where only the interactive path announced
credential changes globally.

* Hoist connectivity banner suppression into a named flag

The four-way suppression condition tripped detekt's ComplexCondition
threshold once the pending-credentials term was added. Lift it into a
named `suppressBanner` flag — clearer intent, and out of the
if-condition detekt inspects. No behavior change.

* Surface the connectivity banner when the app-password mint fails

The pending-credentials suppression also hid the banner when the headless
mint *terminally* failed — and the application-password card can't render
for private Atomic sites either (its authorize-URL discovery hits the same
gated host), so the user was left with a broken site and no signal at all.

Track terminal mint failure in the renamed ApplicationPasswordMonitor (was
CredentialsChangedNotifier) and suppress only while provisioning is
genuinely in flight; once the mint fails, surface the banner. The monitor
also wakes capability detection on failure so the banner appears without
waiting for the next resume/refresh.

* Revert "Surface the connectivity banner when the app-password mint fails"

This reverts commit 357fd82.

The terminal-failure surfacing called onMintFailed on every non-success,
including transient failures, so a transient first-login mint failure
latched hasMintFailed and showed the false connectivity banner this PR
set out to suppress. Revert to the pending-suppression behavior; the
durable single-source-of-truth redesign is tracked in #22942.

---------

Co-authored-by: Automattic Release Bot <mobile+wpmobilebot@automattic.com>
Co-authored-by: Tony Li <tony.li@automattic.com>

Author: 3 people

WordPress/src/main/java/org/wordpress/android/repositories/EditorSettingsRepository.kt

@@ -34,6 +34,17 @@ class EditorSettingsRepository @Inject constructor(
     fun hasCachedCapabilities(site: SiteModel): Boolean =
         appPrefsWrapper.hasSiteEditorCapabilities(site)
 
+    /**
+     * True when capability detection can't run yet because an Atomic site's
+     * direct-host probe needs an application password that hasn't been
+     * provisioned. The password is minted asynchronously on the My Site
+     * screen (see ApplicationPasswordViewModelSlice), so a first-login fetch
+     * can fail purely for lack of credentials — callers should treat this as
+     * pending, not a connection failure.
+     */
+    fun isAwaitingApplicationPassword(site: SiteModel): Boolean =
+        site.isWPComAtomic && !site.hasApplicationPasswordCredentials()
+
     /**
      * Returns whether the site is known to support the
      * `wp-block-editor/v1/settings` endpoint, based on
@@ -139,24 +150,66 @@ class EditorSettingsRepository @Inject constructor(
      * assume the API lives at `/wp-json` (custom permalink structures or
      * REST API paths would break that assumption), then use the routes list
      * returned by discovery directly — no second request needed.
+     *
+     * Discovery is unauthenticated, so it can't reach a *private* Atomic host
+     * — the host gates anonymous requests and the API root never loads. When
+     * the site has application-password credentials, fall back to an
+     * authenticated probe against the same direct host (Basic auth), which is
+     * exactly the transport the editor uses there. Without credentials there's
+     * nothing to authenticate with, so we report failure. See #22883.
      */
     private suspend fun fetchRouteSupportViaDirectHostDiscovery(
         site: SiteModel
     ): Boolean {
         val discovery = wpLoginClient.apiDiscovery(site.url)
-        if (discovery !is ApiDiscoveryResult.Success) {
+        if (discovery is ApiDiscoveryResult.Success) {
+            val resolver = wpApiClientProvider.urlResolverFor(
+                discovery.success.apiRootUrl
+            )
+            persistRouteSupport(site, discovery.success.apiDetails, resolver)
+            return true
+        }
+        AppLog.w(
+            T.EDITOR,
+            "Direct-host API discovery failed for" +
+                " site=${site.name}: ${discovery::class.simpleName}"
+        )
+        return if (site.hasApplicationPasswordCredentials()) {
+            fetchRouteSupportViaApplicationPasswordClient(site)
+        } else {
             AppLog.w(
                 T.EDITOR,
-                "Direct-host API discovery failed for" +
-                    " site=${site.name}: ${discovery::class.simpleName}"
+                "No application password for site=${site.name};" +
+                    " skipping authenticated direct-host probe"
             )
-            return false
+            false
+        }
+    }
+
+    /**
+     * Authenticated direct-host route probe for Atomic sites whose host
+     * rejects the anonymous discovery request (e.g. private sites). Uses the
+     * site's application-password (Basic auth) client and resolves routes
+     * against the same direct host — mirrors
+     * [fetchRouteSupportViaConfiguredClient] but bypasses the WP.com proxy.
+     */
+    private suspend fun fetchRouteSupportViaApplicationPasswordClient(
+        site: SiteModel
+    ): Boolean {
+        val client = wpApiClientProvider.getApplicationPasswordClient(site)
+        val resolver = wpApiClientProvider.getDirectHostApiUrlResolver(site)
+        val response = client.request { it.apiRoot().get() }
+        return if (response is WpRequestResult.Success) {
+            persistRouteSupport(site, response.response.data, resolver)
+            true
+        } else {
+            AppLog.w(
+                T.EDITOR,
+                "Authenticated direct-host probe failed for" +
+                    " site=${site.name}: ${response::class.simpleName}"
+            )
+            false
         }
-        val resolver = wpApiClientProvider.urlResolverFor(
-            discovery.success.apiRootUrl
-        )
-        persistRouteSupport(site, discovery.success.apiDetails, resolver)
-        return true
     }
 
     private fun persistRouteSupport(
@@ -215,3 +268,7 @@ class EditorSettingsRepository @Inject constructor(
         false
     }
 }
+
+private fun SiteModel.hasApplicationPasswordCredentials(): Boolean =
+    !apiRestUsernamePlain.isNullOrEmpty() &&
+        !apiRestPasswordPlain.isNullOrEmpty()

WordPress/src/main/java/org/wordpress/android/ui/accounts/login/ApplicationPasswordLoginHelper.kt

@@ -46,6 +46,7 @@ class ApplicationPasswordLoginHelper @Inject constructor(
     private val discoverSuccessWrapper: DiscoverSuccessWrapper,
     private val crashLogging: CrashLogging,
     private val wpApiClientProvider: WpApiClientProvider,
+    private val credentialsChangedNotifier: CredentialsChangedNotifier,
 ) {
     private var processedAppPasswordData: String? = null
 
@@ -148,6 +149,7 @@ class ApplicationPasswordLoginHelper @Inject constructor(
                 }
                 wpApiClientProvider.clearSelfHostedClient(site.id)
                 dispatcherWrapper.updateApplicationPassword(site)
+                credentialsChangedNotifier.notifyChanged(site.id)
                 trackSuccessful(effectiveUrlLogin.siteUrl)
                 trackCreated(creationSource, success = true)
                 processedAppPasswordData = effectiveUrlLogin.siteUrl

WordPress/src/main/java/org/wordpress/android/ui/accounts/login/CredentialsChangedNotifier.kt

@@ -0,0 +1,34 @@
+package org.wordpress.android.ui.accounts.login
+
+import kotlinx.coroutines.channels.BufferOverflow
+import kotlinx.coroutines.flow.MutableSharedFlow
+import kotlinx.coroutines.flow.SharedFlow
+import kotlinx.coroutines.flow.asSharedFlow
+import javax.inject.Inject
+import javax.inject.Singleton
+
+/**
+ * App-scoped signal that an application password was newly established for a site — either by the
+ * headless Jetpack-tunnel mint on the My Site screen or by the interactive application-password
+ * login. Lets credential-dependent work (e.g. editor capability detection) re-run as soon as the
+ * password exists, instead of waiting for the next My Site resume/refresh.
+ *
+ * Emits the site's local id; collectors should re-read a fresh SiteModel so they observe the
+ * just-persisted credentials rather than a stale in-memory copy.
+ */
+@Singleton
+class CredentialsChangedNotifier @Inject constructor() {
+    // replay = 1 so a collector that subscribes just after an emit still sees it — closes the
+    // emit-before-collect race. DROP_OLDEST keeps tryEmit non-suspending without an unbounded buffer.
+    private val _events = MutableSharedFlow<Int>(
+        replay = 1,
+        extraBufferCapacity = 1,
+        onBufferOverflow = BufferOverflow.DROP_OLDEST,
+    )
+    val events: SharedFlow<Int> = _events.asSharedFlow()
+
+    /** Signals that [siteLocalId]'s application-password credentials were just established. */
+    fun notifyChanged(siteLocalId: Int) {
+        _events.tryEmit(siteLocalId)
+    }
+}

WordPress/src/main/java/org/wordpress/android/ui/mysite/cards/applicationpassword/ApplicationPasswordViewModelSlice.kt

@@ -18,6 +18,7 @@ import org.wordpress.android.fluxc.network.rest.wpapi.rs.WpApiClientProvider
 import org.wordpress.android.fluxc.store.SiteStore
 import org.wordpress.android.fluxc.utils.AppLogWrapper
 import org.wordpress.android.ui.accounts.login.ApplicationPasswordLoginHelper
+import org.wordpress.android.ui.accounts.login.CredentialsChangedNotifier
 import org.wordpress.android.ui.accounts.login.SiteApiRestUrlRecoverer
 import org.wordpress.android.ui.mysite.MySiteCardAndItem
 import org.wordpress.android.ui.mysite.MySiteCardAndItem.Card.QuickLinksItem.QuickLinkItem
@@ -41,6 +42,7 @@ class ApplicationPasswordViewModelSlice @Inject constructor(
     private val siteXMLRPCClient: SiteXMLRPCClient,
     private val siteApiRestUrlRecoverer: SiteApiRestUrlRecoverer,
     private val dispatcher: Dispatcher,
+    private val credentialsChangedNotifier: CredentialsChangedNotifier,
     @Named(IO_THREAD) private val ioDispatcher: CoroutineDispatcher,
 ) {
     lateinit var scope: CoroutineScope
@@ -112,6 +114,7 @@ class ApplicationPasswordViewModelSlice @Inject constructor(
             if (!createResult.isError && createResult.credentials != null) {
                 wpApiClientProvider.clearSelfHostedClient(storedSite.id)
                 appLogWrapper.d(AppLog.T.MAIN, "A_P: Headless mint succeeded for ${storedSite.url}")
+                credentialsChangedNotifier.notifyChanged(storedSite.id)
                 // The mint goes through the Jetpack tunnel and never runs discovery — without this
                 // step, freshly minted Atomic sites end up with working creds but a NULL
                 // wpApiRestUrl in the local DB. Run in the background so the card hides immediately.

WordPress/src/main/java/org/wordpress/android/ui/mysite/cards/connectivity/SiteConnectivityBannerViewModelSlice.kt

@@ -8,13 +8,17 @@ import kotlinx.coroutines.launch
 import org.wordpress.android.R
 import org.wordpress.android.fluxc.model.SiteModel
 import org.wordpress.android.repositories.EditorSettingsRepository
+import org.wordpress.android.ui.accounts.login.CredentialsChangedNotifier
 import org.wordpress.android.ui.mysite.MySiteCardAndItem
+import org.wordpress.android.ui.mysite.SelectedSiteRepository
 import org.wordpress.android.util.NetworkUtilsWrapper
 import javax.inject.Inject
 
 class SiteConnectivityBannerViewModelSlice @Inject constructor(
     private val editorSettingsRepository: EditorSettingsRepository,
     private val networkUtilsWrapper: NetworkUtilsWrapper,
+    private val credentialsChangedNotifier: CredentialsChangedNotifier,
+    private val selectedSiteRepository: SelectedSiteRepository,
 ) {
     private lateinit var scope: CoroutineScope
     private var currentJob: Job? = null
@@ -31,6 +35,18 @@ class SiteConnectivityBannerViewModelSlice @Inject constructor(
 
     fun initialize(scope: CoroutineScope) {
         this.scope = scope
+        // Re-run detection the moment an application password is established for the selected site
+        // (e.g. the headless mint finished after our first fetch lost the race), instead of waiting
+        // for the next resume/refresh. Re-read the selected site so we see the just-persisted
+        // credentials; isUserInitiated = false so a replayed event is a no-op once cached.
+        scope.launch {
+            credentialsChangedNotifier.events.collect { siteLocalId ->
+                val site = selectedSiteRepository.getSelectedSite()
+                if (site != null && site.id == siteLocalId) {
+                    fetchCapabilities(site, isUserInitiated = false)
+                }
+            }
+        }
     }
 
     fun fetchCapabilities(site: SiteModel, isUserInitiated: Boolean) {
@@ -52,7 +68,17 @@ class SiteConnectivityBannerViewModelSlice @Inject constructor(
             // connection" banner already covers this case, and stacking warnings
             // for the same root cause is just noise.
             val suppressForOffline = !ok && !networkUtilsWrapper.isNetworkAvailable()
-            _uiModel.postValue(if (ok || hasCache || suppressForOffline) null else buildBanner())
+            // Atomic sites probe the direct host with an application password that's minted
+            // asynchronously on this same screen, so a first-login fetch can fail purely because
+            // the credential isn't ready yet. Treat that as pending, not a connection failure —
+            // the application-password card owns that state and a later fetch will succeed.
+            val suppressForPendingAuth =
+                !ok && editorSettingsRepository.isAwaitingApplicationPassword(site)
+            // Show the banner only as a last resort — not when detection succeeded, when we have
+            // cached capabilities, or while a transient non-error state (offline / pending creds)
+            // already explains the failure.
+            val suppressBanner = ok || hasCache || suppressForOffline || suppressForPendingAuth
+            _uiModel.postValue(if (suppressBanner) null else buildBanner())
         }
     }
 

WordPress/src/test/java/org/wordpress/android/repositories/EditorSettingsRepositoryTest.kt

@@ -53,6 +53,9 @@ class EditorSettingsRepositoryTest : BaseUnitTest() {
     @Mock
     lateinit var wpApiClient: WpApiClient
 
+    @Mock
+    lateinit var appPasswordClient: WpApiClient
+
     @Mock
     lateinit var apiUrlResolver: ApiUrlResolver
 
@@ -285,6 +288,84 @@ class EditorSettingsRepositoryTest : BaseUnitTest() {
             verify(wpApiClientProvider, never()).getWpApiClient(atomicSite)
         }
 
+    @Test
+    fun `atomic site falls back to authenticated probe when discovery fails`() =
+        runTest {
+            val atomicSite = SiteModel().apply {
+                id = 5
+                url = "https://atomic.example.com"
+                setIsWPCom(true)
+                setIsWPComAtomic(true)
+                apiRestUsernamePlain = "user"
+                apiRestPasswordPlain = "secret"
+            }
+            mockDiscoveryFailure(atomicSite.url)
+            whenever(
+                wpApiClientProvider.getApplicationPasswordClient(atomicSite)
+            ).thenReturn(appPasswordClient)
+            whenever(
+                wpApiClientProvider.getDirectHostApiUrlResolver(atomicSite)
+            ).thenReturn(directHostResolver)
+            mockApiRootResponseFor(
+                client = appPasswordClient,
+                resolver = directHostResolver,
+                hasEditorSettings = true,
+                hasEditorAssets = true,
+            )
+            whenever(themeRepository.fetchCurrentTheme(atomicSite))
+                .thenReturn(buildTheme(isBlockTheme = false))
+
+            val result =
+                repository.fetchEditorCapabilitiesForSite(atomicSite)
+
+            assertThat(result).isTrue()
+            verify(appPrefsWrapper)
+                .setSiteSupportsEditorSettings(atomicSite, true)
+            verify(appPrefsWrapper)
+                .setSiteSupportsEditorAssets(atomicSite, true)
+        }
+
+    @Test
+    fun `atomic site returns false when authenticated probe also fails`() =
+        runTest {
+            val atomicSite = SiteModel().apply {
+                id = 6
+                url = "https://atomic.example.com"
+                setIsWPCom(true)
+                setIsWPComAtomic(true)
+                apiRestUsernamePlain = "user"
+                apiRestPasswordPlain = "secret"
+            }
+            mockDiscoveryFailure(atomicSite.url)
+            whenever(
+                wpApiClientProvider.getApplicationPasswordClient(atomicSite)
+            ).thenReturn(appPasswordClient)
+            whenever(
+                wpApiClientProvider.getDirectHostApiUrlResolver(atomicSite)
+            ).thenReturn(directHostResolver)
+            mockApiRootErrorFor(appPasswordClient)
+            whenever(themeRepository.fetchCurrentTheme(atomicSite))
+                .thenReturn(buildTheme(isBlockTheme = false))
+
+            val result =
+                repository.fetchEditorCapabilitiesForSite(atomicSite)
+
+            assertThat(result).isFalse()
+            verify(appPrefsWrapper, never())
+                .setSiteSupportsEditorSettings(any(), any())
+            verify(appPrefsWrapper, never())
+                .setSiteSupportsEditorAssets(any(), any())
+        }
+
+    private suspend fun mockDiscoveryFailure(siteUrl: String) {
+        whenever(wpLoginClient.apiDiscovery(siteUrl))
+            .thenReturn(
+                ApiDiscoveryResult.FailureParseSiteUrl(
+                    ParseUrlException.Generic("")
+                )
+            )
+    }
+
     private suspend fun mockApiRootResponse(
         hasEditorSettings: Boolean,
         hasEditorAssets: Boolean
@@ -363,15 +444,17 @@ class EditorSettingsRepositoryTest : BaseUnitTest() {
             )
     }
 
+    private suspend fun mockApiRootError() = mockApiRootErrorFor(wpApiClient)
+
     @Suppress("UNCHECKED_CAST")
-    private suspend fun mockApiRootError() {
+    private suspend fun mockApiRootErrorFor(client: WpApiClient) {
         val error = WpRequestResult.UnknownError<Any>(
             statusCode = 500u,
             response = "Internal Server Error",
             requestUrl = "https://test.wordpress.com/wp-json",
             requestMethod = uniffi.wp_api.RequestMethod.GET
         )
-        whenever(wpApiClient.request<Any>(any()))
+        whenever(client.request<Any>(any()))
             .thenReturn(error)
     }
 

WordPress/src/test/java/org/wordpress/android/ui/accounts/login/ApplicationPasswordLoginHelperTest.kt

@@ -76,6 +76,9 @@ class ApplicationPasswordLoginHelperTest : BaseUnitTest() {
     @Mock
     lateinit var wpApiClientProvider: WpApiClientProvider
 
+    @Mock
+    lateinit var credentialsChangedNotifier: CredentialsChangedNotifier
+
     private lateinit var applicationPasswordLoginHelper: ApplicationPasswordLoginHelper
 
     @Before
@@ -92,7 +95,8 @@ class ApplicationPasswordLoginHelperTest : BaseUnitTest() {
             apiRootUrlCache,
             discoverSuccessWrapper,
             crashLogging,
-            wpApiClientProvider
+            wpApiClientProvider,
+            credentialsChangedNotifier
         )
     }
 
@@ -206,6 +210,7 @@ class ApplicationPasswordLoginHelperTest : BaseUnitTest() {
         verify(siteStore).sites
         verify(dispatcherWrapper).updateApplicationPassword(eq(siteModel))
         verify(wpApiClientProvider).clearSelfHostedClient(eq(siteModel.id))
+        verify(credentialsChangedNotifier).notifyChanged(eq(siteModel.id))
     }
 
     @Test