Discussion:
Alternative or reactivation for get_blog_info()
Frank Bueltge
2013-07-24 08:57:29 UTC
Permalink
Hello at all,

since WP 3.0 ist Multisite more and more popular.
Very often on development is it important, that you get all blogs on
network. Before WP 3.0 give it the function get_blog_list() for this job.
http://codex.wordpress.org/WPMU_Functions/get_blog_list

Since 3.0 is this function deprecated. But if you will search via www for a
alternative solution, you find many code snippets, but all with a sql
select. I think it is important, that we have a core function for this
topic, maybe the function get_blog_list().
What do you think, it is a enhancement, change for the trac that we
reactivate the function in core?
I have search on trac for topics to this functions, but only one result
with other content.

Thanks a lot for your time.
Frank
Malte Witt
2013-07-24 09:18:47 UTC
Permalink
I stumbled upon this a few days ago, too.

In my opinion get_blog_list() is perfectly fine. The Codex and the
source is just saying: "For performance reasons this function is not
recommended." That's true for installations with thousands of blogs. But
I think most multisite installations out there in the real world have 3
to 100 sites and they have a perfect valid usecase for get_blog_list().

If there is a no other reason why the function is deprecated (and I
can't see any) I would say just reactivate it and place a big warning
sign in the Codex, that this function shouldn't be used in super-large
multisite installations.

In short: +1 for reactivation of get_blog_list().

Regards,
Malte
Post by Frank Bueltge
Hello at all,
since WP 3.0 ist Multisite more and more popular.
Very often on development is it important, that you get all blogs on
network. Before WP 3.0 give it the function get_blog_list() for this job.
http://codex.wordpress.org/WPMU_Functions/get_blog_list
Since 3.0 is this function deprecated. But if you will search via www for a
alternative solution, you find many code snippets, but all with a sql
select. I think it is important, that we have a core function for this
topic, maybe the function get_blog_list().
What do you think, it is a enhancement, change for the trac that we
reactivate the function in core?
I have search on trac for topics to this functions, but only one result
with other content.
Thanks a lot for your time.
Frank
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Frank Bueltge
2013-07-24 10:24:55 UTC
Permalink
I have create the default functions with site transients, there is a bid
faster.
Maybe this helps other users, there search for a function to get all blogs.
https://github.com/bueltge/WordPress-Multisite-Enhancements/blob/master/inc/autoload/core.php

Best
Frank
Post by Malte Witt
I stumbled upon this a few days ago, too.
In my opinion get_blog_list() is perfectly fine. The Codex and the source
is just saying: "For performance reasons this function is not recommended."
That's true for installations with thousands of blogs. But I think most
multisite installations out there in the real world have 3 to 100 sites and
they have a perfect valid usecase for get_blog_list().
If there is a no other reason why the function is deprecated (and I can't
see any) I would say just reactivate it and place a big warning sign in the
Codex, that this function shouldn't be used in super-large multisite
installations.
In short: +1 for reactivation of get_blog_list().
Regards,
Malte
Post by Frank Bueltge
Hello at all,
since WP 3.0 ist Multisite more and more popular.
Very often on development is it important, that you get all blogs on
network. Before WP 3.0 give it the function get_blog_list() for this job.
http://codex.wordpress.org/**WPMU_Functions/get_blog_list<http://codex.wordpress.org/WPMU_Functions/get_blog_list>
Since 3.0 is this function deprecated. But if you will search via www for a
alternative solution, you find many code snippets, but all with a sql
select. I think it is important, that we have a core function for this
topic, maybe the function get_blog_list().
What do you think, it is a enhancement, change for the trac that we
reactivate the function in core?
I have search on trac for topics to this functions, but only one result
with other content.
Thanks a lot for your time.
Frank
______________________________**_________________
wp-hackers mailing list
http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
______________________________**_________________
wp-hackers mailing list
http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
Micky Hulse
2013-07-24 19:31:20 UTC
Permalink
Post by Frank Bueltge
Maybe this helps other users, there search for a function to get all blogs.
https://github.com/bueltge/WordPress-Multisite-Enhancements/blob/master/inc/autoload/core.php
Frank, nice work on the above repo.

Looks like some nice additions you've made to a multisite install. I'm
looking forward to exploring/using your code.
Frank Bueltge
2013-07-25 06:23:39 UTC
Permalink
Hi Mike.
Thanks a lot for the praise.
I invite you to an improved all the code and expand.

best
Frank
Post by Malte Witt
Post by Frank Bueltge
Maybe this helps other users, there search for a function to get all
blogs.
https://github.com/bueltge/WordPress-Multisite-Enhancements/blob/master/inc/autoload/core.php
Frank, nice work on the above repo.
Looks like some nice additions you've made to a multisite install. I'm
looking forward to exploring/using your code.
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Andrew Nacin
2013-07-25 06:37:52 UTC
Permalink
Post by Malte Witt
I stumbled upon this a few days ago, too.
In my opinion get_blog_list() is perfectly fine. The Codex and the source
is just saying: "For performance reasons this function is not recommended."
That's true for installations with thousands of blogs. But I think most
multisite installations out there in the real world have 3 to 100 sites and
they have a perfect valid usecase for get_blog_list().
If there is a no other reason why the function is deprecated (and I can't
see any) I would say just reactivate it and place a big warning sign in the
Codex, that this function shouldn't be used in super-large multisite
installations.
In short: +1 for reactivation of get_blog_list().
It's really just a poorly written function. No caching, no LIMIT (but does
"limiting" with an array_slice()), hits every site's posts table, etc. This
is one of the more dangerous functions performance-wise in core (probably
the most dangerous) because of how nasty it can be. If you have thousands
of sites, you'll run out of memory. If you have hundreds of sites, it could
take a long while to run. Even if you only have a few dozen sites, if you
have large post tables, this could take a few seconds to calculate. If it
actually did a proper LIMIT for both $start and $num, it'd be a lot better
off, but it's still pretty lame.

