#16214 closed enhancement (fixed)
Custom Field "Name" and "Value" headers shouldn't show if there are no custom fields
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | low | Milestone: | 3.3 |
| Component: | Editor | Version: | 3.1 |
| Severity: | normal | Keywords: | |
| Cc: | trac@… |
Description
Attachments (4)
Change History (17)
comment:1
scribu
— 2 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
comment:3
garyc40
— 2 years ago
- Keywords has-patch needs-testing 3.2-early added; needs-patch removed
comment:4
follow-up:
↓ 6
markjaquith
— 2 years ago
The use of output buffering seems unnecessary — _list_meta_row() is a returning function.
ptahdunbar
— 2 years ago
ptahdunbar
— 2 years ago
comment:5
ptahdunbar
— 2 years ago
ticket.16214.2.diff fixes the patch by checking for an underscore in the meta_key field.
comment:6
in reply to:
↑ 4
;
follow-up:
↓ 7
garyc40
— 2 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.
comment:7
in reply to:
↑ 6
ptahdunbar
— 2 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.
comment:8
follow-up:
↓ 9
markjaquith
— 2 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.
comment:9
in reply to:
↑ 8
ptahdunbar
— 2 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
comment:10
georgestephanis
— 12 months ago
- Keywords needs-refresh added; has-patch removed
comment:11
kovshenin
— 5 months ago
I think this is no longer valid since the rows have been combined: http://cl.ly/image/3s2D1a0Z071n Suggesting to close.
comment:12
helen
— 5 months 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.
comment:13
SergeyBiryukov
— 5 months ago
- Keywords needs-testing needs-refresh removed
- Milestone set to 3.3
- Resolution changed from invalid to fixed
Fixed in [18445] by unsetting protected meta fields before printing the table (similar to what ticket.16214.2.diff suggested).
there's a patch for that