Plugin name and description overlap with "Install Now" button in Japanese locale

[hiroshisato]

In the plugin installation screen, the plugin name and description overlap with the "Install Now" button when the site language is set to Japanese.
This issue does not occur when the site language is set to English.
The issue also occurs in WordPress Playground with no additional plugins installed.

Steps to reproduce

1.Log in to the WordPress admin dashboard.
2.Go to "Plugins" → "Add New".
3.Set the site language to Japanese.
4.View the plugin cards.

Expected behavior

The plugin name, description, and "Install Now" button should be properly spaced and not overlap, regardless of the selected site language.

Actual behavior

The plugin name and description visually collide with the "Install Now" button in the card layout when the site language is Japanese.

Possible cause

It appears that the button width increases in the Japanese locale, while the available width for the plugin title and description does not adjust accordingly. This issue may also occur in other languages with longer button labels.

Environment

WordPress version: 7.0-beta-1
PHP version: 8.5
Browser: Safari 26.3 and Brave 1.87.188 (Chromium 145.0.7632.76)
OS: macOS Tahoe 26.3
Tested in: WordPress Playground

[hiroshisato]

japanese screenshot

[audrasjb]

Same here on fr_FR. See screenshot below.

[huzaifaalmesbah]

I am facing the same issue in the Bengali language as well.

[joedolson]

This is not technically a new problem; it just occurs more easily now that the button is larger. However, long texts will cause the same button overlap in the current 6.9 release.

It's still probably a visual regression we should address; but it's really an inherent problem in the usage of absolute positioning to layout the plugin cards, which precedes this change. The card design allows a fixed width of space for those buttons.

The easiest change would probably be to use the compact button design for the plugin card buttons, which is the same solution used for theme cards.

Switches to the compact button design in plugin cards.

The compact buttons are still a little wider, but it's less of an issue. Will probably need further tweaks; the old buttons had 20px of horizontal padding, the new compact buttons have 24.

Trac ticket: https://core.trac.wordpress.org/ticket/64686

## Use of AI Tools

None

[huzaifaalmesbah]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11021

Environment

• WordPress: 7.0-beta1-61709-src
• PHP: 8.2.29
• Server: nginx/1.29.5
• Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.2.29)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Eleven 5.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. Installed a clean WordPress 7.0-beta1 or trunk.
2. Logged in to the WordPress admin dashboard.
3. Navigated to Settings → General.
4. Changed Site Language to Japanese (ja)/ Bengali (bn_BD).
5. Went to Plugins → Add New.
6. Observed plugin cards in grid view.
7. Before applying the patch:
   • The plugin title and description overlapped with the “Install Now” button.
   • The button width increased due to localization.
   • Layout spacing did not adjust accordingly.

8. Applied the patch from PR
9. Repeated steps 4–6 in Japanese and Bengali locales.
10. ✅ Patch is solving the problem

Expected result

• Plugin title, description, and “Install Now” button should not overlap.
• Proper spacing should be maintained regardless of language.
• Layout should remain stable in languages with longer button labels.

Screenshots/Screencast with results

Before Apply Patch	After Apply Patch ✅

[audrasjb]

Thanks @joedolson, while this doesn't really fix the original layout issue of this screen, I wasn't able to reproduce the issue with these compact buttons anymore, at least on fr_FR.

I'm inclined to go with this implementation for 7.0.

[shailu25]

Test Report

This Report Validates that the indicated patch address the issue.✅

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11021

Environment:

WordPress - 7.0-beta1-20260223.221003
OS - Windows
Browser - Chrome
Theme: Twenty Twenty
PHP - 7.4.33
Plugin - None

Actual Results:

• Issue Resolved with Patch ✅ Plugin name and description is not overlap with "Install Now"

Supplemental Artifacts

• Attached

[shailu25]

Before Patch

[shailu25]

After Patch

[joedolson]

In 61729:

Admin: Switch plugin card buttons to compact size.

Following the admin reskin, the larger buttons in plugin cards caused an existing potential for text overlap to happen more easily. Switching to compact size restores prior behavior.

Props hiroshisato, audrasjb, huzaifaalmesbah, shailu25, joedolson.
Fixes #64686.

[hiroshisato]

Elementor

[hiroshisato]

MonsterInsights

[hiroshisato]

It looks like this issue has reappeared in WordPress 7.0 RC3.

