WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 5 years ago

Last modified 5 years 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 7 years ago.
there's a patch for that
ticket.16214.diff (1.0 KB) - added by ptahdunbar 7 years ago.
ticket.16214.2.diff (535 bytes) - added by ptahdunbar 7 years ago.
garyc40.16214.2.diff (2.6 KB) - added by garyc40 7 years ago.
don't use output buffering

Download all attachments as: .zip

Change History (17)

#1 @scribu
7 years ago

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

#2 @garyc40
7 years ago

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

@garyc40
7 years ago

there's a patch for that

#3 @garyc40
7 years ago

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

#4 follow-up: @markjaquith
7 years ago

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

#5 @ptahdunbar
7 years ago

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

@garyc40
7 years ago

don't use output buffering

#6 in reply to: ↑ 4 ; follow-up: @garyc40
7 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 @ptahdunbar
7 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: @markjaquith
7 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 @ptahdunbar
7 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

#10 @georgestephanis
6 years ago

  • Keywords needs-refresh added; has-patch removed

#11 @kovshenin
5 years ago

I think this is no longer valid since the rows have been combined: http://cl.ly/image/3s2D1a0Z071n Suggesting to close.

#12 @helen
5 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.

#13 @SergeyBiryukov
5 years 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.