Opened 8 years ago
Closed 8 years ago
#40623 closed defect (bug) (invalid)
Investigate new file structure for Multisite functionality
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Networks and Sites | Keywords: | |
Focuses: | multisite | Cc: |
Description
Currently core multisite functionality resides in the following files:
Loaded early:
class-wp-site-query.php
class-wp-network-query.php
ms-blogs.php
Bootstrap File:
ms-settings.php
Loaded by bootstrap file:
class-wp-network.php
class-wp-site.php
ms-load.php
ms-default-constants.php
Loaded after WordPress Core stuff:
ms-functions.php
ms-default-filters.php
ms-deprecated.php
This structure and loading order is problematic for several reasons.
- The functionality is not clearly separated. File names (particularly
ms-blogs.php
andms-functions.php
provide no idea (or confusion about) what they contain. For examplems-blogs.php
contains read functionality for sites and networks plus a bit of updating site functions (the old*_blog_details()
stuff),ms-functions.php
contains functions for creating sites and users. - Future improvements (such as #37923 and #25344) run into problems since they need to declare new functions in
ms-blogs.php
which require other functions that are declared in Core files that are loaded after it. - While
ms-settings.php
is the multisite bootstrap file just aswp-settings.php
loads the regular Core functionality,ms-settings.php
is loaded before most parts of Core, which feels weird to me and may cause problems (see 2. above).
I think we should find a way to improve this through a more clarifying file structure and loading order. Some ideas I have:
- Introduce files
ms-site.php
andms-network.php
and move all basic API functions for that specific area into them (those files would be similar likepost.php
andtaxonomy.php
for example).ms-site.php
should for example contain things likeget_site()
,get_sites()
, related cache functions, functions such as those created in #40364,*_site_meta()
functions (if #37923 makes it into Core);ms-network.php
would containget_network()
,get_networks()
, related cache functions,*_network_meta()
functions (if #25344 makes it into Core) etc. I think we should only put "new" functions into those files (with "new" I mean more recent things that follow the current naming conventions in Multisite). We might also add anms-user.php
file. - Load all Multisite functionality after Core functionality. This would solve issues where Core functionality needed is not available in early-loaded files, and also that other Multisite functionality is not available (for example you shouldn't currently call
ms-functions.php
functions fromms-blogs.php
. We have to be careful with BC, edge-cases and all the other things that might come up when changing loading order - so not sure whether this is possible, but it's something to think about.
Let's think about it.
Attachments (1)
Change History (7)
#2
@
8 years ago
40623.diff moves some functions from the general ms-blogs.php
to more specific ms-site.php
and ms-network.php
files respectively. All functions follow the new naming conventions except clean_blog_cache()
, I moved that function because it actually belongs to the site API (if we ever introduce a replacement, that function can be deprecated and moved out of there).
The two files are loaded from ms-blogs.php
to provide full BC even for the edge-case that someone loads that file manually. If we come to the conclusion that this is not necessary, it would probably be better to load the two new files from wp-settings.php
directly.
I think this change is a good first step into the right direction, which we could easily merge without BC concerns (correct me if I'm wrong!). This would give a better overview over the existing site and network APIs and also provide dedicated files for enhancements such as #40364.
After playing around with the loading order, I already have to revert my initial idea: Loading the files after all the rest is not a great idea since some areas require the current site and network to be set up prior.
However we could move the three files that are loaded late into the initial block. That would already provide some benefits, for example deprecated functions that were previously available in
ms-blogs.php
and have been moved toms-deprecated.php
should still be available early, and by that tweak they would be.I encountered a further problem: Some functions in
ms-blogs.php
assume that the current site and network area already set up. However, those functions can be called prior to that (for example in a customsunrise.php
), and they should properly handle the case thatnull
is returned byget_site()
orget_network()
. There is anms-loaded
hook inms-settings.php
that we could use to easily check whether the multisite bootstrap process has already been completed.An alternative would be to think about a file structure, where we only make a selected list of functions available early (before
ms-settings.php
) and move the rest to a later loading point, however this might become very complicated for BC because people might have been using some of these "not-recommended" functions.