Opened 15 years ago
Closed 14 years ago
#14696 closed task (blessed) (fixed)
Personal Dashboard
Reported by: |
|
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)
Change History (29)
#3
@
15 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
@
15 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! =/
#5
@
15 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
#6
@
15 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
#12
@
15 years ago
- Milestone changed from Awaiting Review to 3.1
- Type changed from feature request to task (blessed)
#16
in reply to:
↑ 14
@
14 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
@
14 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.
#19
@
14 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.
#21
@
14 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
@
14 years ago
I think that plugins should have to explicitly add notices to network/user admin screens.
Dito for the menu filters.
#23
@
14 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.
#25
@
14 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
@
14 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.
Changing this to feature request, since it's asking for the creation of a new section.