没有不值得去解决的问题,也没有不值得去学习的技术!

Troubleshooting Mobile Image Misalignment in Old WordPress Posts: Classic Editor Caption Fixed Width and Cache Verification

图1:移动端访问旧文章时,图片没有正常居中缩放

作者:

在

While checking the blog’s mobile display recently, I stumbled upon an issue: in some older posts, images failed to center and scale properly when viewed on a phone, and even broke the content area.

This issue did not affect all pages, but was concentrated in some older posts from around 2014 and 2017. Since my blog has been running for years and has a large number of historical posts, I was initially worried: could there be many similar mobile layout issues lurking in the site?

This article documents a complete troubleshooting process: from sampling mobile screenshots and testing with online tools, to ultimately identifying the fixed-width issue with wp-caption in older Classic Editor posts, and fixing it with a CSS fallback.


1. Symptom: Older Post Images Fail to Adapt on Mobile

I first noticed the problem while browsing older posts on a phone, seeing that the images in the articles did not scale to fit within the screen width.

Some images appeared noticeably too large, stretching the content area wider, and they did not display according to the current theme’s responsive rules.

Figure 1: When viewing an older post on mobile, the image does not center or scale properly
Figure 1: When viewing an older post on mobile, the image does not center or scale properly

Since the issue appeared in posts from earlier years, I initially suspected it might be related to the HTML structure of those early posts. Particularly for posts from around 2014 and 2017, they were most likely written using the WordPress Classic Editor rather than the current block editor.


2. Determining the Scope: Not a Site-Wide Template Issue, But an Issue with a Few Older Posts

My blog currently uses the WordPress 2025 theme. This theme does not involve many core templates, so instead of troubleshooting the entire site right away, I compiled a set of representative URLs for sample testing.

The tested URLs covered the following page types:

  • Chinese homepage
  • English homepage
  • Chinese category archive page
  • English category archive page
  • Tag archive page
  • Search results page
  • About page
  • Date archive page
  • 404 page
  • New post from 2026
  • Older post from 2014
  • Older English post from 2017

The test URLs compiled this time are as follows:

Plaintext
https://www.shuijingwanwq.com/ Blog homepage (Chinese)
https://www.shuijingwanwq.com/en/ Blog homepage (English)
https://www.shuijingwanwq.com/category/programming-language/ All archives (category) (Chinese)
https://www.shuijingwanwq.com/en/category/programming-language-en/ All archives (category) (English)
https://www.shuijingwanwq.com/tag/sql/ All archives (tag) (Chinese)
https://www.shuijingwanwq.com/2026/05/22/12860/ Single post (2026) (Chinese)
https://www.shuijingwanwq.com/en/2026/06/08/16568/ Single post (2026) (English)
https://www.shuijingwanwq.com/?s=fcitx Search results (Chinese)
https://www.shuijingwanwq.com/about-me-contact/ Page (Chinese)
https://www.shuijingwanwq.com/2014/ All archives (date) (Chinese)
https://www.shuijingwanwq.com/2014/11/10/387/ Single post (2014) (Chinese)
https://www.shuijingwanwq.com/en/2017/12/20/15940/ Single post (2017) (English)
https://www.shuijingwanwq.com/2014/11/10/38555 Page: 404 (Chinese)
Figure 2: A compiled list of URLs for mobile layout testing
Figure 2: A compiled list of URLs for mobile layout testing

After testing, I found that the vast majority of pages displayed normally. Ultimately, only the following two older posts had obvious issues:

Plaintext
https://www.shuijingwanwq.com/2014/11/10/387/
https://www.shuijingwanwq.com/en/2017/12/20/15940/

This result was crucial.

It indicated that the problem was not a failure of the overall 2025 theme template, nor a responsive issue at the template level for the homepage, archive pages, search pages, or 404 pages. Instead, it was isolated to the body content of a few older posts.


3. Using Microlink Bulk Website Screenshot for Mobile Screenshot Testing

To quickly check the mobile performance of these pages, I used the Microlink Bulk Website Screenshot tool.

The core configuration used during testing was as follows:

Plaintext
Device: Mobile
Viewport: 393 × 852
Full page screenshot: Checked
Block ads and banners: Unchecked
Use cache: Unchecked

Here, Full page screenshot needed to be checked. Because I was troubleshooting images, ads, code blocks, and the content area throughout the entire article, capturing only the first screen would easily miss image misalignment issues within the text.

Figure 3: Microlink Bulk Website Screenshot mobile screenshot configuration
Figure 3: Microlink Bulk Website Screenshot mobile screenshot configuration

Initially, some post images were blank in the screenshots. I later confirmed this was because my blog has image lazy loading enabled. The screenshot tool does not necessarily scroll slowly to trigger image loading like a real user would, so the image placeholder areas might appear empty.

Upon retesting, the images appeared normally in the screenshots, ultimately confirming that the issue was concentrated in the two older posts mentioned above.

Figure 4: Comparison of mobile pages after downloading batch screenshots
Figure 4: Comparison of mobile pages after downloading batch screenshots

4. Inspecting Older Post HTML: Discovering Hardcoded Width in figure.wp-caption

Next, I started inspecting the image HTML in the problematic posts.

Taking the 2017 English post as an example, the HTML structure of the problematic image was as follows:

HTML
<figure id="attachment_2150" aria-describedby="caption-attachment-2150" style="width: 816px" class="wp-caption alignnone">
    <a href="https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4.png">
        <img decoding="async"
             class="size-full wp-image-2150 lazy entered loaded exited"
             src="https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4.png"
             data-src="https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4.png"
             alt="新建完毕,点击 Start 按钮,启动设备"
             width="816"
             height="639"
             data-srcset="https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4.png 816w, https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4-300x235.png 300w, https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4-768x601.png 768w"
             data-sizes="auto, (max-width: 816px) 100vw, 816px"
             data-ll-status="loaded"
             sizes="auto, (max-width: 816px) 100vw, 816px"
             srcset="https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4.png 816w, https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4-300x235.png 300w, https://www.shuijingwanwq.com/wp-content/uploads/2017/12/3-4-768x601.png 768w">
    </a>
    <figcaption id="caption-attachment-2150" class="wp-caption-text">Figure 3</figcaption>
</figure>

The key issue was here:

Plaintext
style="width: 816px"
class="wp-caption alignnone"

This means that while the image itself had srcset and sizes, theoretically giving it responsive capabilities, the outer figure.wp-caption had a fixed width hardcoded by the Classic Editor.

On desktop, this fixed width is usually not noticeable. On mobile, however, such as when the viewport width is only 393px, the outer container still maintains 816px, which breaks the page layout.

Figure 5: HTML showing the fixed width of figure.wp-caption in a 2017 older post

I then checked the 2014 Chinese older post and found a similar structure, just with a larger original image width:

HTML
<figure id="attachment_390" aria-describedby="caption-attachment-390" style="width: 975px" class="wp-caption alignnone">
    <a href="https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3.png">
        <img decoding="async"
             class="size-full wp-image-390 lazy entered loaded"
             src="https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3.png"
             data-src="https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3.png"
             alt="在新安装的UC中添加应用phpsso!"
             width="975"
             height="891"
             data-srcset="https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3.png 975w, https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3-300x274.png 300w"
             data-sizes="auto, (max-width: 975px) 100vw, 975px"
             data-ll-status="loaded"
             sizes="auto, (max-width: 975px) 100vw, 975px"
             srcset="https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3.png 975w, https://www.shuijingwanwq.com/wp-content/uploads/2014/11/3-300x274.png 300w">
    </a>
    <figcaption id="caption-attachment-390" class="wp-caption-text">在新安装的UC中添加应用phpsso!</figcaption>
</figure>

The issue here was the same:

Plaintext
style="width: 975px"
class="wp-caption alignnone"

After further comparison, I confirmed that there was no fundamental difference in the HTML structure between the 2014 and 2017 posts.

They both belonged to the figure.wp-caption structure generated by the Classic Editor, and both contained an inline fixed width:

Plaintext
style="width: 816px"
style="width: 975px"

Therefore, the core of this issue was not some special HTML specific to posts from a certain year, but rather the figure.wp-caption fixed width that is commonly found in older Classic Editor posts. The two problematic posts from 2014 and 2017 merely exposed the same type of legacy structure.

At this point, the problem was basically identified:

The image caption container figure.wp-caption in older Classic Editor posts retained a fixed width, preventing it from scaling properly to the screen width on mobile devices.


5. Why Not Just Delete the width and height Attributes?

Upon initially seeing the following inside the image tag:

Plaintext
width="975"
height="891"

It is easy to assume the problem lies with the img and width attributes on the height tag.

In reality, however, these two attributes are not necessarily a bad thing. Modern browsers can use them to calculate the image aspect ratio in advance, reducing layout shifts.

What actually caused the layout to stretch on mobile was the inline style in the outer container:

Plaintext
style="width: 975px"

Therefore, I chose not to batch delete the width and height attributes from older posts, nor did I directly batch modify the post HTML in the database.

For this kind of legacy issue, using a CSS fallback fix is safer.


6. First CSS Fix: Limiting Max-Width for Images and wp-caption

Initially, I added a version of the CSS:

CSS
/* ==========================================================================
   🖼️ 旧文章图片说明(Caption)移动端适配修复
   解决:经典编辑器旧文章中的 figure.wp-caption 被内联 style 固定宽度,
   导致移动端图片不缩放、正文被撑宽、图片说明区域不居中的问题。
   适用于 2014/2017 等早期文章在 2025 主题下的响应式兼容修复。
   ========================================================================== */

.entry-content img {
    max-width: 100%;
    height: auto;
}

.entry-content .wp-caption {
    max-width: 100% !important;
    margin-left: auto;
    margin-right: auto;
}

.entry-content .wp-caption img {
    max-width: 100%;
    height: auto;
}

After adding this CSS, the 2017 English post looked normal on an actual phone, but the 2014 Chinese post still displayed abnormally.

However, after further comparing the HTML, I found that there was actually no fundamental difference in structure between the 2014 and 2017 posts. They both belonged to the figure.wp-caption structure generated by the Classic Editor, and both contained an inline fixed width.

Therefore, the fact that the 2014 page was still abnormal at that time was not necessarily because its HTML structure was more special; it could also have been related to caching by W3 Total Cache, Cloudflare, or the online screenshot tool.

To make the fix more robust, I ultimately upgraded the CSS from only restricting max-width to also covering width and max-width.


7. Upgrading the CSS: Covering Both width and max-width

Ultimately, I upgraded the CSS to a more complete version:

CSS
/* ==========================================================================
   🖼️ 旧文章图片说明(Caption)移动端适配修复
   解决:经典编辑器旧文章中的 figure.wp-caption 被内联 style 固定宽度,
   例如 style="width: 816px" / style="width: 975px",
   导致移动端图片不缩放、正文被撑宽、图片说明区域不居中的问题。
   适用于 2014/2017 等早期文章在 2025 主题下的响应式兼容修复。
   ========================================================================== */

.entry-content img,
.wp-site-blocks img {
    max-width: 100%;
    height: auto;
}

.entry-content figure.wp-caption,
.entry-content .wp-caption {
    width: auto !important;
    max-width: 100% !important;
    margin-left: auto;
    margin-right: auto;
    box-sizing: border-box;
}

.entry-content figure.wp-caption a,
.entry-content .wp-caption a {
    display: block;
    max-width: 100%;
}

.entry-content figure.wp-caption img,
.entry-content .wp-caption img {
    display: block;
    max-width: 100%;
    height: auto;
}

The most critical part of this CSS version is:

Plaintext
width: auto !important;
max-width: 100% !important;

Because the older posts contain the inline style:

Plaintext
style="width: 975px"

It was necessary to use !important to explicitly override it.

Even if the first version of the CSS might have been sufficient in some cases, ultimately keeping width: auto !important was intended to explicitly override the inline style="width: xxxpx" written by the Classic Editor, avoiding inconsistent results across different cache states, browsers, and screenshot tools.


8. Cache Impact: Why the Visitor Side Might Still Show the Old Effect

After adding the CSS, I cleared the cache for the problematic pages using W3 Total Cache, but the downloaded online screenshots still looked problematic.

Later, after logging into WordPress on a desktop device, I opened the developer tools, switched to mobile mode, and visited the post. I found that the page was already normal.

Figure 6: Using browser developer tools to simulate mobile while logged in, the older post image displays normally
Figure 6: Using browser developer tools to simulate mobile while logged in, the older post image displays normally

This showed that the CSS fix itself had taken effect.

I subsequently opened other single posts from 2014 while logged in, and found that the images in those posts were also displaying normally.

This further indicated that the problem was not invalid CSS, but rather that the visitor-side pages might still be affected by caching.

My website uses W3 Total Cache and also uses Cloudflare. For this kind of non-urgent issue, I chose not to clear the W3 Total Cache for the entire site, nor did I perform a cache purge on Cloudflare.

The reasons being:

  1. The fix had already been verified as effective while logged in;
  2. The issue was a mobile display compatibility problem for older posts, not a site-wide access failure;
  3. Purging the cache site-wide could cause additional origin server load;
  4. The cache could be allowed to expire naturally.

The final handling strategy was:

Plaintext
Keep the CSS fix;
Do not clear W3 Total Cache site-wide;
Do not actively clear Cloudflare cache;
Wait for the visitor-side cache to expire naturally.


9. Conclusions from This Troubleshooting

Following this troubleshooting, several clear conclusions can be drawn.

First, the current 2025 theme templates overall do not have obvious mobile layout issues. The homepage, archive pages, tag pages, search pages, standard pages, 404 page, and new post pages are all basically normal.

Second, the issue is primarily concentrated in early Classic Editor posts, especially the older image structures containing captions.

Third, what actually breaks the mobile layout is not the image itself, but the inline fixed width in the outer figure.wp-caption.

The typical problematic structure is as follows:

HTML
<figure style="width: 975px" class="wp-caption alignnone">

Fourth, there is no fundamental difference in the HTML structure between the two problematic posts from 2014 and 2017; they expose the same type of Classic Editor legacy issue.

Fifth, prioritize using a CSS fallback fix rather than batch modifying the HTML of older posts in the database.

Sixth, when verifying, distinguish between the actual fix effect and cache impact. Pages viewed while logged in usually bypass the visitor-side page cache, making them better suited for determining whether the CSS has taken effect.


10. The Final Retained Fix Code

The code ultimately retained in the WordPress global “Additional CSS” is as follows:

CSS
/* ==========================================================================
   🖼️ 旧文章图片说明(Caption)移动端适配修复
   解决:经典编辑器旧文章中的 figure.wp-caption 被内联 style 固定宽度,
   例如 style="width: 816px" / style="width: 975px",
   导致移动端图片不缩放、正文被撑宽、图片说明区域不居中的问题。
   适用于 2014/2017 等早期文章在 2025 主题下的响应式兼容修复。
   ========================================================================== */

.entry-content img,
.wp-site-blocks img {
    max-width: 100%;
    height: auto;
}

.entry-content figure.wp-caption,
.entry-content .wp-caption {
    width: auto !important;
    max-width: 100% !important;
    margin-left: auto;
    margin-right: auto;
    box-sizing: border-box;
}

.entry-content figure.wp-caption a,
.entry-content .wp-caption a {
    display: block;
    max-width: 100%;
}

.entry-content figure.wp-caption img,
.entry-content .wp-caption img {
    display: block;
    max-width: 100%;
    height: auto;
}


11. Follow-up Observation Plan

Because a site-wide cache purge was not performed this time, it may take a while for visitors to fully see the fixed effect.

I will continue to observe the following pages moving forward:

Plaintext
https://www.shuijingwanwq.com/2014/11/10/387/
https://www.shuijingwanwq.com/en/2017/12/20/15940/

If visitor-side access returns to normal after the cache expires naturally, then this issue can be closed.

If individual older post image anomalies are still encountered later, I will continue checking for other fixed-width elements, such as:

Plaintext
table
pre / code
iframe
legacy div containers
ad iframes
hardcoded style="width: xxxpx"

But at least this troubleshooting has confirmed that the primary issue right now is the wp-caption fixed width in older Classic Editor posts.


Summary

Although this issue seemingly amounted to “older post images not centering and scaling on mobile,” the troubleshooting process was actually quite representative.

For WordPress blogs that have been running for many years, historical posts have typically gone through different themes, different editors, and different image insertion methods. The HTML structures in older posts may not be fully compatible with the current theme and mobile responsive layouts.

The issue ultimately identified this time was:

Plaintext
The figure.wp-caption in older Classic Editor posts had a fixed width written into it,
causing the mobile image caption container to break the content area.

The final solution was not to modify the older posts one by one, but to provide compatibility fallback through global CSS.

This approach carries low risk, offers broad coverage, and is more suitable for older blogs with a large number of historical posts.

系列导航

关于作者 · 持续学习与技术实践

我是一名拥有 15 年以上开发经验的技术从业者,自 2013 年起持续运营个人技术博客,记录工作与个人项目中遇到的真实问题,以及解决问题过程中的探索、实践和思考。

除了技术写作,我也在持续开发和维护自己的独立项目,探索新技术和新工具在实际场景中的应用。我始终相信,没有不值得去解决的问题,也没有不值得去学习的技术。

如果这篇文章对你有所帮助,欢迎浏览博客中的其他文章,也欢迎交流技术经验与想法。

关于我  ·  GitHub  ·  邮件联系