current wp-login.php call to wp_admin_css() bypasses its own filter

[F J Kaiser]

The current situation in wp-login.php looks like the following:

	wp_admin_css( 'login', true );
	wp_admin_css( 'colors-fresh', true );

Looking at /wp-includes/general-template.php and wp_admin_css( $file = 'wp-admin', $force_echo = false ); tells that this bypasses the filter calls as the function returns if $force_echo is true. The filters are called after that. This doesn't make sense as the filter will never work this way. Changing wp_admin_css() is no option, so I suggest to change the calls to it in login_head.

[nacin]

Duplicate of #14559?

[F J Kaiser]

Replying to nacin:

Duplicate of #14559?

Afaik, wp-login.php doesn't behaves like this.

[ocean90]

Comment from nacin:

Core CSS files will get processed via WP_Styles, so the filter isn't very helpful anymore.

The filter wp_admin_css will never be fired for core files, no matter if $force_echo is true or false. If you use a custom file the filter can be used.

Behaviour introduced in #7011.

[Ninos Ego]

I hope in the next version you can fix this bug. Because I want to do all things with wordpress, and this issue is like a jail for me. I have got a custom login stylesheet. 80% of the code are !important atribute. Beyond my login page is not compatible with other browsers..

[ocean90]

Version number indicates when the bug was initially introduced/reported.

[DrewAPicture]

As @ocean90 notes in comment:6, the wp_admin_css filter will never be fired for core files — if a custom file is passed, the filter will fire. This is a feature, not a bug.

In a way, it is conceptually similar to the admin_body_class filter: core admin body classes can't be filtered, but new ones can be tacked on.