Enqueued styles are only printed on login_footer in wp-login.php

[Cimmo]

In my plugin I have this include:
wp_register_style("cimy_uef_register", $cuef_css_webpath."/cimy_uef_register.css", false, false);

now independently where and when I use the above css, even if I never enqueue or print it... it basically forces the admin panel to be always left instead of the right.

In particular it changes the admin panel menu #adminmenu to stick to the left, also other little things.
The question is:
why this happens even if the CSS is not included at all? Browsing the documentation quickly on that function I didn't find anything useful, please help me.

[Cimmo]

Forgot to say that obviously I forced to be RTL in wp-config.php
$text_direction = 'rtl';

so I wouldn't expect that a simple wp_register_style screws up things.

[Cimmo]

One more funny thing:
even if I register a non existent css file, bug occurs, so I think is something in wp code :P

[kawauso]

I can't reproduce on trunk.

[Cimmo]

Checked out trunk from today, perfectly reproducible.

[dd32]

Please attach a plugin which shows can be used to reproduce this on a stock installation, with no other plugins active.

[dd32]

I'm closing this as worksforme for one reason: It works, and that example doesn't do anything at all (other than create a PHP notice due to the mis-use of the $cuef_css_webpath variable).

If you can provide an example which, on a stock install, ie. a clean install, can reproduce the problem, please post a followup comment

As a way of testing the php-notice impacts upon your install, you can test with this (which will do exactly as your attachment - nothing)

wp_register_style("cimy_uef_register", "404-style.css", false, false);

[Cimmo]

The freaking example works and you have also to add in the wp-config.php: $text_direction = 'rtl'; as said in the comments, if you don't believe me check these screenshots, before and after enabling the plugin I attached.

[albertolau]

Cimmo, i have the same problem. until they figure out a solution you can try doing all your wp_register_style in a hook that is after load_textdomain

function proof_of_concept_init(){
	wp_register_style( 'debug-handle', 'doesntmatters/if/it/exists.css', array(),'1.0.0');
} 

add_action('after_setup_theme','proof_of_concept_init');

[SergeyBiryukov]

