Opened 9 years ago
Closed 9 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.phpclass-wp-network-query.phpms-blogs.php
Bootstrap File:
ms-settings.php
Loaded by bootstrap file:
class-wp-network.phpclass-wp-site.phpms-load.phpms-default-constants.php
Loaded after WordPress Core stuff:
ms-functions.phpms-default-filters.phpms-deprecated.php
This structure and loading order is problematic for several reasons.
- The functionality is not clearly separated. File names (particularly
ms-blogs.phpandms-functions.phpprovide no idea (or confusion about) what they contain. For examplems-blogs.phpcontains read functionality for sites and networks plus a bit of updating site functions (the old*_blog_details()stuff),ms-functions.phpcontains 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.phpwhich require other functions that are declared in Core files that are loaded after it. - While
ms-settings.phpis the multisite bootstrap file just aswp-settings.phploads the regular Core functionality,ms-settings.phpis 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.phpandms-network.phpand move all basic API functions for that specific area into them (those files would be similar likepost.phpandtaxonomy.phpfor example).ms-site.phpshould 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.phpwould 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.phpfile. - 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.phpfunctions 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
@
9 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.phpand have been moved toms-deprecated.phpshould still be available early, and by that tweak they would be.I encountered a further problem: Some functions in
ms-blogs.phpassume 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 thatnullis returned byget_site()orget_network(). There is anms-loadedhook inms-settings.phpthat 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.