WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 8 years ago

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

Download all attachments as: .zip

Change History (17)

#1 @scribu
10 years ago

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

#2 @garyc40
10 years ago

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

@garyc40
10 years ago

there's a patch for that

#3 @garyc40
10 years ago

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

#4 follow-up: @markjaquith
10 years ago

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

#5 @ptahdunbar
10 years ago

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

@garyc40
10 years ago

don't use output buffering

#6 in reply to: ↑ 4 ; follow-up: @garyc40
10 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
10 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
10 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
10 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
8 years ago

  • Keywords needs-refresh added; has-patch removed

#11 @kovshenin
8 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
8 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
8 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.