Weird style code in my website

That code isn’t malicious, and it could have been added by anything.

If you’re concerned, attempt to deactivate all plugins and switch to the default Twenty Twenty-Four theme. If the problem goes away, re-activate them one by one to identify the source of the problem.

If you can install plugins, install Health Check. On the troubleshooting tab, you can click the button to deactivate all plugins and change the theme for you while you’re still logged in without affecting normal visitors to your site.

DId you find what causes this? … having the same issue and it’s messing up some of my thumbnails on a client’s site

Please try the steps in my reply above.

FYI … seems like this was a code addition in WP 6.7.1 , it’s included in the wp-inlcudes/media.php :

/**

?* Prints a CSS rule to fix potential visual issues with images using sizes=auto.

?*

?* This rule overrides the similar rule in the default user agent stylesheet, to avoid images that use e.g.

?* width: auto or width: fit-content to appear smaller.

?*

?* @since 6.7.1

?* @see https://html.spec.whatwg.org/multipage/rendering.html#img-contain-size

?* @see https://core.trac.www.ads-software.com/ticket/62413

?*/

function wp_print_auto_sizes_contain_css_fix() {

/** This filter is documented in wp-includes/media.php */

$add_auto_sizes = apply_filters( 'wp_img_tag_add_auto_sizes', true );

if ( ! $add_auto_sizes ) {

return;

}

?>

<style>img:is([sizes="auto" i], [sizes^="auto," i]) { contain-intrinsic-size: 3000px 1500px }</style>

<?php

}

“Malicious”, no … but it doesn’t validate.

Now that we know it IS wordpress and NOT “added by anything, nothing to see here, move along, no help to be given” I gotta say … @gleysen well done! Thank you.

Via functions.php it’s pretty easy to filter out. Here’s my solution:

function remove_auto_sizes_css_fix($add_auto_sizes) {return false;}
add_filter(‘wp_img_tag_add_auto_sizes’, ‘remove_auto_sizes_css_fix’);

@macmanx, while I do realize you are likely volunteering to be a moderator, there isn’t much value in a response that shows no attempt at any research. Ideally, moderators would be aware of code changes in WordPress before repeatedly asking people to do the “disable everything” shuffle.

And I agree with, but would take @robin_dean ‘s approach one step further. Malicious code is defined by Google as:

Malicious code is any software, script, or program designed to harm, disrupt, or compromise systems and information.

Code which deteriorates a theme developer’s intentions and bloats themes by adding code to our sites which we do not need can easily be defined as harmful and certainly, for those of us who still believe in the mantra that “code is poetry,” it compromises our information.

That this thread exists is also evidence of disruption.

So yeah, fairly malicious code and arguably irresponsible moderation.

Thanks to the rest of the community here for actually working on a solution!

Ideally, moderators would be aware of code changes in WordPress

We do our best, but frankly there is often too much to keep track of in the meager free time we’re all able to volunteer to the project between our personal lives and real jobs. Track every change, keep the forums free from spam, attempt help people; pick 2.

Unfortunately, this is a change I was not aware of.

But the good news is, the team is always looking for new volunteers: https://make.www.ads-software.com/support/

More volunteers sharing the load means more time to keep track of every change.

Malicious code is defined by Google as

Fair enough, I was defining it as an exploit or vunerability.

That this thread exists is also evidence of disruption.

The developers don’t monitor these forums. If you want to reach them about this, please file a bug report: https://make.www.ads-software.com/core/handbook/testing/reporting-bugs/

arguably irresponsible moderation

No moderator actions were taken on this thread.

Just wanted to chip-in to say that we also had problems on one of our websites caused by this addition, and I think that this CSS must be removed from Core.

Whatever the intentions were, I am honestly quite baffled by the decision to add some frontend styling directly from WP Core. I think WP should not interfere with how the frontend looks, and indeed there isn’t any stylesheet loaded in frontend from Core. And that’s also the reason why these styles have been added in a quite hacky way, printing them out via a php filter…

Any developer with some experience in frontend knows that CSS “fixes” are a mine field. When you introduce a fix, it can easily conflict with some other styles applying only on specific locations other than the one that you tried to fix.

In my opinion it really doesn’t make sense to assume that you’re deploying that one CSS rule and it will fix all problems and work on any website using WP… And that’s why WP should not try to “fix” frontend styling, and it should just leave that to the frontend developers. They will eventually find a fix which is specific for their environment and the other thousands lines of CSS that they have to work with.

After that said, I didn’t mean to offend or point fingers! Mistakes happens and we all made wrong decisions sometimes. ??

This is how I tried to hacked it:

if ( ! function_exists( 'wp_print_auto_sizes_contain_css_fix' ) ) {
    function wp_print_auto_sizes_contain_css_fix() {
        // Do nothing, effectively disabling the function.
    }
}

Not completely working with Google PageSpeed Insights.

• This reply was modified 2 months ago by debbrancheau.

Here is the link to a ticket discussing this issue – https://core.trac.www.ads-software.com/ticket/62413

It seems to have something with the auto attribute being added to images with lazy loading.

Here is the suggested filter to remove this addition:

add_filter('wp_img_tag_add_auto_sizes', '__return_false');

Hello @rcneil and thanks for the tip!

I had a quick look at the thread and I see the reasons behind those edits. Though I am still wondering why the sizes “auto” is added even when WP default lazyload is not in use (we use our own lazyload integration), and why it’s added even if we already have another filter in place to disable the sizes attribute altogether (as well as the srcset, because we handle resizing dynamically via js based on actual container size rather than the window size).

To be honest I think that the sizes “auto” (and the consequent CSS fix) should have been added conditionally only if using the wp lazyload and only if the sizes attribute was actually meant to be print out, respecting the other filters that are already handling that attribute, rather than forcing us to add another filter (after spending time figuring out about the new need for it…).

in any case, thanks again for your help!

There is a fix provided from the Core team here as well.

<?php
add_filter(
        'wp_content_img_tag',
        static function ( $image ) {
                return str_replace( ' sizes="auto, ', ' sizes="', $image );
        }
);
add_filter(
        'wp_get_attachment_image_attributes',
        static function ( $attr ) {
                if ( isset( $attr['sizes'] ) ) {
                        $attr['sizes'] = preg_replace( '/^auto, /', '', $attr['sizes'] );
                }
                return $attr;
        }
);

Hello,

I keep running into customer websites who have this issue. It’s kind of worrisome that the core team knew this would be an issue, but still pushed it through AND didn’t even mention it in the release note.

Yes we all have this issue! It gives a penalty in our pagespeed rankings.

I am also afraid that this code also impact the LCP of the images overall, especially in mobile. I just cannot explain why the intrinsic size on mobile is… huge.

@vitaminssk we are using WP Rocket. Me thinks that this addition in the core just ruins WP Rocket’s own functionality. Any ideas?