This basically works:
<?
$wp_user_search = $wpdb->get_results("SELECT ID, display_name, user_registered FROM $wpdb->users ORDER BY user_registered DESC LIMIT 7");
foreach ( $wp_user_search as $userid ) {
$user_id = (int) $userid->ID;
$user_login = stripslashes($userid->user_login);
$display_name = stripslashes($userid->display_name);
$return = '';
$return .= "\t" . '<li>'. $display_name .'</li>' . "\n";
print($return);
}
?>
Now I have to figure out how to split the return/echo stuff from the PHP…
What are the arguments against doing it this way? Are there better ways? Maybe using WP_User_Query somehow?
This also works:
<?php
$querystr = "
SELECT $wpdb->users.*
FROM $wpdb->users
ORDER BY $wpdb->users.user_registered DESC LIMIT 10
";
$listmembers = $wpdb->get_results($querystr, OBJECT);
?>
<?php if ($listmembers): ?>
<?php global $member; ?>
<?php foreach ($listmembers as $member): ?>
<?php setup_postdata($member); ?>
<p><? echo $member->display_name ?></p>
<?php endforeach; ?>
<?php else: ?>
<h2>You got nuthin...</h2>
<?php endif; ?>
Again, are there arguments against this approach? Is there a better way?
To get from here to the blog specific data raskull needed is another story of course. These multisite functions and methods could be useful.
Yes, WordPress Multisite was designed to with WordPress.com in mind as the sample.
It’s not a huge thing to code, it’s just no one’s done it and come back to say ‘This is what I did and how it works.’ It’s only custom because there wasn’t a need case. (I can think of maybe 5 times this has come up in 3 years, compared to over 300 times I’ve been asked why you can’t get rid of the /blog/ slug in SubDirectory installs. I’d really rather they fix the slug first 😉 )
As a stopgap, if you don’t want to write the calls yourself, you could use http://wordpress.org/extend/plugins/multisite-user-management/ and add them all to a ‘fake’ blog.
Or go check out BuddyPress. I’m sure it’s overkill for many people, but you can see how they make a list of all members. http://buddypress.org/community/members as an example. You could download their code and check it out.
Thanks for your response.
… over 300 times I’ve been asked why you can’t get rid of the /blog/ slug in SubDirectory installs …
That’s another one I wasted one or two days on solving.
Or go check out BuddyPress
I have tried Buddypress for about two years since it first came out and it just got worse and worse. I have just junked that pile of garbage and am now trying to simplify/streamline my projects on standard WP multisite with as few plugins as possible.
The Multisite User Management plugin is mentioned for every multisite user management problem and is simply not a solution. It only lets you manually add users to blogs on the network, which is useless if you try to use multisite for a company or membership organization.
Yes, WordPress Multisite was designed to with WordPress.com in mind as the sample.
Why?! Who would use it like that?
About 80% of Multisite users, at the last check (based on people who reply to such surveys), use Multisite for multiple, separate, sites. The other 10% either really want totally separate sites with separate user bases or, like you, a totally integrated site where everything’s shared.
Instead of trying to be all things for all people, WordPress said ‘This is what we are.’
It only lets you manually add users to blogs on the network, which is useless if you try to use multisite for a company or membership organization.
No, it lets you automatically assign users a role on a specific site on the domain. So let’s say you make a site called members. You set the plugin to make all new users ‘subscribers’ on the members blog. Then on the front page of the members site, you hard code the php for the members list (or use another plugin: http://wordpress.org/extend/plugins/members-list/ )
It’s not great I grant you, but it gets the job done if you don’t want the SQL query 🙂
And when I mentioned BuddyPress, please note I was specifically saying “You could download their code and check it out.” What I meant by that was not ‘use BuddyPress it will cure cancer!’ but ‘Look at their code, for the members page, and steal it.’
About 80% of Multisite users, at the last check (based on people who reply to such surveys), use Multisite for multiple, separate, sites
Who are these people? I really can’t imagine many cases where that would make much sense, except maybe a big hosting company or a blog farm advertising scam.
Those 80% are probably lots of kids in basements starting their own blog farms that never go anywhere.
WordPress is developed by and for PHP tinkerers, piling on features on top of “what it is” without much thought to what it could be, how it could be used in the real world.
Creating a members blog feels like a illogical workaround that will only cause problems down the line. It still wouldn’t help make a network-wide view of latest posts etc. easier to accomplish.
Apologies for hijacking/derailing this thread. Was the original question answered? In general, is there a way to make WP_user_query work in multisite, maybe in combination with the blog_id switch stuff?
In general, is there a way to make WP_user_query work in multisite, maybe in combination with the blog_id switch stuff?
Not without the DB query, as you noted, or adding all the users to a ‘member’ blog and calling it from there (which after I poked around, seems to be how BuddyPress does it).
I was having the same problem, then I decided to try using wp_user_query with a blog id of 0. This seems to return all users whether or not they are assigned to a blog. Let me know if you see any downsides.
About 80% of Multisite users, at the last check (based on people who reply to such surveys), use Multisite for multiple, separate, sites
Who are these people? I really can’t imagine many cases where that would make much sense, except maybe a big hosting company or a blog farm advertising scam.
Many of them are “Internet Marketers” trying to fool their world (Google) into thinking they have a lot of sites and jumping to the top of the search results for each product page/site.
