WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 15 months ago

Last modified 15 months ago

#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:

Description

http://grab.by/grabs/f8a2db4bc7601c50a1fab29861f21d58.png

Attachments (4)

garyc40.16214.diff (2.7 KB) - added by garyc40 3 years ago.
there's a patch for that
ticket.16214.diff (1.0 KB) - added by ptahdunbar 3 years ago.
ticket.16214.2.diff (535 bytes) - added by ptahdunbar 3 years ago.
garyc40.16214.2.diff (2.6 KB) - added by garyc40 3 years ago.
don't use output buffering

Download all attachments as: .zip

Change History (17)

comment:1 scribu3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

comment:2 garyc403 years ago

  • Owner set to garyc40
  • Status changed from new to assigned

garyc403 years ago

there's a patch for that

comment:3 garyc403 years ago

  • Keywords has-patch needs-testing 3.2-early added; needs-patch removed

comment:4 follow-up: markjaquith3 years ago

The use of output buffering seems unnecessary — _list_meta_row() is a returning function.

ptahdunbar3 years ago

ptahdunbar3 years ago

comment:5 ptahdunbar3 years ago

ticket.16214.2.diff fixes the patch by checking for an underscore in the meta_key field.

garyc403 years ago

don't use output buffering

comment:6 in reply to: ↑ 4 ; follow-up: garyc403 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 ptahdunbar3 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: markjaquith3 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 ptahdunbar3 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 georgestephanis22 months ago

  • Keywords needs-refresh added; has-patch removed

comment:11 kovshenin15 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 helen15 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 SergeyBiryukov15 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).

Note: See TracTickets for help on using tickets.