How do you Properly Query Posts in a Multisite Network?

Perhaps simply using WPMU’s switch_to_blog would be appropriate, however very intensive when used across several hundred Pages.

<?php switch_to_blog(2); ?>
// do stuff
<?php restore_current_blog(); ?>

My guess is this would probably OK so long as W3 Total Cache stores this Page output to alleviate some of the burden.

Gather all your posts into one blog with this plugin:

https://www.ads-software.com/extend/plugins/wordpress-mu-sitewide-tags/

Hi! Always lovely to have your thoughts.

Alas, I was hoping to avoid leaning on that specific plugin to do this, but I can see that as of WP3.1 there’s still a lot of drama surrounding switch_to_blog and W3 Total Cache (#14992).

Seems like it’s one or the other at this point.

Correct me if I’m wrong, but it would appear that unless I’m using Sitewide Tags, there’s now little difference between folding the travelogue into a Multisite network or leaving it be on a single install. (as it pertains to pulling posts in a category with a custom field, that is)

except wp super cache works just fine with SWT as they are from the same developer.

SWT does what you want.

that link about querying posts is for within one install – not for getting posts from a separate install into another one.

Right. It’s my understanding that WP Super Cache isn’t having the same conflicting problems with switch_to_blog that W3 Total Cache is. Or maybe it’s just going unreported. I don’t know.

I certainly have no doubt that SWT is the answer for most folks, but I’m not supporting a large network, simply the root and one sub-site.

However, as I’m on shared hosting, the bottom line on all this will be what ultimately consumes fewer server resources:
1) using caching with SWT;
2) using caching with switch_to_blog; or
3) using caching with a custom select query

1) using caching with SWT;

this one.

You only have TWO blogs.

Yeah, #2 wouldn’t work well anyway. Use Caching and SWT. Works fine ??

Thanks for your thoughts you two. Will have to look into if option #3 is just as speedy (cached), as my desire to not maintain/bloat with another plugin is high on my list. SWT seems to be the answer repeated again and again (for good reason), but I’m not one to shy away from the less traveled road.

I think querying multiple tables and merging the info will be more CPU intensive than just doing that with SWT personally (there’s a reason that’s currently the way we do it ?? ) but I’m not the best with SQL queries.

FYI:
This is just a follow-up for searchers who come across this topic.

With the awesome help of Curtiss, there’s another option on the table for people to consider.

I used this for Pages on site #1 where I wanted to pull and list Posts out of site #2.

global $wpdb;
$wpdb->set_blog_id(2);
$wpdb->set_prefix($wpdb->base_prefix);

--- YOUR CODE ---

$wpdb->set_blog_id(1);
$wpdb->set_prefix( $wpdb->base_prefix );

Detailed examples can be found here.

Enjoy!

I strongly recommend that you do not use the code snippet as an alternative to switch_to_blog().

I am developing a network wordpress site and I would like to have all posts shown (and searcheable) in the main page.

From what I have read in many forums, it allways comes back to SWT. However one can see that wordpress.com itself has this feature and they should be using an enhanced version of the wordpress script, I trust.

How do they do it? No site would be bigger so they must have it fully dialed. It can’t be just hardcore servers running the core functions of wordpress, can it?

Thanks

They are using something similar to SWT.

Someone suggested preparing a batch that would copy and update all posts from the subsites to the main site overnight.

Is this similar to the SWT approach?

Yes. that’s exactly what it does. Why reinvent the wheel?

The guy who made the3 SWT plugin works for wp.com.

The stuff on the front page of wp.com is actually hand selected, not pulled in automatically from all blogs. They have *millions*.