Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#14696 closed task (blessed) (fixed)

Personal Dashboard

Reported by: ryan's profile ryan Owned by:
Milestone: 3.1 Priority: normal
Severity: normal Version:
Component: Multisite Keywords:
Focuses: Cc:

Description

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.

Attachments (3)

14696.diff (32.5 KB) - added by ryan 13 years ago.
Dump of what I'm playing with
14696.2.diff (58.9 KB) - added by ryan 13 years ago.
14696.3.diff (684 bytes) - added by PeteMall 13 years ago.
Add hooks for user dashboard widgets.

Download all attachments as: .zip

Change History (29)

#1 @jane
14 years ago

  • Type changed from defect (bug) to feature request

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

#2 @scribu
14 years ago

  • Component changed from General to Multisite

#3 @wpmuguru
14 years ago

+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.

#4 in reply to: ↑ description @markmcwilliams
14 years ago

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
13 years ago

Dump of what I'm playing with

#5 @ryan
13 years ago

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
13 years ago

#6 @ryan
13 years ago

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


#7 @ryan
13 years ago

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

#8 @hakre
13 years ago

Related: #11517

#9 @voyagerfan5761
13 years ago

  • Cc WordPress@… added

#10 @nacin
13 years ago

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

@PeteMall
13 years ago

Add hooks for user dashboard widgets.

#11 @nacin
13 years ago

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

#12 @nacin
13 years ago

  • Milestone changed from Awaiting Review to 3.1
  • Type changed from feature request to task (blessed)

#13 @ryan
13 years ago

(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

#14 follow-up: @ryan
13 years ago

(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

#15 @tmoorewp
13 years ago

  • Cc tim@… added

#16 in reply to: ↑ 14 @nacin
13 years ago

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.

#17 @westi
13 years ago

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.

#18 @nacin
13 years ago

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

#19 @ryan
13 years ago

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.

#20 @ryan
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

#21 @westi
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#22 @scribu
13 years ago

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

Dito for the menu filters.

#23 @PeteMall
13 years ago

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.

#24 @nacin
13 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#25 @nacin
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#26 @westi
13 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.