Use `WP_Site` class globally

[flixos90]

The WP_Site class introduced in WordPress 4.5 is currently only being loaded in Multisite environments. However, there are several functions that return a "site-like" object on non-multisite installs as well. Given that every setup contains a site (or let's rather say, a regular setup is a site), I think it would make sense to make the WP_Site class compatible with regular setups and then load it globally.

For reference see #37061

[flixos90]

37948.diff​ makes WP_Site compatible with non-multisite installs and loads it on these setups as well.

Questions from my end:

• Should we prevent calling the get_details() method when the $blog_id property is something other than 1 (there's no such site on a regular setup)?
• Should we make the function get_site() compatible as well and load it everywhere too? My first thought would be no, since this WP_Site use-case on a regular setup is very specific and it should be sufficient to have only the class available.

[jorbin]

@jeremyfelt What do you think?

[jeremyfelt]

Thanks for exploring this, @flixos90.

However, there are several functions that return a "site-like" object on non-multisite installs as well.

Can you highlight some others beyond get_blogs_of_user()? I can somewhat see some of the benefits there, but can also see reasons/ways around them (I think). I didn't look too closely elsewhere, but it would be helpful to have other examples for context.

In general - I'm wary of pushing for WP_Site to exist outside of multisite in the near future due to its close relationship with the wp_blogs table as well as a handful of its properties that only multisite understands. Of course, it's always possible that this changes in the future. :)

[flixos90]

Replying to jeremyfelt:

Can you highlight some others beyond get_blogs_of_user()? I can somewhat see some of the benefits there, but can also see reasons/ways around them (I think). I didn't look too closely elsewhere, but it would be helpful to have other examples for context.

Hmm, indeed I couldn't find anything else except get_blogs_of_user(), so from that point of view it might indeed be a little "too much" to load the class globally only for that one function. Let's say we don't make this class globally available, how would you continue with #37061? Return a different object type on non-multisite like the latest patch does? Or do you have another idea? :)

In general - I'm wary of pushing for WP_Site to exist outside of multisite in the near future due to its close relationship with the wp_blogs table as well as a handful of its properties that only multisite understands. Of course, it's always possible that this changes in the future. :)

I think it would be logical to provide the WP_Site class to non-multisite setups because these actually are a site. While the class is usually filled with data from the wp_blogs table, it's not restricted to that in its current state, and many parameters can easily be filled with similar data from a non-multisite setup (as we do in get_blogs_of_user(), and maybe we could even fill the public property according to the "Discourage search engines..." setting). But I also see your concern as it might become easier to introduce bugs if it's loaded everywhere.

[MikeSchinkel]

Replying to jeremyfelt:

Can you highlight some others beyond get_blogs_of_user()? I can somewhat see some of the benefits there, but can also see reasons/ways around them (I think). I didn't look too closely elsewhere, but it would be helpful to have other examples for context.

I could envision WP_Site to have properties of the site available so there is an obvious place to look for them. Compare to:

• WP_HOME
• WP_SITEURL
• DB_USER
• DB_PASSWORD
• DB_HOST
• site_url()
• home_url()
• admin_url()
• content_url()
• get_bloginfo( 'name' )
• get_bloginfo( 'description' )
• get_bloginfo( 'wpurl' )
• get_bloginfo( 'url' )
• get_bloginfo( 'admin_email' )
• get_bloginfo( 'html_type' )
• get_bloginfo( 'text_direction' )
• get_bloginfo( 'language' )
• get_bloginfo( 'stylesheet_directory' )
• get_bloginfo( 'language' )
• get_bloginfo( 'template_url' )
• get_bloginfo( 'atom_url' )
• get_bloginfo( 'rdf_url' )
• get_bloginfo( 'rss_url' )
• get_bloginfo( 'comments_atom_url' )
• get_bloginfo( 'comments_rss2_url' )

In addition I could envision these methods (or properties), with some possibly renamed to be more clear:

• plugins()
• active_plugins()
• inactive_plugins()
• mu_plugins()
• plugins_with_updates()
• drop_ins()
• themes()
• allowed_themes()
• current_theme()
• admin_menu()
• background_color()
• background_url()
• icon_url()
• background_url()
• feed_urls()
• current_user()
• users()
• subscribers()
• contributors()
• authors()
• editors()
• administrators()
• roles()
• page_ids()
• archives()
• categories()
• upload_path()
• upload_url()
• upload_subdir()
• upload_basedir()
• upload_baseurl()
• temp_dir()
• theme_mods()
• theme_roots()
• comments_popup_template()
• index_template()
• not_found_template()
• archive_template()
• post_type_archive_template()
• author_template()
• category_template()
• tag_template()
• taxonomy_template()
• date_template()
• home_template()
• front_page_template()
• page_template()
• paged_template()
• search_template()
• single_template()
• embed_template()
• singular_template()
• attachment_template()
• header_image()
• header_textcolor()
• home_path()
• importers()
• index_rel_link()
• intermediate_image_sizes()
• locale()
• locale_stylesheet_uri()
• meta_keys()
• nav_menu_locations()
• num_queries()
• page_statuses()
• plugin_updates()
• post_format_slugs()
• post_format_strings()
• post_mime_types()
• post_statuses()
• random_header_image()
• registered_nav_menus()
• shortcut_link()
• stylesheet_name()
• stylesheet_directory()
• stylesheet_directory_uri()
• stylesheet_uri()
• template_name()
• template_directory()
• template_directory_uri()
• temp_dir()

We might even consider this as a way to evolve some of the terminology make the it more consistent and easier to understand, e.g. what is the different between site_url() and home_url() and when are you supposed to use each? Or url and wpurl? Or 'stylesheet_url' and 'template_url'?

Of course all of the above it just fodder for discussion. I am not advocating that we implement that list of functions above as-is, just showing that there is a lot of information that could be consider "site" information that normally takes a lot of learning to discover and having it as properties or access methods of a class or object would be nice, especially if we can clean make the terminology consistent and potentially over time deprecate the functions that currently provide this information.

[flixos90]

@MikeSchinkel I don't think we should get into this just yet, but I agree that it might be useful to provide some of that functionality in the future. This might also make sense as it would somehow align with approaches like ​https://github.com/WP-API/wp-api-site-endpoints/issues/14.

So I think it's a valid use-case, but I don't think we should add anything of it at this point even if we make the class globally available. This would belong to a new ticket anyway. :)

[flixos90]

After discussion in multisite office hours, it was decided that this shouldn't happen yet. But as more use-cases might be appearing in the future, it might be reconsidered later.