#13217 closed defect (bug) (fixed)
Use most recent instead of most used in add menu item boxes
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.0 | Priority: | normal |
| Severity: | normal | Version: | 3.0 |
| Component: | Menus | Keywords: | has-patch ux-feedback |
| Focuses: | Cc: |
Description
This was the only item left from #13134:
"are we doing most recent for pages? for both pages and cats it might be more useful than most used, b/c they'll likely go there when they add a new one, to add to menu"
Do we still want to do this?
Attachments (1)
Change History (19)
#3
@
16 years ago
Err, flip that. Most recent for any post type, most used for any taxonomy. Evidently I need some more sleep.
#6
@
16 years ago
- Milestone 3.0 deleted
- Resolution set to wontfix
- Status changed from assigned to closed
I'm thinking that this defies common expectation. Perhaps someone passionate about it can reopen.
#7
@
16 years ago
Common definitions mean you can't have "most used" pages. Most recently created for post types, and most used for taxonomies.
#8
@
16 years ago
- Milestone set to 3.0
- Resolution wontfix deleted
- Status changed from closed to reopened
After conversation with filosofo:
- [wontfix] It seems like consensus is to leave Most Used tab for taxonomies. I wasn't advocating for a change there.
- [needs-patch] New tab for post types called "Most Recent." Would show same # (I think 15) that taxonomies show for most used.
#9
@
16 years ago
- Owner set to filosofo
- Status changed from reopened to assigned
OK, I'll do this unless someone already has a patch.
#10
@
16 years ago
- Keywords has-patch added
Added "Most Recent" panel for post types, similar in behavior and markup to taxonomies' "Most Popular."
Cleaned up a couple of minor things:
- empty opening and closing PHP tags
- unnecessary Walker instantiations.
#13
@
16 years ago
UI: There seems to be different top/bottom padding going on between the recent tab and the view-all tab
UX: The tab makes sense, good idea
#14
@
16 years ago
On another note - the page labels aren't quite centered with the checkboxes, but this is true for all metaboxes, not just this one.
#15
@
16 years ago
johnonolan, any chance you could make a screenshot? I'm not seeing what you're referring to regarding the padding.
When you say "the page labels aren't quite centered with the checkboxes," do you refer to vertical alignment?
Knowing browser and OS info would be helpful too.
#16
@
16 years ago
Sorry about that - poor feedback on my part[[BR]]
I'm on a Mac, I see the vertical alignment issue with the checkboxes in mozilla only, webkit is fine.
Here's a screencast of the padding issue http://screenr.com/Lwp
#17
@
16 years ago
- Resolution set to fixed
- Status changed from assigned to closed
Thanks for the details.
I'd like to move this to separate tickets, since we're now dealing with issues orthogonal to this ticket's subject.
The padding issue is handled in #13497. Would you please test the patch there and confirm that it fixes the difference?
Regarding vertical alignment, I imagine this would affect all similar checkboxes throughout the WP admin (particularly those in lists, such as categories on the post edit page), so if you think it merits attention, would you please open a ticket regarding it?
From Jane: Yes. (And I agree.)
It'd be the last 15 created pages.