Fixing open-source software while building the solution.
A production problem is sometimes the fastest route to a useful upstream contribution. This is how a broken WordPress provider screen became a focused fix for WPGraphQL Headless Login.
Open-source dependencies are part of the product, not somebody else's problem. When a dependency breaks the workflow we are building, the most durable answer is often to diagnose the failure in public and send the smallest responsible fix upstream.
The failure appeared inside real delivery work
While configuring headless authentication, the provider settings screen in WPGraphQL Headless Login stopped rendering after a WordPress core update. The browser showed minified React error #130. Provider selection was gone, and the controls needed to configure social login were no longer usable.
The first useful clue was what had not broken. The
/wp-json/wp/v2/settings response still contained the provider
configuration, including each provider's isEnabled state.
Data was reaching WordPress correctly; the failure lived in the
administration interface.
Trace the boundary before replacing anything
The affected environment exposed WordPress's current component APIs but no
longer provided the old __experimentalNavigation,
__experimentalNavigationItem, and
__experimentalNavigationMenu exports used by the plugin.
React error #130 was the result of trying to render components that were
now undefined.
That diagnosis matters. Rebuilding the settings system or changing its state model would have widened the patch without addressing the actual compatibility boundary. The provider data, context, and save flow were already sound.
Use stable primitives and preserve the state flow
The proposed fix replaces the unavailable experimental navigation
components with stable Button, Flex, and
FlexItem components from @wordpress/components.
Provider buttons still call the existing
setActiveClient action, the selected provider receives an
active variant and aria-current="page", and the existing
status badge remains visible.
This is an important maintenance pattern: change the unstable presentation boundary while leaving the proven state and persistence paths intact.
Restore behavior explicitly, without rendering it twice
Replacing the navigation uncovered a second visible regression: the
provider enable/disable control was missing. The patch renders the existing
isEnabled value explicitly with a WordPress
ToggleControl and passes changes through the existing
updateClient function.
At the same time, isEnabled is excluded from the generic
fields renderer. Restoring a missing control is not complete if the same
setting can then appear twice.
Testing found a separate multisite edge case
Two multisite installations revealed another problem during provider
initialization. A provider could be sent to the REST schema with a slug
such as wpgraphql_login_provider_facebook, even though the
endpoint expects facebook.
The initial configuration now strips the known provider prefix with
activeClient.replace(PROVIDER_PREFIX, ''). That one-line
normalization allowed Facebook and LinkedIn provider settings to validate
and save successfully in the tested multisite environments.
A contribution needs evidence and boundaries
The pull request documents the original error, the API mismatch, the restored control, and the multisite slug failure. It was tested against the affected WordPress environment and two multisite installations. Provider selection, enable/disable behavior, field controls, saving, and slug validation were verified. A compiled test ZIP and screenshot proof were also attached for maintainers.
The limitation is stated just as clearly: the change has not yet been tested against older WordPress versions. At the time of writing, pull request #308 is open, so this is a tested proposed fix rather than a merged upstream release.
Why upstream work belongs in product delivery
A private patch may unblock one build, but it also creates a permanent fork that the project must remember to carry. A focused upstream contribution creates a reviewable explanation, gives maintainers a reproducible case, and gives every downstream user a path to the same fix.
The practical sequence is simple: verify the data boundary, isolate the compatibility break, preserve working behavior, test the surrounding edge cases, and document what remains unknown. That is not separate from building the solution. It is part of building the solution well.