Opened 5 years ago
Last modified 4 weeks ago
#54325 new enhancement
Multisite domain mapping: No blog address to revert to when domain mapping is made inactive
| Reported by: | henry.wright | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Networks and Sites | Version: | |
| Severity: | normal | Keywords: | close |
| Cc: | Focuses: | multisite |
Description
When a user creates a blog in a network install they are given a blog address like "foobar.example.com". Now, imagine domain mapping is activated for this blog and the blog can be accessed using a custom domain like "example.com".
If the user decides they no longer want example.com to be hosted on the network, they may point DNS records to an IP address not associated with the network install. This will result in an orphaned blog because the "foobar.example.com" address was vacated when the initial domain mapping became active.
"foobar.example.com" isn't reserved so a completely different user may have created a new blog in the mean time using the "foobar.example.com" address.
Change History (4)
#3
@
7 weeks ago
- Keywords close added
Core doesn't ship a domain mapping feature with an active/inactive state, so this lifecycle doesn't really map to core. Multisite stores domain and path directly in wp_blogs, and the only thing core provides here is the sunrise.php drop-in (SUNRISE constant) as an extension point. Domain mapping itself is left to plugins, as noted in core (see the "Domain mapping plugins" comment in class-wp-customize-manager.php).
Which setup does this describe? A domain mapping plugin (e.g., WP MU Domain Mapping keeps the original wp_blogs entry and stores mappings separately, so the address is never vacated), or changing the domain via Network Admin (a rename, not a reversible mapping)? That would help clarify whether there's a core code path to address here.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
.