Like wp_register_script(), wp_register_style() also shouldn't be called before init, since locale isn't initialized yet (see #11526).

I've updated the patch in #11526 to include _doing_it_wrong() for $wp_styles.

I've also added a note in Codex with this ticket as a reference.

[Cimmo]

Ok my bad but still I don't get it when to use exactly wp_register_style and wp_enqueue_style
I need the css file in the login/registration pages only and I tried this code:

function cimy_uef_register_init_css() {
	global $cuef_css_webpath;
	wp_register_style("cimy_uef_register", $cuef_css_webpath."/cimy_uef_register.css", false, false);
	wp_enqueue_style("cimy_uef_register");
}

add_action('wp_print_styles', 'cimy_uef_register_init_css');

but works only for WordPress MS, not for non-MS. Using 'after_setup_theme' hook has same effect.

[SergeyBiryukov]

For login/registration pages, I'd try login_head or login_enqueue_scripts action:

function cimy_uef_register_init_css() {
	global $cuef_css_webpath;
	wp_register_style("cimy_uef_register", $cuef_css_webpath."/cimy_uef_register.css", false, false);
	wp_enqueue_style("cimy_uef_register");
	wp_print_styles();
}

add_action('login_enqueue_scripts', 'cimy_uef_register_init_css');

Someone may correct me if I'm wrong, but it looks like we should call wp_print_styles() or wp_print_scripts() ourselves in this case.

[Cimmo]

Adding
wp_print_styles();

Fixes the issue, but afaik that is not needed elsewhere, how is that?

[SergeyBiryukov]

wp_print_styles() is only called automatically for wp_head, not for login_head.

I guess that's for a reason, since most of the time custom styles should only be included on frontend.

[Cimmo]

but registration page is part of the front-end, anyways not a big deal, I fixed my issue, thank you!

[nacin]

Since we have wp_enqueue_scripts, we should do the printing.

[SergeyBiryukov]

Replying to nacin:

Since we have wp_enqueue_scripts, we should do the printing.

17916.patch​ adds wp_print_styles() on login_head.

[Cimmo]

I applied the patch to WP 3.2.1 and does not fix the issue for me, still needs wp_print_styles();

[Cimmo]

Problem is in the patch:
add_action( 'login_head', 'wp_print_styles', 8 );

and when adding an action to login_head without priority this is set by default to 10 that means will be runned _after_ that.
So either the patch should have a higher number or I have to setup a lower one in my code.

Problem is: how authors can understand they have to use priority < 8 to have this working properly? You should document it somewhere.

[SergeyBiryukov]

With the patch applied, the right hook for enqueuing styles would be wp_print_styles, not login_head.

I used the same priority as in wp_head:
​http://core.trac.wordpress.org/browser/tags/3.2.1/wp-includes/default-filters.php#L211

[nacin]

Actually, the best hook is wp_enqueue_scripts. There are equivalent login_ and admin_ versions as well.

[Cimmo]

With the patch applied, the right hook for enqueuing styles would be wp_print_styles, not login_head.

Not really if you want to add the css only in the registration page for example instead of spamming everything.

Actually, the best hook is wp_enqueue_scripts. There are equivalent login_ and admin_ versions as well.

Exactly! 'login_enqueue_scripts' is the right one, thanks.
I think patch can be applied then and documentation you'll find the best way to mention this I guess.

[Cimmo]

nacin can we have the go for this patch? This bug is causing me issues
​http://wordpress.org/support/topic/plugin-cimy-user-extra-fields-wrong-background-for-login-page

[Cimmo]

Replying to Cimmo:

nacin can we have the go for this patch? This bug is causing me issues
​http://wordpress.org/support/topic/plugin-cimy-user-extra-fields-wrong-background-for-login-page

Actually a side effect of the patch is with Suffusion theme installed the login/registration page is totally screwed.
I think that the problem is on theme side. Will contact the author.

[Cimmo]

Replying to Cimmo:

Actually a side effect of the patch is with Suffusion theme installed the login/registration page is totally screwed.
I think that the problem is on theme side. Will contact the author.

Filed a ticket on their side:
​http://aquoid.com/forum/viewtopic.php?f=2&t=6417

[Cimmo]

Suffusion issue fixed in version 3.8.9
Please apply this patch before 3.3 release!

[Cimmo]

Sorry to bother, but patch is not yet applied WordPress 3.3 beta3 any chance to get this before release candidates?

Thank you.

[azaozz]

Still not clear what would be best there, the login screen is "special", not a part of the admin, not really a part of the front-end... And we don't want many scripts loading there for better security.

Think we need to talk/clarify the concept first before adding more auto-run stuff.

[husobj]

+1 for this patch

Works fine for me if correct hooks are used for queuing: login_enqueue_scripts / admin_enqueue_scripts / wp_enqueue_scripts

I guess it's just older themes/plugins using the wrong hooks that could potential affect styling?

[husobj]

Also note that wp_print_footer_scripts() is called via filter in the login footer anyway so why not load the scripts in the header like everywhere else?

[SergeyBiryukov]

Replying to husobj:

Also note that wp_print_footer_scripts() is called via filter in the login footer anyway so why not load the scripts in the header like everywhere else?

wp_print_head_scripts() is called as well, the patch adds wp_print_styles().

[husobj]

Replying to SergeyBiryukov:

Replying to husobj:

Also note that wp_print_footer_scripts() is called via filter in the login footer anyway so why not load the scripts in the header like everywhere else?

wp_print_head_scripts() is called as well, the patch adds wp_print_styles().

wp_print_footer_scripts() triggers an action
which calls _wp_footer_scripts()
which calls print_late_styles()

...so the styles get loaded in the footer of the login page anyway.

[SergeyBiryukov]

Replying to husobj:

...so the styles get loaded in the footer of the login page anyway.

Indeed, since [18446].

So 17916.patch​ just makes it consistent with wp_print_head_scripts(), no new styles are added (which I guess was the concern in comment:30).

[Cimmo]

Replying to SergeyBiryukov:

So 17916.patch​ just makes it consistent with wp_print_head_scripts(), no new styles are added (which I guess was the concern in comment:30).

Also:
how a CSS could be of any security threat?

[nacin]

This seems good.

[nacin]

I think this patch revives ​http://make.wordpress.org/core/2011/12/12/use-wp_enqueue_scripts-not-wp_print_styles-to-enqueue-scripts-and-styles-for-the-frontend/. This is probably time to create a new function, such as wp_print_head_styles() (like wp_print_head_scripts), that does not accept a set of handles, and simply does the printing. Otherwise, calling wp_print_styles() in this case will fire the wp_print_styles hook.

[SergeyBiryukov]

#33922 was marked as a duplicate.

[diddledani]

I independently came to the same conclusion as @SergeyBiryukov, and provided semantically the same patch in the duplicate issue #33922. I believe that this ticket should be marked as has-patch, so I've done that with this comment :-)

[ocean90]

#35896 was marked as a duplicate.

[SergeyBiryukov]

Note: login_head triggers print_admin_styles() since [36341].