Opened 5 months ago
Last modified 3 months ago
#65254 new enhancement
wp_signup_url() function proposal
| Reported by: | virgodesign | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Networks and Sites | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | multisite |
Description
Hello everyone,
I noticed that WordPress already provides several helper functions to retrieve authentication-related URLs, such as:
wp_login_url() wp_logout_url() wp_registration_url()
However, there does not seem to be an equivalent function for retrieving the Multisite signup URL.
Developers currently need to manually build or retrieve the signup URL, typically using network_site_url( 'wp-signup.php' ). This may create inconsistency and make registration/signup URL handling less uniform.
Additionally, WordPress already relies in multiple places on the following filter:
apply_filters( 'wp_signup_location', network_site_url( 'wp-signup.php' ) );
This seems to indicate that there is already a need for a centralized and filterable signup URL mechanism, but currently there is no dedicated global helper function encapsulating this behavior.
I would like to propose adding a new function:
wp_signup_url()
Possible behavior:
- In Multisite, return the filtered network signup page URL.
- In non-Multisite installations, it could return
wp_registration_url().
Example implementation idea:
<?php function wp_signup_url() { if( is_multisite() ) { return apply_filters( 'wp_signup_location', network_site_url( 'wp-signup.php' ) ); } return wp_registration_url(); }
Benefits:
- Improves API consistency.
- Centralizes signup URL generation logic.
- Ensures consistent application of the wp_signup_location filter.
- Simplifies plugin and theme development.
- Avoids repeated custom implementations across projects.
- Provides a clearer semantic distinction between registration and Multisite signup flows..
I’d be happy to hear feedback about the preferred behavior for non-Multisite installations and whether this could be a useful addition to Core.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Thanks for the proposal. Adding it for completeness seems fine, since the other auth URL helpers (
wp_login_url(),wp_registration_url(), and so on) already exist.The
wp_signup_locationfilter is already applied in three places with the same default (wp-login.php,wp-includes/canonical.php,wp-admin/my-sites.php), so a single helper would fit.For non-Multisite I would return
wp_registration_url(), as you proposed. Core already makes this exact mapping inwp-includes/canonical.php, so the helper just formalizes existing behavior. Returningfalsewould push theis_multisite()check back onto every caller.It would go next to
wp_registration_url()inwp-includes/general-template.php. I would not add a new filter, since both branches are already filterable (wp_signup_locationandregister_url).If you would like to move this forward, the easiest way is to open a pull request on GitHub and link this Trac ticket in the PR body. Please include unit tests as well.