WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#14696 closed task (blessed) (fixed)

Personal Dashboard

Reported by: 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 6 years ago.
Dump of what I'm playing with
14696.2.diff (58.9 KB) - added by ryan 6 years ago.
14696.3.diff (684 bytes) - added by PeteMall 6 years ago.
Add hooks for user dashboard widgets.

Download all attachments as: .zip

Change History (29)

#1 @jane
6 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
6 years ago

  • Component changed from General to Multisite

#3 @wpmuguru
6 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
6 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
6 years ago

Dump of what I'm playing with

#5 @ryan
6 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
6 years ago

#6 @ryan
6 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
6 years ago

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

#8 @hakre
6 years ago

Related: #11517

#9 @voyagerfan5761
6 years ago

  • Cc WordPress@… added

#10 @nacin
6 years ago

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

@PeteMall
6 years ago

Add hooks for user dashboard widgets.

#11 @nacin
6 years ago

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

#12 @nacin
6 years ago

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

#13 @ryan
6 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
6 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
6 years ago

  • Cc tim@… added

#16 in reply to: ↑ 14 @nacin
6 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
6 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
6 years ago

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

#19 @ryan
6 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
6 years ago

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

#21 @westi
6 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
6 years ago

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

Dito for the menu filters.

#23 @PeteMall
6 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
6 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
6 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
6 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.