WordPress.org

Make WordPress Core

#37948 closed enhancement (maybelater)

Use `WP_Site` class globally

Reported by: flixos90 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords:
Focuses: multisite Cc:

Description

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

Attachments (1)

37948.diff (2.5 KB) - added by flixos90 17 months ago.

Download all attachments as: .zip

Change History (10)

@flixos90
17 months ago

#1 @flixos90
17 months ago

  • Keywords has-patch needs-unit-tests 2nd-opinion added; needs-patch removed

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.

This ticket was mentioned in Slack in #core by flixos90. View the logs.


16 months ago

#3 @jorbin
16 months ago

@jeremyfelt What do you think?

#4 follow-ups: @jeremyfelt
16 months ago

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. :)

#5 in reply to: ↑ 4 @flixos90
16 months ago

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.

#6 in reply to: ↑ 4 @MikeSchinkel
16 months ago

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.

#7 @flixos90
16 months ago

@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. :)

This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.


16 months ago

#9 @flixos90
16 months ago

  • Keywords has-patch needs-unit-tests 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.