Move utility functions out of wp-admin/network.php

[scribu]

There are several functions in wp-admin/network.php that would come in handy outside the WP Admin -> Network Setup screen:

• network_domain_check()
• allow_subdirectory_install()
• get_clean_basedomain()

etc.

They could be moved to wp-admin/includes/ms.php

[jeremyfelt]

Moves utility functions to ms.php

[jeremyfelt]

21156.diff​ moves network_domain_check(), allow_subdomain_install(), allow_subdirectory_install(), and get_clean_basedomain() from the display page of wp-admin/network.php to wp-admin/includes/ms.php. In the process, added inline docs for the global $wpdb objects.

[nacin]

admin/includes/ms.php only gets included when multisite is enabled. As network.php is for converting to a network, ms.php cannot be relied upon. Including ms.php and allowing code from it to be executed before multisite is loaded could have nasty side effects.

I imagine scribu wants these functions specifically for WP-CLI, which is totally understandable. Beyond that, though, I'd really hesitate to make too much of network creation truly public, because most of these functions are either based on our rudimentary UI and upgrade process, or on our current subdirectory/subdomain restrictions. Long term, both get dropped. populate_network() already exists, which is sufficient for most use cases.

To satisfy WP-CLI's needs, I'd suggest pushing these functions to be usable with a few changes:

• Renaming network_domain_check() and having it return *. Maybe ms_is_network_installed()
• Probably finding a better name for get_clean_basedomain().

Definitely fine with allow_subdirectory_install() and allow_subdomain_install() to be public. Note they'll likely just return; or return true; at some later point when subdomain versus subdirectory goes away.

No need for the @var's, we don't really do those on reference, just initial defines. It'd also be @global anyway.

[jeremyfelt]

Replying to nacin:

No need for the @var's, we don't really do those on reference, just initial defines. It'd also be @global anyway.

Oops, global is good. We should do them on reference though, they come in extremely handy when reading core in an IDE.

I'll let scribu chime in on the rest.

[jeremyfelt]

Punting to a future release. Looks like we can do a few things here, but more feedback and a patch is needed.

[chriscct7]

Closing as maybelater. Complete lack of interest on the feature on the ticket over the last 2 years. Feel free to reopen when more interest re-emerges (particularly if there's a patch)

[jeremyfelt]

Noting for others coming across this ticket - the intention is good. Rather than move the functions over, we should concentrate on what those functions do currently and then replace them with public functions that do it better and with more long term thought in mind.