I've always had in my head a more robust WP_Site_Query, to be modeled after
WP_User_Query, WP_Comment_Query, and WP_Query. Fully functional arguments,
proper limiting, only touching the blogs table (post count is superflous —
query it yourself only if or when you need it), having numerous filters and
built-in caching (WP_Comment_Query does this well, IIRC), declining to do
anything when wp_is_large_network(), etc. Even though we've yet to get
around to making such a replacement, I have no regrets for us marking
get_blog_list() deprecated. What a terrible function.

Nacin
Frank Bueltge
2013-07-25 08:05:50 UTC
Permalink
Hi Nacin,

thanks for the feedback and declare the points to deprecated.
I think a Query was the best solution, useful and flexible.

But maybe it is a small chance to reduce the get_blog_list() to the
important parts, get blog list ID and not more to reduce to a fast simple
function.

Best
Frank
Post by Malte Witt
Post by Malte Witt
I stumbled upon this a few days ago, too.
In my opinion get_blog_list() is perfectly fine. The Codex and the source
is just saying: "For performance reasons this function is not
recommended."
Post by Malte Witt
That's true for installations with thousands of blogs. But I think most
multisite installations out there in the real world have 3 to 100 sites
and
Post by Malte Witt
they have a perfect valid usecase for get_blog_list().
If there is a no other reason why the function is deprecated (and I can't
see any) I would say just reactivate it and place a big warning sign in
the
Post by Malte Witt
Codex, that this function shouldn't be used in super-large multisite
installations.
In short: +1 for reactivation of get_blog_list().
It's really just a poorly written function. No caching, no LIMIT (but does
"limiting" with an array_slice()), hits every site's posts table, etc. This
is one of the more dangerous functions performance-wise in core (probably
the most dangerous) because of how nasty it can be. If you have thousands
of sites, you'll run out of memory. If you have hundreds of sites, it could
take a long while to run. Even if you only have a few dozen sites, if you
have large post tables, this could take a few seconds to calculate. If it
actually did a proper LIMIT for both $start and $num, it'd be a lot better
off, but it's still pretty lame.
I've always had in my head a more robust WP_Site_Query, to be modeled after
WP_User_Query, WP_Comment_Query, and WP_Query. Fully functional arguments,
proper limiting, only touching the blogs table (post count is superflous —
query it yourself only if or when you need it), having numerous filters and
built-in caching (WP_Comment_Query does this well, IIRC), declining to do
anything when wp_is_large_network(), etc. Even though we've yet to get
around to making such a replacement, I have no regrets for us marking
get_blog_list() deprecated. What a terrible function.
Nacin
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
Loading...