The plugin name and the “Install Now” button are overlapping again on the Add Plugins screen.

In the previous discussion, this issue was not limited to Japanese. Similar layout problems were also reported in other locales, so this regression may affect languages other than Japanese as well.

This is not a major functional bug, but it is a visible layout issue on a screen that many users interact with. A broken layout on the plugin installation screen can make WordPress appear less polished.

I think this should be fixed before the final release if possible.

I reopened this ticket because the issue appears to be the same regression. However, if it would be better to handle this as a separate issue, I’m happy to create a new ticket or rewrite the report accordingly.

[369work]

I'd like to suggest a structural fix that prevents the overlap from recurring regardless of locale or button label length.

The current layout breaks differently depending on screen width:

• Desktop (>1100px): .action-links is position: absolute; width: 120px. "Install Now" fits, but translated labels — "今すぐインストール" (JA), "Jetzt installieren" (DE), "Installer maintenant" (FR) — overflow into the description area.
• Tablet (782–1100px): Switches to position: static; margin-left: 148px, which avoids the overlap but crushes the plugin name into an extremely narrow column, causing it to wrap across many lines.
• Mobile (<480px): Same margin-left: 148px rule applies. The description area is also unnecessarily narrow.

In short, there is no viewport width where the current layout works correctly.

Proposed fix: CSS only — no PHP or HTML changes required

Instead of fighting the existing position: absolute on .action-links, we keep it and simply move the button coordinates to sit directly below the plugin icon. The description's unnecessary margin-right compensation is also removed.

Tested on desktop (Nest Hub Max 1280×800 where the overlap was confirmed) and mobile (375px).

(See attached screenshots: desktop before/after and mobile before/after.)

/* Desktop: move button below icon, remove description margin compensation */
@media (min-width: 1101px) {
    .plugin-card .action-links {
        position: absolute;
        top: 152px;
        left: 20px;
        right: auto;
        width: 128px;
    }
    .plugin-card .desc > p, .plugin-card .name {
        margin-right: 0;
    }
}

/* Tablet and mobile: widen description area */
@media (max-width: 1100px) and (min-width: 782px), (max-width: 480px) {
    .plugin-card .action-links {
        margin-left: 148px;
        width: calc(100% - 148px);
    }
    .plugin-card .desc > p {
        margin-left: 0;
    }
}

This approach:

• Permanently fixes the overlap for all locales on desktop
• Improves the description width on tablet and mobile
• Changes only wp-admin/css/list-table.css — no PHP or HTML modifications required

Happy to prepare a formal patch if this direction looks good.

[369work]

[Imgur](​https://imgur.com/RputFFi)
[Imgur](​https://imgur.com/AFawwEm)
[Imgur](​https://imgur.com/LDbJq54)
[Imgur](​https://imgur.com/eloOGOk)
[Imgur](​https://imgur.com/4yVXIor)

I'd also suggest raising the severity from normal to major, since the layout breaks at every viewport width — desktop, tablet, and mobile.

[huzaifaalmesbah]

Hi, this issue is still present. I checked on 7.0 RC3 at 1280 px and 1600 px resolutions, and I can see the issue.

[wildworks]

It appears that two issues are being discussed here.

The first issue is the spacing between the plugin header and the plugin description text. This problem should have been resolved in both [61729] and [62290].

The second issue is that the plugin title and the "Install Now" button overlap. This problem became prominent with the introduction of the new design system in WordPress 7.0, but it was likely a latent issue that existed before. Therefore, strictly speaking, there are no longer any new regressions occurring in 7.0.

The second issue is that there's no fundamental solution as long as ​the plugin action links are absolutely positioned. This is because even if we change the margins or width to avoid overlap, it may not be optimal for all locales.

It would be best to rebuild the entire plugin card using a flex layout, but I'm unsure if that would be acceptable for the 7.0 release.

[wildworks]

One short-term solution is to increase the right margin for specific languages.

@media (min-width: 1101px) {
        .plugin-card .name, .plugin-card .desc > p {
                margin-right: 128px;
        }

        .plugin-card .name:lang(ja), .plugin-card .desc > p:lang(ja) {
                margin-right: 138px;
        }
}

The approach using the lang pseudo-class is also used on the about page. See [58979]

Fixes layout on Plugins → Add New where long translated strings for the install/update action (e.g. Japanese, Bengali, German, French) could overlap the plugin title and description. Compact buttons alone did not fully resolve this for all locales and widths (​PR #11021, reopened in Trac).
## Approach

• Wide viewports (≥1101px): Position .plugin-card .action-links under the plugin icon (top / left / fixed width) so labels stay in the icon column instead of intruding on the text column; remove the large margin-right reserve on .name / .desc > p that fought absolute positioning.
• Tablet / small breakpoints (existing max-width: 1100px + (min-width: 782px) or max-width: 480px query): Give static .action-links full remaining width (calc(100% - 148px)) and reset .desc > p left margin so the description area can use space more sensibly.

CSS only: src/wp-admin/css/list-tables.css (no PHP/HTML).

[sabernhardt]

allows wide .button link text to wrap to another line, and aligns text to start instead of the right

[sabernhardt]

wrapping long link text to another line in French, at 1600 pixels wide with the admin menu collapsed

[sabernhardt]

It is very late to redo the layout for next week's release, and PR 11820 is not ready anyway.

One short-term solution is to increase the right margin for specific languages.

My "Update Now" link in French, with the icon, is more than 188 pixels wide. The translation lengths are highly variable, and they can change at any time.

The "Update Now" string with the 'plugin' context is only on the plugin install screen, so removing "now" from some long translations might be an option. However, "Install Now" is used on other screens, where it probably should not be abbreviated.

Allowing the .button link text to wrap to another line seems to be the safest temporary change. It still is not good, but it prevents overlapping. The worst part of this idea is probably when someone clicks the link and it changes height along with the text as it progresses from "Update Now" to "Updating..." to "Updated!" (or "Install Now", etc.).

I also considered adding a white background to these links. That probably is not safe enough, and the links still would overlap plugin names as they did in 6.9 (with an additional four pixels to their width).

.plugin-action-buttons li .button:not(.button-primary) {
	background: #fff;
}

Partially related: #48648

[audrasjb]

Hello, I think it's a bit too late for this to be fixed in 7.0, as we don't have a solid and long term solution for now.
What I suggest is to move this ticket to 7.0.1 and to post a heads up in the #polyglots Slack channel. For example, on our side, we could update the fr_FR translation strings to remove "Now" (which translates "Maintenant") from our translation strings and just keep "Update", "Install", etc., as the interface is not designed to accept any text length.

[wildworks]

Allowing the .button link text to wrap to another line seems to be the safest temporary change.

This feels very unnatural to me. The space between the wrapped text is too large because the current button is ​using a very large value for line-height to express its height, in addition to min-height. In other words, the current button is not designed to have its text wrap.

What I suggest is to move this ticket to 7.0.1 and to post a heads up in the #polyglots Slack channel.

I agree with this

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[desrosj]

Replying to joedolson:

This is not technically a new problem; it just occurs more easily now that the button is larger. However, long texts will cause the same button overlap in the current 6.9 release.

Since this is made worse in the 7.0 release, going to leave trunk as the version (trunk is renamed to the numbered version upon release, so it will point to 7.0 after tomorrow).

[wildworks]

I'd like to consider how we should proceed with this ticket. As a short-term solution, would it be to shorten the word length by not translating "Now" in the locale where the problem is occurring, rather than fixing the core code? If so, I suggest changing the milestone for this ticket to 7.1 and working on a long-term solution.

[joedolson]

It seems to me like the fundamental problem is the use of absolute positioning & floats; this is always a fragile method of arranging content, and making CSS changes to remove that may be the best idea.

I'd propose just adjusting the CSS for the card so that it uses more modern layout techniques.

The layout itself is easily reproduced; but I think it'll need to have HTML modified, which is not something I think we should do in a minor release. There are definitely existing extenders that are using the plugin-card component structure and CSS, so we'd probably need to take that into consideration, as well.

The polyglot decision might be possible, but probably just needs to be a per-translation decision to make.

[369work]

@joedolson

I agree that moving away from absolute positioning is the right direction.
In my earlier comment (comment:11), I proposed a CSS-only approach that repositions .action-links below the plugin icon rather than alongside the text — effectively removing the conflict between the button and the description area without touching PHP or HTML. It also widens the description column on tablet and mobile.

It's not a full flex layout rebuild, but it could serve as a practical stopgap until a more complete restructuring is planned.

[masteradhoc]

@369work Could you prepare your version of the PR on GitHub based on the approach outlined so we can review and test it more thoroughly?

Given where we are in the 7.0.1 cycle, I think we'll need to move this ticket to the 7.1 milestone. We're quite late in the 7.0.1 milestone, and any change to this area needs additional review, consensus, and testing across locales and screen sizes before it can be considered for inclusion.

If the proposed fix proves stable and suitable for backporting to a minor release, we can revisit that decision later.

[369work]

Thanks for the update, @masteradhoc.
I'll prepare a PR based on the approach from comment:11.
Before opening the PR, I'm going to re-verify the current behavior against the latest trunk (the CSS structure for .plugin-card has changed somewhat since I wrote that comment), and confirm the exact pixel values across breakpoints and a few locales.

Will follow up here once the PR is ready for review.

[369work]

701px width, Featured tab, overlap on first load

[369work]

702px width, same plugin set, worse overlap

[369work]

712px width, multiple cards overlapping

[369work]

1920×1080, 3-column layout, overlap reproduced

[369work]

320px width, button clipped by overflow:hidden

[369work]

Attempted fix (comment:11 approach) regressing into star rating

[369work]

I tested this on the current "Plugins → Add New" landing page (Featured tab) on trunk (7.1-alpha), with the site language set to Japanese. The overlap was visible immediately on first load, without resizing the window, on these three plugins:

rtCarousel – Flexible Carousel & Slider Block for Images, Videos, Testimonials & More (slug: rt-carousel)
Admin Optimizer – Performance, Security & Site Cleanup (slug: admin-optimizer)
BlockFlow – FSE Blocks, Site Builder & Starter Templates (slug: blockflow)

From there, I resized the browser across a range of widths to map out where the overlap does/doesn't occur.

Findings

1. The 481–781px range (where .action-links stays position: absolute with a fixed margin-right: 128px reservation on .name/.desc > p) is broken across almost the entire range, not at a single breakpoint. Two widths just 1px apart can flip between "fine" and "overlapping" depending on which plugin title happens to be displayed and how it wraps:

At slightly wider widths, multiple cards overlap simultaneously:

2. This isn't limited to narrow viewports. At ≥1600px, .plugin-card switches to a 3-column layout (calc((100% - 32px) / 3)), and at ≥2300px to 4 columns. Both reflows narrow each card enough to reproduce the same overlap, even at 1920×1080:

3. Separately, below 480px, .action-links switches to position: static, but the button label doesn't wrap, so instead of overlapping it gets silently clipped by .plugin-card's overflow: hidden:

4. I attempted a fix based on the approach from comment:11 (repositioning .action-links below .plugin-icon with a fixed top offset, removing the margin-right reservation). Note that the CSS in comment:11 was based on the .plugin-card structure as of May, which has since changed (different breakpoints, .plugin-icon width is now 128px not 148px, etc.) — so I rewrote the approach against current trunk rather than applying that diff literally. This does resolve the title/button overlap, but introduces a new regression: on cards with short title/description text (e.g. the default "Add Plugins" landing page), .plugin-card-top's height collapses below the fixed offset, and the absolutely-positioned button overflows into .plugin-card-bottom, overlapping the star rating:

This suggests the fragility isn't specific to any one fix attempt: the original margin-right: 128px reservation in Finding 1 wasn't enough to account for every possible button label, and a fixed top offset has the same problem in the other direction — it isn't enough to account for every possible card height. Any approach that reserves a fixed number of pixels, in either direction, runs into the same wall.

Where I'm stuck
The underlying issue seems to be that any fix relying on a fixed pixel reservation (margin, offset, or width) will always have some combination of content length + viewport width that breaks it, since the failure boundary depends on the actual rendered text, not just the breakpoint.
This feels consistent with what @wildworks noted in comment:13 — that a real fix likely requires moving away from absolute positioning toward a flex/grid-based card layout.

I don't think I have the experience to scope a full layout rebuild of .plugin-card confidently, especially given the concern raised in comment:23 about extenders depending on the existing markup/CSS structure.

I'd appreciate guidance from @wildworks and @joedolson on direction here — is a structural rebuild the right path (even if it's out of scope for 7.1 and needs its own ticket/discussion), or is there a narrower CSS-only approach the team would consider acceptable despite the edge cases above?

[joedolson]

In my opinion, a structural rebuild is the only real path to addressing this. @wildworks suggestion about modifying translations can work, but isn't something we can really control; that will be up to each locale to determine for themselves.

The reality is that these older layouts are *all* quite fragile, and there are many good reasons to rebuild them, to take advantage of the gains in modern CSS.

While there are certainly extenders who will be impacted, if we communicate this effectively that shouldn't be a significant problem. If necessary, we can leave the old CSS in place for an extra release to give more time, while adding a new set to handle the new layout.

It's not viable for 7.0.1, but could be introduced in 7.1, if it was finished soon enough.

[wildworks]

I agree that a fundamental rebuilding is the ideal approach, but it would be advisable to keep the following in mind.

• Avoid using absolute positioning. Depending on the locale, certain elements might conflict with others.
• Discard old CSS approaches and adopt current, modern CSS practices.
• Do not rely on text length, especially for button text, for layout, as these lengths can easily change across locales.

When working on this ticket, it is better to fork the ​wordpress-develop GitHub branch and submit a PR from your forked branch. This makes code changes easy to review and allows many contributors to test via the auto-generated Playground.

[369work]

Thank you both for the clear guidance.
@joedolson @wildworks I'd like to take a shot at the structural rebuild.
I'll start by mapping out the current .plugin-card CSS structure to make sure I fully understand what's there before making any changes, then work toward a flex-based layout following the principles outlined in comment:30.
I'll open a PR from my forked branch once I have something worth reviewing.

## Summary

This patch fixes the plugin-card button overlap reported in #64686 by
replacing the absolute-positioning-based layout of .plugin-card-top
with a flexbox + container query based one, following the direction
agreed in comment:29 (joedolson) and comment:30 (wildworks): no
position: absolute, no legacy fixed-offset CSS, and a layout that
doesn't depend on button label length.

Only src/wp-admin/css/list-tables.css is touched. No PHP/markup
changes are required.

## Root cause

The overlap wasn't a single bug — it was two independent, viewport-based
breakpoint systems drifting out of sync:

1. The outer grid (#the-list) decides how many .plugin-cards fit per row (1 column below 782px, 2 columns from 783px, 3 columns from 1600px, 4 columns from 2300px).
2. The inner layout of .plugin-card-top (icon / title / description / action buttons) previously decided its own layout using viewport width via @media, not the actual rendered width of the card.

Because a card's real width depends on both the viewport width and the
current column count, a @media rule keyed to viewport width can't
reliably predict how much space is actually available inside a card.
A card in 3-column mode at a wide viewport can be narrower than a card
in 2-column mode at a medium viewport, yet a viewport-based rule treats
them identically. This mismatch is what produced the reported overlaps
at 320px, 481–756px, and again at 1600px+.

## Why container queries instead of viewport media queries

container-type: inline-size is added to .plugin-card, and the
internal layout responds to the card's own rendered width via
@container, not the viewport. This removes the dependency on two
unrelated breakpoint systems entirely — the inner layout now always
has an accurate picture of its own available space, regardless of
column count or viewport size.

Browser support: container size queries are supported by all browsers
in Core's official ​browser support matrix
(last 2 versions of Chrome/Firefox/Safari/Edge/Opera/iOS), so no
fallback is required.

## Why 600px as the breakpoint

The action-buttons column only shares a row with the icon+title when
there's enough width for all three to coexist without cramping:

• Card padding: 32px (16px × 2)
• Icon: 128px (fixed)
• Icon–title gap: 20px
• Title (minimum comfortably readable width): ~150px
• Title–button gap: ~20px
• Action button column (accounting for longer translated labels): ~180–200px

Summing these gives roughly 550px as the point where things start to
fit at all, with no margin for longer translations or larger font
settings. 600px was chosen to give a small buffer above that minimum
so the side-by-side layout only activates when there's genuinely
enough room, consistent with the "don't depend on button text length"
principle from comment:29/30.

## Icon/title ordering

The icon remains inside the existing <a class="open-plugin-details-modal">
(no markup change). .plugin-card .name h3 a is made a flex container;
the title text becomes an anonymous flex item and .plugin-icon is
placed before it visually via order: -1, keeping the icon clickable
as part of the details link and preserving the existing DOM order.

## Testing

Verified visually across 320, 375, 540, 768, 820, 1024, 1200, 1440,
1574, and 1920px viewport widths on the "Add Plugins" (bundled/beta),
single-column, and multi-column (2/3-col) card grids. In all cases:

• Icon and title stay aligned regardless of title length
• Action buttons consistently sit below (narrow cards) or beside (wide cards) the icon+title block, with no cards falling into an inconsistent in-between state
• No overlapping elements at any tested width

Trac ticket: https://core.trac.wordpress.org/ticket/64686

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude (Anthropic)
Model(s): Claude
Used for: Root-cause analysis of the layout bug, CSS implementation (flexbox + container query refactor), and drafting this PR/Trac description. All changes were tested and verified across multiple viewport widths (320–1920px) by me before submission.

[369work]

Pull request: ​https://github.com/WordPress/wordpress-develop/pull/12376

Thanks for the discussion in comment:29 and comment:30 — here's a patch following that direction.

Summary

This patch fixes the plugin-card button overlap reported in this ticket by replacing the absolute-positioning-based layout of .plugin-card-top with a flexbox + container query based one: no position: absolute, no legacy fixed-offset CSS, and a layout that doesn't depend on button label length.

Only src/wp-admin/css/list-tables.css is touched. No PHP/markup changes are required.

Root cause

The overlap wasn't a single bug — it was two independent, viewport-based breakpoint systems drifting out of sync:

1. The outer grid (#the-list) decides how many .plugin-cards fit per row (1 column below 782px, 2 columns from 783px, 3 columns from 1600px, 4 columns from 2300px).
2. The inner layout of .plugin-card-top (icon / title / description / action buttons) previously decided its own layout using viewport width via @media, not the actual rendered width of the card.

Because a card's real width depends on both the viewport width and the current column count, a @media rule keyed to viewport width can't reliably predict how much space is actually available inside a card. A card in 3-column mode at a wide viewport can be narrower than a card in 2-column mode at a medium viewport, yet a viewport-based rule treats them identically. This mismatch is what produced the reported overlaps at 320px, 481–756px, and again at 1600px+.

Why container queries instead of viewport media queries

container-type: inline-size is added to .plugin-card, and the internal layout responds to the card's own rendered width via @container, not the viewport. This removes the dependency on two unrelated breakpoint systems entirely — the inner layout now always has an accurate picture of its own available space, regardless of column count or viewport size.

Browser support: container size queries are supported by all browsers in Core's official ​browser support matrix (last 2 versions of Chrome/Firefox/Safari/Edge/Opera/iOS), so no fallback is required.

Why 600px as the breakpoint

The action-buttons column only shares a row with the icon+title when there's enough width for all three to coexist without cramping:

• Card padding: 32px (16px × 2)
• Icon: 128px (fixed)
• Icon–title gap: 20px
• Title (minimum comfortably readable width): ~150px
• Title–button gap: ~20px
• Action button column (accounting for longer translated labels): ~180–200px

Summing these gives roughly 550px as the point where things start to fit at all, with no margin for longer translations or larger font settings. 600px was chosen to give a small buffer above that minimum so the side-by-side layout only activates when there's genuinely enough room, consistent with the "don't depend on button text length" principle from comment:29/30.

Icon/title ordering

The icon remains inside the existing <a class="open-plugin-details-modal"> (no markup change). .plugin-card .name h3 a is made a flex container; the title text becomes an anonymous flex item and .plugin-icon is placed before it visually via order: -1, keeping the icon clickable as part of the details link and preserving the existing DOM order.

Testing

Verified visually across 320, 375, 540, 768, 820, 1024, 1200, 1440, 1574, and 1920px viewport widths on the "Add Plugins" screen, single-column, and multi-column (2/3-col) card grids. In all cases:

• Icon and title stay aligned regardless of title length
• Action buttons consistently sit below (narrow cards) or beside (wide cards) the icon+title block, with no cards falling into an inconsistent in-between state
• No overlapping elements at any tested width

Use of AI Tools

AI assistance: Yes
Tool(s): Claude (Anthropic)
Model(s): Claude
Used for: Root-cause analysis of the layout bug, CSS implementation (flexbox + container query refactor), and drafting this PR/Trac description. All changes were tested and verified across multiple viewport widths (320–1920px) by me before submission.

This is certainly going in a better direction - I think using containers to handle the width is a good idea.

However, this style change introduces a significant visual difference that leaves a large amount of empty white space that I don't think is desirable. I think it's going to require some structural changes in order to be feasible.

As I see it, the region with the icon, title, and action buttons needs to be a grid/flex with an order of icon > heading/description > actions. It won't be trivial to achieve the current or similar layout while also ensuring that the h3 is the first item in the card and the icon is clickable, but that's what needs to happen. It might mean needing to remove the icon from the link and give it a scripted event to trigger the heading's link, but have the image itself have aria-hidden. The focus target would change shape, but the ability to trigger the link would be unchanged for keyboard users.

[369work]

Option A

[369work]

Option B

[369work]

Thanks for the direction on this — a few points of context first, then two layout options to choose from before I implement further (want to avoid redoing this twice).

Context on the previous patch

The patch in PR #12376 was deliberately scoped as a CSS-only, minimal fix — no markup changes, no JS. The goal at that stage was just to remove position: absolute and the fixed-offset overlap bug while keeping the existing DOM structure untouched.

Separating the icon from the <a> inside h3 was actually something I'd already been considering from the start, for the same reasons you raised (nesting the icon inside the link makes it hard to lay out independently, and ties the accessible name/click target together in a way that's awkward for layout). I held off on it in the first patch specifically to keep that patch minimal and CSS-only, as noted above.

Now that markup changes are acceptable

With your go-ahead to pull the icon out of the <a>, here are two layout directions I'd already sketched out. Screenshots attached (using the actual "Gutenberg" card data for a realistic comparison):

Option A — icon spans the height of the title + description, action buttons sit in a full-width row below. This keeps the same general "changes shape depending on available width" approach as today (icon/title/description share the top area, buttons drop to their own row).

Option B — a single fixed layout that doesn't change based on device or viewport width at all: icon, title, then author + install button on one line, details link below that, then the description. Same structure whether it's a phone or a wide desktop screen.

I'd like your input on which direction to pursue before I put together the full implementation (icon out of the link, aria-hidden, scripted click passthrough, grid/flex layout). Let me know if either fits better with what you had in mind, or if you'd lean toward a hybrid.

[369work]

@joedolson:
Just following up in case this got buried — no rush, but wanted to flag that 7.1 Beta 1 is coming up in about a week, so I'd like to move forward with an implementation soon.

Happy to go with whichever of the two options (or a hybrid) you'd lean toward; if there's no strong preference,
I'll proceed with Option B since it removes the width-dependent breakpoint logic entirely.
Let me know either way!

[wildworks]

@369work Thanks for working on this.

To ideally resolve this issue, I believe we need to discuss it more carefully from the perspectives of design and accessibility. There's no need to rush a solution for Beta 1. I think it would be best to take sufficient time to refine it for future releases.

[369work]

@wildworks:
Thanks for the feedback, and for taking the pressure off around Beta 1 — that's helpful to know.

Agreed that this deserves a more careful design/accessibility conversation rather than a rushed fix.

I'll hold off on the layout implementation for now and wait for that discussion to develop — happy to revisit it once the design direction is settled.

@joedolson @wildworks:
Thanks again to both of you for the thoughtful review.

[joedolson]

In my opinion, option A is the better path, as it makes for a more efficient usage of the space available. And yes, I agree with @wildworks; this isn't an enhancement, so it can continue to be worked on during beta.

From an accessibility standpoint, moving the action buttons under the description has no significant consequences; they're in the same DOM position they currently are, and the difference between locating to the right of the panel vs below the icon is insignificant.

[hiroshisato]

I accidentally edited the ticket description instead of posting a comment. Fixed now.

[hiroshisato]

I'm also on board with Option A.

The goal here is to make the layout responsive enough so that buttons and links don't overlap, even when the translated text gets long.

I’m not sure about the final implementation yet, but if we go with something like flex-wrap: wrap to let the action area wrap naturally, Option A feels like the right way to go.

For instance, if an "Install Now" label is too long in a specific locale, we could just have the "Learn More" link wrap to the second line instead of forcing them to stay on the same row. This lets the layout adapt naturally to the available width and text length.

I also think this approach is more future-proof—it’s less likely to break visually if we update labels or layouts later on, making it much easier to maintain.

[369work]

Thank you all for the guidance, @joedolson, @wildworks, and @hiroshisato!

I'll proceed with implementing Option A (icon spanning vertically alongside a full-width action row below the description). The groundwork (icon moved outside the <a> link, aria-hidden="true", JS click delegation to the heading link) is already in place from the previous commit, so I'll build the final grid/flex layout on top of that.

@hiroshisato, that's a great point about flex-wrap: wrap for the action row — allowing links to wrap to a second line naturally when translated labels run long feels much more robust than trying to fit everything on one row. I'll incorporate that into the implementation.

I'll test across the same range of viewports as before (320px–1920px), plus a few locales with longer button labels, before updating the PR.

Thanks again for taking the time to review this carefully rather than rushing it for Beta 1.

[hiroshisato]

@369work

You may already be aware of this, and I assume the behavior will be tested after implementation, but I would like to raise one potential concern.

The plugin installation button changes its label as the installation progresses:

English: “Install Now” → “Installing...” → “Installed!” → “Activate”
Japanese: “今すぐインストール” → “インストール中” → “インストールしました。” → “有効化”

The label changes in the same way in other languages as well.

Because the length of the label varies between states, using flex-wrap may cause the layout to shift or wrap differently during these transitions. If this results in noticeable visual jumping, we may need to consider a different approach.

[369work]

375

[369work]

820

[369work]

1920

[369work]

Update: Option A is implemented and tested.

Summary of the implementation:

• .plugin-card-top now uses CSS Grid (icon spanning the title + description height, action buttons in a full-width row below), applied unconditionally rather than gated behind a width threshold — the layout doesn't depend on having room for buttons beside the title, unlike the previous flex-based design.
• The description row uses 1fr so it grows to fill available space, anchoring the action row to a consistent height across cards in the same grid row, regardless of description length.
• .plugin-action-buttons uses flex-wrap: wrap so long, translated labels wrap naturally instead of overlapping.

Testing:

• Verified across 320px–4K (12 viewport widths), including the previously broken ranges (320px, 481–756px, 1600px+). No overlap or clipping in any of them.
• Verified the dynamic button label transition during install (Install Now → Installing... → Installed! → Activate) at narrow widths (320px) per @hiroshisato's concern — no layout jump observed.
• Verified button-row vertical alignment is consistent across cards in the same row regardless of description length.

Screenshots at 375px, 820px, and 1920px widths are attached below for reference.

Note: the PHPUnit CI check is currently failing on tests/readme.php, unrelated to this CSS-only change — I believe it's unrelated to this PR, but flagging it in case it needs attention.

Pushed to the PR (​https://github.com/WordPress/wordpress-develop/pull/12376). Would appreciate a review when you have a chance.

Alternate version of ​https://github.com/WordPress/wordpress-develop/pull/12376

Trac ticket: https://core.trac.wordpress.org/ticket/64686

## Use of AI Tools

See ​https://github.com/WordPress/wordpress-develop/pull/12672 with an additional commit to modify the DOM order.

Thanks for the review!

I've addressed both issues:

1. Focus order

Rather than just moving the author link (as suggested in #12672), I restructured the DOM more broadly: the icon now comes first, followed by a single info group (title, author, description), then the actions group. This achieves the same result — DOM order now matches visual order (icon → title → author link → action button → details link) — while also simplifying the grid from 4 areas down to 3. Verified with keyboard tab order.

2. Icon alignment on secondary action buttons in mobile viewports

Confirmed and fixed. This turned out to be a pre-existing issue, not introduced by this patch: .plugin-card .update-now:before (the static "Update Now" state) was missing the vertical-align: middle; top: -2px; adjustment that .updated-message:before and .updating-message:before already had. Since the "Updating..." and "Updated!" states carry the update-now class alongside their own state class, the shared rule masked the gap — but the plain "Update Now" state (before any update action is taken) never picked it up, so its icon sat slightly low relative to the label text.

Fixed by adding .update-now:before to the shared alignment rule and removing the now-redundant vertical-align: top from its own rule. Verified at 344px (Galaxy Z Fold 5) across all three states (Update Now / Updating... / Updated!) with English labels — icon and text now align consistently.

[joedolson]

@wildworks While I think this is progressing well, it feels like a large change to make this late in the cycle. How do you feel about this?

[wildworks]

While I think this is progressing well, it feels like a large change to make this late in the cycle. How do you feel about this?

I agree. Based on the screenshots, it looks promising, but making significant changes at this stage might carry some risks. Let's make sure to resolve this in the 7.2 release.

Just checking in on this one.

I pushed an update to the PR back in July addressing the review feedback, and it's been sitting since then. I know the milestone moved to 7.2, and I'm not in a hurry — I'd much rather this be worked out properly than rushed.

Is there anything we need to do at this point?
We will take care of it if necessary.