WordPress.org

Make WordPress Core

#21203 closed defect (bug) (fixed)

A CPT named 'code' triggers wierd font/order bugs in admin

Reported by: clarklab Owned by: nacin
Milestone: 3.5 Priority: normal
Severity: minor Version: 3.0
Component: UI Keywords: has-patch
Focuses: Cc:

Description

When you make a custom post type named 'code', some weird problems arise. In the admin, the post list is rendered in Consalas (see attachment). Even weirder, the default sort changes to alpha order, not date.

The font looks to be happening because the class 'code' gets added to the TR in the post list, but I'm not sure why the order would change.

I checked for a reserved CPT name, but all the codex said was to avoid the wp_ prefix.

Attachments (4)

2012-07-09_111610.png (36.8 KB) - added by clarklab 22 months ago.
the post listing rendered in the wrong font.
21203.patch (314 bytes) - added by c3mdigital 22 months ago.
21203.1.patch (489 bytes) - added by c3mdigital 22 months ago.
21203.2.patch (464 bytes) - added by c3mdigital 22 months ago.
Wraps post type in in is_admin

Download all attachments as: .zip

Change History (15)

clarklab22 months ago

the post listing rendered in the wrong font.

c3mdigital22 months ago

comment:1 follow-up: c3mdigital22 months ago

  • Component changed from Post Types to UI
  • Keywords ui-feedback has-patch added; needs-patch removed
  • Version changed from 3.4.1 to 3.0

Was not able to reproduce sort order but confirmed font changing. Is the .code css class used anywhere in admin?

comment:2 in reply to: ↑ 1 ; follow-up: helenyhou22 months ago

Replying to c3mdigital:

Is the .code css class used anywhere in admin?

Yes - quite a few places. Things like inputs, especially those containing code or URL entry, and some lists (files to delete, etc.).

comment:3 in reply to: ↑ 2 c3mdigital22 months ago

Replying to helenyhou:

Replying to c3mdigital:

Is the .code css class used anywhere in admin?

Yes - quite a few places. Things like inputs, especially those containing code or URL entry, and some lists (files to delete, etc.).

Just did a search and found around 20 uses so removing .code from css is not an option.

comment:4 follow-up: scribu22 months ago

  • Keywords needs-patch added; has-patch removed

I assume the issue here is that there's some css class being generated based on the post type name.

We should prefix that class, to avoid collisions. Example: class="cpt-<?php echo $post_type; ?>".

comment:5 scribu22 months ago

  • Keywords ui-feedback removed

comment:7 in reply to: ↑ 4 c3mdigital22 months ago

Replying to scribu:

I assume the issue here is that there's some css class being generated based on the post type name.

We should prefix that class, to avoid collisions. Example: class="cpt-<?php echo $post_type; ?>".

Makes sense but would require changing get_post_class:


        $classes[] = 'post-' . $post->ID;  
	$classes[] = $post->post_type;  
	$classes[] = 'type-' . $post->post_type;  
	$classes[] = 'status-' . $post->post_status;  

Might break some themes.

comment:8 nacin22 months ago

$classes[] = $post->post_type; — introduced in [8641]. We can solve this for the admin by putting an is_admin() around that single class.

c3mdigital22 months ago

comment:9 c3mdigital22 months ago

  • Keywords has-patch added; needs-patch removed

c3mdigital22 months ago

Wraps post type in in is_admin

comment:10 SergeyBiryukov22 months ago

  • Milestone changed from Awaiting Review to 3.5

comment:11 nacin19 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [21848]:

Don't output the {$post_type} post class in the admin, to avoid clashes with admin CSS. props c3mdigital. fixes #21203.

Note: See TracTickets for help on using tickets.