'get_current_blog()' and/or 'current_blog_id()' function?

[martythornley]

I posted this over in the mu forums but realize it is pretty dead over there and may be better mentioned here:

​http://mu.wordpress.org/forums/topic/17568?replies=2

It would be a great help to easily get the current blog's id as in 'current_blog_id()'. I searched the entire wordpress 3.0 and mu code and it is not mentioned anywhere.

'get_current_blog()' might imply something more complex that returns all a blog's info, which would be nice too.

But in the short term... 'current_blog_id()'?

People are currently having to call global variables to use $wpdb, $current_site and/or $blog_id. I feel all of these are messy and pretty generic variables to be using within theme or plugin files.

[nacin]

People are currently having to call global variables to use $wpdb, $current_site and/or $blog_id. I feel all of these are messy and pretty generic variables to be using within theme or plugin files.

Introducing a *fourth* way to determine blog ID isn't going to get more cleaner.

The global $blog_id has existed for quite some time, even outside of MU in regular WP. So that's not going anywhere. Given WP's dependence on globals already, these should be relied on for the most part.

[martythornley]

Replying to nacin:

People are currently having to call global variables to use $wpdb, $current_site and/or $blog_id. I feel all of these are messy and pretty generic variables to be using within theme or plugin files.

Introducing a *fourth* way to determine blog ID isn't going to get more cleaner.

The global $blog_id has existed for quite some time, even outside of MU in regular WP. So that's not going anywhere. Given WP's dependence on globals already, these should be relied on for the most part.

The whole reason of my bringing this up is I tried using $blog_id in a plugin that used add_action to add to the init action and it screwed things up. Using global variables with generic names is bad form. It requires developers to know every globla variable or else risk redefining them.

This isn't about introducing a fourth way, it is about introducing THE way and losing the ones that need intimate knowledge of the core WordPress functions. Getting the current blog id should be fool proof and currently it is not.

[nacin]

If you used the global $id in your plugin, you'd screw other things up. Or $post, $paged, $posts, and the like. If you're using them in local scope -- as you should be in an add_action callback -- then you're fine, though I'd avoid local variables being called the same as important WP globals just so someone reading your code isn't confused.

I don't see how $GLOBALS['blog_id'] is not foolproof to determining the current blog ID.

[martythornley]

Replying to nacin:

I don't see how $GLOBALS['blog_id'] is not foolproof to determining the current blog ID.

Not '$GLOBALSblog_id?' but using the variable $blog_id.

Think about what might happen if you tried to define $post within the loop. Same thing.

[scribu]

If nothing else, get_current_blog() should be added for symmetry with get_current_site():

1012 function get_current_site() {
1013 global $current_site;
1014 return $current_site;
1015 }

[dd32]

#15233 added {{[get_current_blog_id();}} in 3.1

Since 3.5, [22108] / #22090 you can simply call get_blog_details();