WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#17516 closed defect (bug) (wontfix)

Add Favorite Actions to Admin Bar

Reported by: technosailor Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.2
Component: Toolbar Keywords: has-patch
Focuses: Cc:

Description

With the new UI upgrade, the favorite_actions() method was removed from the main UI. After a brief discussion with Westi, it made sense to put the functionality back in as part of the adminbar.

The attached patch does that using the favorite_actions() method (which can now return the filtered list of favorite_actions as an array). We should eat our own dog food.

Attachments (6)

17516.diff (2.1 KB) - added by technosailor 10 years ago.
favorite_actions.jpg (17.1 KB) - added by technosailor 10 years ago.
Screenshot of new menu
17516-2.2.diff (2.1 KB) - added by technosailor 10 years ago.
17516-2.diff (2.0 KB) - added by technosailor 10 years ago.
Dont' do cap check because each action should provide its own checks.
17516-3.diff (5.3 KB) - added by technosailor 10 years ago.
Take 3. Lots of red. Wheeee! New patch allows for a string or an array to be passed. The array can have an optional cap. Unit test included as next attachment.
foo.php (330 bytes) - added by technosailor 10 years ago.
Unit test plugin for 17516-3.diff

Download all attachments as: .zip

Change History (16)

@technosailor
10 years ago

@technosailor
10 years ago

Screenshot of new menu

@technosailor
10 years ago

Dont' do cap check because each action should provide its own checks.

#1 @scribu
10 years ago

  • Component changed from General to Administration
  • Summary changed from Add Favorite Actions to Quick Bar to Add Favorite Actions to Admin Bar

I don't think simply moving the favorite actions to the admin bar is a good idea.

For example, there are two links to 'Comments' now.

Related: #17499

#2 @nacin
10 years ago

Per IRC discussion - cap check should go, as each favorite action has its own cap check. If the user doesn't have caps for any action, then the menu shouldn't be added.

I think we should cripple favorite_actions() to only return actions that were added via a filter. That way we offer some backwards compatibility without offering duplication. Otherwise, the various actions under "Add New" replace the core links, as well as the screen-dependent "Edit X" being added in #17499.

#3 @technosailor
10 years ago

Acknowledged. I'll put some cycles into that tonight or tomorrow. Should be simple.

@technosailor
10 years ago

Take 3. Lots of red. Wheeee! New patch allows for a string or an array to be passed. The array can have an optional cap. Unit test included as next attachment.

@technosailor
10 years ago

Unit test plugin for 17516-3.diff

#4 @jane
9 years ago

  • Cc daryl.koopersmith@… added
  • Version set to 3.2

Koop should look at this as part of admin bar redux he's working on now for 3.3, no? Probably would need a patch refresh to fit in?

#5 @technosailor
8 years ago

Marking this as wontfix as it's a moot point 2 years later.

#6 @technosailor
8 years ago

  • Keywords close added
  • Resolution set to wontfix
  • Status changed from new to closed

#7 @SergeyBiryukov
8 years ago

  • Component changed from Administration to Toolbar
  • Keywords has-patch added; close removed
  • Milestone Awaiting Review deleted

#8 @technosailor
8 years ago

Why reopen this? It should really be part of the MP6 development if anything....

#9 @SergeyBiryukov
8 years ago

I didn't reopen the ticket, just corrected the component and removed the milestone.

"close" keyword is for marking a ticket as a candidate for closure, no need to add it if you're actually closing the ticket.

#10 @technosailor
8 years ago

Ah cool. My bad. Thanks!

Note: See TracTickets for help on using tickets.