WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 8 months ago

Last modified 8 months 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 3 years ago.
favorite_actions.jpg (17.1 KB) - added by technosailor 3 years ago.
Screenshot of new menu
17516-2.2.diff (2.1 KB) - added by technosailor 3 years ago.
17516-2.diff (2.0 KB) - added by technosailor 3 years ago.
Dont' do cap check because each action should provide its own checks.
17516-3.diff (5.3 KB) - added by technosailor 3 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 3 years ago.
Unit test plugin for 17516-3.diff

Download all attachments as: .zip

Change History (16)

technosailor3 years ago

technosailor3 years ago

Screenshot of new menu

technosailor3 years ago

technosailor3 years ago

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

comment:1 scribu3 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

comment:2 nacin3 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.

comment:3 technosailor3 years ago

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

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

technosailor3 years ago

Unit test plugin for 17516-3.diff

comment:4 jane3 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?

comment:5 technosailor8 months ago

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

comment:6 technosailor8 months ago

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

comment:7 SergeyBiryukov8 months ago

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

comment:8 technosailor8 months ago

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

comment:9 SergeyBiryukov8 months 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.

comment:10 technosailor8 months ago

Ah cool. My bad. Thanks!

Note: See TracTickets for help on using tickets.