Point user-portal links at the configured portal URL - #719
Open
johnworth wants to merge 1 commit into
Open
Conversation
The logged-out banner kept the signup link in a useRef seeded with constants.DEFAULT_USER_PORTAL_URL, updated it from a useEffect, and then read the ref during render. Mutating a ref triggers no re-render, so the link stayed on https://user.cyverse.org until some unrelated re-render happened to occur -- and every refresh reverted it, since the SSR'd HTML always carried the default. Read publicRuntimeConfig.USER_PORTAL_URL directly instead of going through the config context: the context is assembled in an effect in _app, so it is still null when the banner first renders and would leave the initial paint pointing at the default either way. The register link on the sign-in error page and the user-portal link in the admin subscription drawer had the same problem in a simpler form -- they read the hardcoded constants and never consulted the config at all. That leaves constants.USER_PORTAL unused, so drop it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
psarando
requested changes
Jul 29, 2026
psarando
left a comment
psarando
left a comment
Member
There was a problem hiding this comment.
Wait, I'll have to change my review, since this will cause conflicts in the next.js v16 upgrade, which gets rid of the publicRuntimeConfig.
It can be kept in the Banner for this PR, and I'll do some testing in the nextjs v16 branch for another solution, if the useConfig context won't work there.
Comment on lines
+64
to
+67
| const { publicRuntimeConfig = {} } = getConfig() || {}; | ||
| const registerURL = `${ | ||
| publicRuntimeConfig.USER_PORTAL_URL || constants.DEFAULT_USER_PORTAL_URL | ||
| }/register`; |
Member
There was a problem hiding this comment.
Can this use the useConfig context instead of the publicRuntimeConfig?
Comment on lines
+296
to
+299
| const { publicRuntimeConfig = {} } = getConfig() || {}; | ||
| const baseURL = | ||
| publicRuntimeConfig.USER_PORTAL_URL || | ||
| constants.DEFAULT_USER_PORTAL_URL; |
Member
There was a problem hiding this comment.
Can this use the useConfig context instead of the publicRuntimeConfig?
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
2 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.
The logged-out banner kept the signup link in a useRef seeded with constants.DEFAULT_USER_PORTAL_URL, updated it from a useEffect, and then read the ref during render. Mutating a ref triggers no re-render, so the link stayed on https://user.cyverse.org until some unrelated re-render happened to occur -- and every refresh reverted it, since the SSR'd HTML always carried the default.
Read publicRuntimeConfig.USER_PORTAL_URL directly instead of going through the config context: the context is assembled in an effect in _app, so it is still null when the banner first renders and would leave the initial paint pointing at the default either way.
The register link on the sign-in error page and the user-portal link in the admin subscription drawer had the same problem in a simpler form -- they read the hardcoded constants and never consulted the config at all. That leaves constants.USER_PORTAL unused, so drop it.