[wp-trac] [WordPress Trac] #37948: Use `WP_Site` class globally

[WordPress Trac]

#37948: Use `WP_Site` class globally
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Networks and Sites                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  has-patch needs-unit-tests 2nd-      |  Resolution:
  opinion                                        |     Focuses:  multisite
-------------------------------------------------+-------------------------

Comment (by MikeSchinkel):

 Replying to [comment:4 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37948#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform