Images Inserted into a Post Using Links with Center Alignment, Edited and Saved as HTML, Display Left Aligned

[ann47he1rpjggx6f3yso]

I believe a bug was introduced in WordPress v6.9 and the v6.9.1 upgrade did not resolve it.

The bug involves images inserted into a post using links with center alignment, edited and saved as HTML.

I have verified that the issue presents when using other themes to rule out the possibility of my theme being the issue. I have also verified that the issue presents after disabling most of my plugins (one by one), with the exception of Force Login, UpdraftPlus - Backup/Restore, and Wordfence Security. I did not disable those plugins because I don't think they would impact how WordPress generates pages.

Following is the process, in detail, that I have used for a number of years without issue until the WordPress 6.9 upgrade.

First I upload the image(s) I plan to use in a post to my server using SFTP.

Then I commence to insert the image(s) into a post using the / Image option. I select the Align Center option, click the Insert from URL option, and then I enter the URL to the image location on my server.

Link:​https://imgbox.com/75oGasc5

After the image appears, I then click the far right option (three dots stacked vertically) and select Edit as HTML.

Link:​https://imgbox.com/HZFITFSM

I then enter a custom CSS class to make higher spacing above and/or below the image.

Link:​https://imgbox.com/VCncuYnh

When I click out of the code area, I get the following error:

Link:​https://imgbox.com/eyxk0Gpj

At that point, I click the far right option (three dots stacked vertically) and select the Convert to HTML option and then I save the post.

Link:​https://imgbox.com/4oBGjEmr

However, after upgrading to WordPress 6.9, as well as WordPress 6.9.1, the aligncenter part of the code is basically ignored.

Link:​https://imgbox.com/HgbUdJV5

Following is one of the custom CSS classes that I created and use for more white space above and/or below images:

.image-margin-default {
  margin-bottom: 30px;
  margin-top: 30px;}

A workaround would be just to not edit the inserted images as HTML and use the code editor to insert my CSS custom class. However, that leaves the ugly error referenced above in my posts and I would have to use the code editor to view the image code or to make any necessary future changes. I think things should work as they did prior to the WordPress v6.9 upgrade.

[SirLouen]

@ann47he1rpjggx6f3yso I think this issue was been already reported here #64354
AFAIK, there is a problem with block styles being loaded on demand in classic themes hence this error appears but it was closed, so I'm not 100% confident.

Can you test this plugin to see if this fixes it for you?
​https://wordpress.org/plugins/load-combined-core-block-assets/

Want to double check with @westonruter

PS: Setting close as potential dupe of #64354

[westonruter]

Remaining issues with CSS introduced in 6.9/6.9.1 I'm hoping to have resolved by #64389, assuming they are all related.

See also #64710 and my most recent comment.

I've had a very hard time getting people to test the CSS fixes I've been working on, so any feedback would be very helpful.

[ann47he1rpjggx6f3yso]

Replying to SirLouen:

@ann47he1rpjggx6f3yso I think this issue was been already reported here #64354
AFAIK, there is a problem with block styles being loaded on demand in classic themes hence this error appears but it was closed, so I'm not 100% confident.

Can you test this plugin to see if this fixes it for you?
​https://wordpress.org/plugins/load-combined-core-block-assets/

Want to double check with @westonruter

PS: Setting close as potential dupe of #64354

I'm not sure how my bug report is a dupe of 64354 as that is related to button color. There's no way I would have ever found that and determined that it was the same issue as I was having.

Anyway, I installed the Load Combined Core Block Assets plugin and that fixed my issue. Thank you for the plugin recommendation.

[westonruter]

@ann47he1rpjggx6f3yso can you share the URL to your site where the issue can be observed? (Since you activated that hotfix plugin, there is a query var which can be added to the URL to see how it behaves without the workaround. I want to validate what the specific issue is in your case. Hopefully this would mean you can deactivate the hotfix plugin in 7.0.

[ann47he1rpjggx6f3yso]

Replying to westonruter:

@ann47he1rpjggx6f3yso can you share the URL to your site where the issue can be observed? (Since you activated that hotfix plugin, there is a query var which can be added to the URL to see how it behaves without the workaround. I want to validate what the specific issue is in your case. Hopefully this would mean you can deactivate the hotfix plugin in 7.0.

​https://www.sharedbits.net

[westonruter]

@ann47he1rpjggx6f3yso Thank you. I'm trying to find something broken on the version with separate block styles loading on demand, but I'm not seeing it.

Compare these two URLs:

Loading combined block styles: ​https://www.sharedbits.net/
Loading separate block styles: ​https://www.sharedbits.net/?should_load_separate_core_block_assets=true

Both are looking the same to me. Is there a frontend URL that has broken styling? Or is the issue exclusive to the block editor?

[ann47he1rpjggx6f3yso]

My personal opinion is that the issue has something to do with WordPress core. I'm not experiencing any issues with the block editor.

Would it be helpful if I disabled the Load Combined Core Block Assets plugin?

[westonruter]

@ann47he1rpjggx6f3yso What I'm asking is if you can observe any issue on the frontend of your site. Please share the URL for where you can see an issue when the ?should_load_separate_core_block_assets=true parameter is added to the URL. This has the effect of disabling the functionality in the Load Combined Core Block Assets, so you can easily compare a page with and without that running.

All of the screenshots in the ticket description appear to be from the post editor, so that's why I asked about that.

Please share the URL for where the issue was being observed.

[ann47he1rpjggx6f3yso]

Yes, I can observe the issue I reported when I use the parameter you provided; images inserted in a post align left instead of center. When I remove the parameter and refresh the browser, the images align center like they should.

Most of the screenshots I provided were for the procedure I use to insert images into my posts. I tried to explain the procedure in the WordPress Fixing WordPress forum, but people responding to my post had trouble understanding what I was talking about so I took screenshots.

However, in those screenshots I show that I set image alignment to center, but then when previewed in a separate browser tab, the images aligned left. The images also appeared aligned left just viewing a post normally (not using preview from the post editor) in a browser.

Not sure if it matters, but just in case, I use Linux on my computer.

[westonruter]

@ann47he1rpjggx6f3yso What URL? Your homepage?

I see no difference between these URLs:

• ​https://www.sharedbits.net/
• ​https://www.sharedbits.net/?should_load_separate_core_block_assets=true

I'm testing with Chrome 145 on MacOS.

[westonruter]

Re-posting my comment from #64389:

I've just finished another pass at improving the preservation of classic theme CSS cascade when loading block styles on demand.

The PR description has been fleshed out with all the details, but in short:

1. Determining where to insert the styles hoisted from the footer has been made more robust by inserting placeholder inline styles. This simplifies the insertion logic since it doesn't have to hunt around for references for where styles should be inserted. It merely needs to replace the placeholders with the captured styles.
2. The CSS cascade is now improved for inline styles which had been added to wp-block-library. Now when loading separate block styles, any such inline styles get added after any of the separate core block styles.

Note: Do not have Gutenberg active when testing this, as the patch has not yet been applied to Gutenberg's forked version of wp_enqueue_global_styles().

Review and testing much appreciated: ​https://github.com/WordPress/wordpress-develop/pull/10875

I really hope to get this into the next beta.

[ann47he1rpjggx6f3yso]

Replying to westonruter:

@ann47he1rpjggx6f3yso What URL? Your homepage?

I see no difference between these URLs:

• ​https://www.sharedbits.net/
• ​https://www.sharedbits.net/?should_load_separate_core_block_assets=true

I'm testing with Chrome 145 on MacOS.

Here's what I'm seeing using Vivaldi (Chromium-based) under Linux...first screenshot normal link, second screenshot using the link parameter:

​https://imgbox.com/TIiZgme5

​https://imgbox.com/00Mzjm0q

Here's what I'm seeing using Firefox under Linux...first screenshot normal link, second screenshot using the link parameter:

​https://imgbox.com/UJmSnvd2

​https://imgbox.com/6BBVSPxD

The above is from my live site. I saw the same issue on my sandbox site. My hosting provider is Opalstack; ​https://opalstack.com/.

[westonruter]

@ann47he1rpjggx6f3yso ok, the URL you shared in the screenshot is what I was looking for:

• ​https://www.sharedbits.net/short-bits-2026/
• ​https://www.sharedbits.net/short-bits-2026/?should_load_separate_core_block_assets=true

I'll look at why they aren't rendering the same.

[westonruter]

@ann47he1rpjggx6f3yso Can you turn off FlyingPress? It seems to be involved somehow. I'd like to rule out whether it is causing the problem.

[ann47he1rpjggx6f3yso]

My first impulse was to reply and state that FlyingPress isn't the issue. I don't have FlyingPress on my sandbox site and the issue exists there as well.

However, I went ahead and deactivated FlyingPress on my live site and the issue still exists when I use the link parameter.

I'm about at the end of the amount of time I can spend on the computer today due to a spine condition. I probably will not be back on my computer until late tomorrow or early Friday.

[westonruter]

Thank you. OK, in ​the version which is working as expected, there are these two additional style rules present:

.wp-block-image .aligncenter, .wp-block-image .alignleft, .wp-block-image .alignright, .wp-block-image.aligncenter, .wp-block-image.alignleft, .wp-block-image.alignright {
    display: table;
}

.wp-block-image.aligncenter {
    text-align: center;
}

These are being loaded from ​https://www.sharedbits.net/wp-includes/css/dist/block-library/style.min.css?ver=6.9.1

These styles are missing from ​the other version, where separate block styles are being loaded on demand as opposed to the single combined block library always being enqueued.

The above styles should normally be added by enqueueing the Image block's stylesheet: ​https://www.sharedbits.net/wp-includes/blocks/image/style.min.css

However, this stylesheet is not getting enqueued for you.

So the issue doesn't seem related to #64389 because the issue isn't with a different CSS cascade. The issue is some styles are missing entirely. How is the content for that post being rendered in the template? Is it using a regular the_content()? If WordPress isn't doing do_blocks() on the content, then it isn't able to discover which block styles it needs to enqueue.

I suggest also reading the ​relevant section from the 6.9 performance field guide to see if it applies to your situation.