[wp-trac] [WordPress Trac] #19510: wp_print_styles() causing mid-page scripts/styles to bleed into admin

[WordPress Trac]

#19510: wp_print_styles() causing mid-page scripts/styles to bleed into admin
---------------------------+------------------
 Reporter:  AdamBackstrom  |       Owner:
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  3.3
Component:  Editor         |     Version:  3.3
 Severity:  critical       |  Resolution:
 Keywords:  dev-feedback   |
---------------------------+------------------

Comment (by nacin):

 While the Hotfix plugin could solve things, this problem is very difficult
 to identify without a bit of skill. A user will need to inspect styles to
 figure out that they are being printed by an errant stylesheet. The blind
 "Re-activate plugins one by one" will often be needed to find the culprit.

 I've seen a lot of situations where "Just install Hotfix" has been
 recommended even though the plugin will not address the problem. It
 muddies the plugin's usefulness -- it's best for when there is a targeted,
 specific error message that clearly shows that Hotfix needs to be used.
 And I'm not sure I like us relying on it to hit a deadline.

 I think the best and most targeted fix here is to simply not fire the
 wp_print_styles hook in the admin. Then come 3.4, we stop using
 wp_print_styles() in the admin all together, and if it is called in the
 admin, we `return print_admin_styles( $handle );`.

 I've posted to wpdevel: http://wpdevel.wordpress.com/2011/12/12/use-
 wp_enqueue_scripts-not-wp_print_styles-to-enqueue-scripts-and-styles-for-
 the-frontend/. *We* know that *_enqueue_scripts is proper, but most good
 developers — and anyone following the Codex — will be finding that they've
 been doing it wrong. If we punt this to 3.3.1, I won't strongly object,
 but I think we will be making a mistake.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19510#comment:15>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software