#19426 closed defect (bug) (fixed)
Need to support old admin bar node ID my-account-with-avatar
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | high | Milestone: | 3.3 |
| Component: | Toolbar | Version: | 3.3 |
| Severity: | normal | Keywords: | has-patch commit needs-refresh dev-reviewed |
| Cc: | johnbillion@… |
Description
In 3.2, the my account ID varied from my-account-with-avatar to my-account, depending on whether avatars were enabled. This was moved to classes in 3.3 where it belongs.
Unfortunately plugins may have been using my-account-with-avatar. We need to preserve these mappings.
A quick search of the directory found BuddyPress was among the plugins that did this. And smartly, for that matter -- $bp->my_account_menu_id = ( ! empty( $avatar ) ) ? 'my-account-with-avatar' : 'my-account';.
Patch incoming.
Attachments (5)
Change History (18)
I checked all of the IDs in 3.2 and the only other one is my-blogs to my-sites. Of note, blog-{$id} and blog-{$id}-* still work. BuddyPress and a few other plugins were using my-blogs.
comment:4
koopersmith — 18 months ago
Tested. Looks good to me.
Per #19429, we're going to want to map 'my-account' and 'my-account-with-avatar' to 'account'.
duck_ has pointed out that the first and third sprintf() arguments need to be reversed.
comment:8
johnbillion — 18 months ago
- Cc johnbillion@… added
comment:10
nacin — 18 months ago
- Keywords needs-refresh dev-reviewed added
Needs refresh, s/account/my-account/g.
comment:11
azaozz — 18 months ago
Looks good.
comment:12
ryan — 18 months ago
- Owner set to ryan
- Resolution set to fixed
- Status changed from new to closed
In [19555]:
comment:13
ryan — 18 months ago
In [19556]:

This would revive the mapping concept proposed in #19245. But the binding code is no longer the proper place for it. add_node() it is.