Personal Dashboard

[ryan]

Similar to what was done for the Network Admin, let's create a separate "personal" dashboard. This would provide a single endpoint for accessing profile information, cross-site preferences, a launching point for accessing all of a user's blogs, collation of stats across all of a user's blogs, a place for a multisite aware quick press, etc. This would also allow us to drop the rather clumsy "dashboard blog" concept.

/wp-admin/me/, / wp-me/, /wp-admin/you/, /wp-you/, etc. are some possible locations for this personal admin area.

UI/UX for switching between the site admin, network admin, and personal admin would need to be considered.

[jane]

Changing this to feature request, since it's asking for the creation of a new section.

[wpmuguru]

+1

I like /wp-admin/me/ or suggest /my-admin/. Having it under wp-admin would probably make for less work but something like /my-admin/ would make it more personal.

[markmcwilliams]

BIG +1 from me! :)

Having said to Andrea, and Ron, in a little discussion on Twitter about how I thought that Dashboard Blog thing was just a little confusing, and that it needed a little bit of TLC to make it better!

Much as I don't like the /wp-*/ prefix, I would say whatever location we give this, it still needs to fall under the /wp-admin/ folder, still is admin stuff at the end of the day. Unless of course we could play with /global/ or words to that effect?

But yes, this is much needed, and damn I wish I knew how to code! =/

[ryan]

Dump of what I'm playing with

[ryan]

The patch wanders off into network admin cleanup territory. Some of the same fixes are needed for both network and user admin.

The user admin part of this is purposefully limited to offering a way to get rid of the dashboard blog stuff. If a user does belong to a blog, then all user related stuff happens there and not in the user admin. The scope can be expanded later.

• wp-admin/user/
• user_admin_url()
• is_user_admin()
• Fix $pagenow detection for network and user admins
• Add an 'exist' capability that all users have, even if they don't have a role on a blog. current_user_can('exist'), yeah, cute. Suggestions welcome.
• auth_redirect() only requires the logged_in cookie for user admin
• Removes adding user to dashboard blog. Hooray.
• Appends '-network' and '-user' to the screen ids for network and user admin screens, respectively.
• add_screen_option() for registering per_page screen options instead of special casing them in screen_options()
• Call add_screen_option() for all admin pages that have a per_page option
• Fix the dashboard so that it cap checks each dashboard module and only shows blog specific modules in the blog admin
• Fixes for network screens that were missing screen icons

[ryan]

In addition to the above:

• Almost completely remove dashboard blog concept. get_dashboard_blog() remains for back compat
• Redirect to user admin after login if the user doesn't have a blog
• Register layout columns via add_screen_option()
• Make the dashboard screen options and boxes independent for user admin

[ryan]

(In [15746]) First pass of user admin. Network admin and screen cleanups. see #14696

[hakre]

Related: #11517

[nacin]

(In [15879]) Doc blocks for wp-admin/user. see #14696.

[PeteMall]

Add hooks for user dashboard widgets.

[nacin]

(In [15900]) Hooks for user dashboard. props PeteMall, see #14696.

[ryan]

(In [16083]) get_dashboard_url() and get_edit_profile_url(). Determine the appropriate dahboard for a user based on the user's blogs and the current blog. see #14696 #14772

[ryan]

(In [16224]) Issue user_admin_notices for user admin. Issue admin_notices only for blog admin. Issue all_admin_notices for all dashboards. see #14696

[nacin]

Replying to ryan:

(In [16224]) Issue user_admin_notices for user admin. Issue admin_notices only for blog admin. Issue all_admin_notices for all dashboards. see #14696

Thinking we should make admin_notices everywhere, then blog_admin_notices otherwise. If a plugin wants to spit something out on admin_notices, like Hello Dolly for example, they need to hook all three. It's kind of weird, and often they're going to be doing special detection to see if the current screen is what they want.

This is also consistent with the is_admin() function and its children.

There is probably a use case I am thinking of where the current setup in [16224] is desirable -- perhaps Akismet's use case? It should be noted that admin_notices would have shown up on the profile (with the dashboard blog) and under Super Admin, so there's no regression.

[westi]

I would have thought that admin_notices should fire as much as it used to and we should introduce three new ones which we encourage people to switch to for better target ting in multisite.

[nacin]

(In [16292]) blog_admin_notices for non-network-non-user, admin_notices for all. see #14696.

[ryan]

admin_notices annoyed the hell out of my on wordpress.com because of mis-targeted stuff in the user and network admins. No big deal though.

[westi]

Maybe we should reconsider this last change - as we have it now lots of plugins will end up adding notices everywhere - user/network admin which probably have no place there

[scribu]

I think that plugins should have to explicitly add notices to network/user admin screens.

Dito for the menu filters.

[PeteMall]

Replying to westi:

Maybe we should reconsider this last change - as we have it now lots of plugins will end up adding notices everywhere - user/network admin which probably have no place there

Plugins like akismet add links in the admin notices which don't exist for the net/user admin.
My suggestion:

• admin_notices for blog admin
• network_admin_notices for network admin
• user_admin_notices for user admin
• all_admin_notices for all

This will preserve backward compatibility.

[nacin]

(In [17016]) Revert [16292], admin_notices for non-network non-user only. all_admin_notices for all. fixes #14696.

[nacin]

So I just reverted this, but then I saw my comment above and changed my mind again.

It should be noted that admin_notices would have shown up on the profile (with the dashboard blog) and under Super Admin, so there's no regression.

I'm curious that a MU management plugin or a plugin modifying user profiles might have relied on admin_notices. Now this will no longer works. Then again, the whole plugin no longer works either, but that's another story.

Happy to see this closed as fixed by ryan or westi. Just wanted to leave this last thought on here.

[westi]

Closing as Fixed.

We talked about this in IRC yesterday.

In general it seems likely that this solution is best for existing plugins.

The few MS plugins that were using this hook will need work to work in the Network Admin anyway and this gives us the best balance of backwards compatibility and better targeting going forwards.