#16214 closed enhancement (fixed)
Custom Field "Name" and "Value" headers shouldn't show if there are no custom fields
Reported by: | markjaquith | Owned by: | garyc40 |
---|---|---|---|
Milestone: | 3.3 | Priority: | low |
Severity: | normal | Version: | 3.1 |
Component: | Editor | Keywords: | |
Focuses: | Cc: |
Attachments (4)
Change History (17)
#1
@
14 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
#4
follow-up:
↓ 6
@
14 years ago
The use of output buffering seems unnecessary — _list_meta_row()
is a returning function.
#5
@
14 years ago
ticket.16214.2.diff fixes the patch by checking for an underscore in the meta_key field.
#6
in reply to:
↑ 4
;
follow-up:
↓ 7
@
14 years ago
Replying to markjaquith:
The use of output buffering seems unnecessary —
_list_meta_row()
is a returning function.
Revised patch attached. What was I thinking when I wrote that? :)
Replying to ptahdunbar:
ticket.16214.2.diff fixes the patch by checking for an underscore in the meta_key field.
I don't think not outputting private meta fields is a good idea. Plugin developers might want to use custom private meta fields with javascript in their custom post types.
Other than that, the patch should also hide custom field table when you delete the last field.
#7
in reply to:
↑ 6
@
14 years ago
- Cc trac@… added
Replying to garyc40:
I don't think not outputting private meta fields is a good idea. Plugin developers might want to use custom private meta fields with javascript in their custom post types.
Do you have a use case for that? Private meta is typically reserved for core anyway.
Other than that, the patch should also hide custom field table when you delete the last field.
makes sense.
#8
follow-up:
↓ 9
@
14 years ago
Private meta is typically reserved for core anyway.
Not at all. It's the preferred way to store plugin custom fields that have their own UI.
#9
in reply to:
↑ 8
@
14 years ago
Replying to markjaquith:
Private meta is typically reserved for core anyway.
Not at all. It's the preferred way to store plugin custom fields that have their own UI.
Ah, good to know. Thx
#11
@
12 years ago
I think this is no longer valid since the rows have been combined: http://cl.ly/image/3s2D1a0Z071n Suggesting to close.
#12
@
12 years ago
- Keywords 3.2-early removed
- Milestone Future Release deleted
- Resolution set to invalid
- Status changed from assigned to closed
They haven't been combined. I don't really understand why that was showing in the first place - there's an inline display: none
on the top empty table that seems to be applying just fine. That hasn't changed, so I have no idea when or how this was fixed.
there's a patch for that