Skip to content

Fix two 1.3.0 regressions reported on the support forum - #356

Merged
puikinsh merged 1 commit into
masterfrom
hotfix/1.3.1-link-colour-and-handles
Sep 5, 2026
Merged

Fix two 1.3.0 regressions reported on the support forum#356
puikinsh merged 1 commit into
masterfrom
hotfix/1.3.1-link-colour-and-handles

Conversation

@puikinsh

@puikinsh puikinsh commented Sep 5, 2026

Copy link
Copy Markdown
Member

Two users reported problems after the 1.3.0 update. Both are mine.

1. Links taking the button colour

unwanted link color — customizer set to #006699, links rendering #5D47D7.

The theme-mod → theme.json bridge mapped link_color and button_color onto the same primary slug, so the second write silently overwrote the first. Reproduced exactly — with both mods set, the page emitted:

:root{--wp--preset--color--primary:#5d47d7;}

Buttons now get their own button / button-hover palette slots.

There's a subtler reason this matters. theme.json's link rule and the theme's own customizer CSS have equal specificity, so which wins depends on emission order — and a caching or optimisation plugin that reorders CSS can flip it. That's likely why it hit some sites and not a stock install. With the slugs separated, both rules resolve to the same colour, so the outcome no longer depends on winning that tie.

2. Child themes replacing Bootstrap / FlexSlider / Owl Carousel

Update breaks navigation.

1.3.0 renamed four generic handles so a plugin claiming bootstrap couldn't suppress the theme's stylesheet. That fixed a real fault — but silently broke the most common child-theme pattern there is:

wp_dequeue_style( 'bootstrap' );   // swap in my own build

After the rename that names a handle nobody registers. It does nothing, the parent's Bootstrap comes back, and it lands on top of whatever the child replaced it with. Nothing errors — the layout just changes under them on update.

Reproduced with a two-line child theme: bootstrap stylesheets on the page went 0 (1.2.21) → 1 (1.3.0).

Each old handle is now registered as an empty placeholder and enqueued; a late hook mirrors any dequeue of it onto the real stylesheet. The placeholder is only registered when nothing else has claimed the handle, so the theme isn't back to squatting on generic names.

Verified — all three cases that must hold at once

case result
child theme dequeues bootstrap 0 stylesheets (was 1 in 1.3.0)
default site, nothing dequeued 1 stylesheet, shapely-bootstrap
plugin claims bootstrap first both load; theme's not suppressed

13 pages crawled, 0 failures, 0 fatals, 0 theme lines in WP_DEBUG_LOG.

🤖 Generated with Claude Code

Link colour taking the button colour
------------------------------------
The theme-mod -> theme.json bridge mapped link_color and button_color both onto
the 'primary' preset slug, so on a site that set the two to different colours the
second write silently overwrote the first and links rendered in the button's
colour. Reported by chrisesch: customizer set to #006699, links displaying as
#5D47D7. Reproduced exactly -- with both mods set the page emitted

    :root{--wp--preset--color--primary:#5d47d7;}

Buttons now have their own 'button' / 'button-hover' palette slots.

Worth recording why this matters beyond the obvious. theme.json's link rule and
the theme's own customizer CSS have equal specificity, so which one wins depends
on emission order, and a caching or optimisation plugin that reorders CSS can
flip it -- which is why this hit some sites and not a stock install. With the
slugs separated both rules resolve to the same colour, so the result no longer
depends on winning that tie.

Child themes replacing Bootstrap / FlexSlider / Owl Carousel
------------------------------------------------------------
1.3.0 renamed four generic asset handles so a plugin claiming 'bootstrap' could
not suppress the theme's stylesheet. That fixed a real fault but silently broke
the most common child-theme pattern there is:

    wp_dequeue_style( 'bootstrap' );   // swap in my own build

After the rename that names a handle nobody registers, so it does nothing, the
parent's Bootstrap loads again, and it lands on top of whatever the child had
replaced it with. Nothing errors; the layout just changes under them on update.
Reproduced with a two-line child theme: bootstrap stylesheets on the page went
0 (1.2.21) -> 1 (1.3.0).

Each old handle is registered as an empty placeholder and enqueued; a late hook
mirrors any dequeue of it onto the real stylesheet. The placeholder is only
registered when nothing else has claimed the handle, so the theme is not back to
squatting on generic names.

Verified all three cases that have to hold at once:

    child theme dequeues 'bootstrap'   0 stylesheets  (was 1 in 1.3.0)
    default site, nothing dequeued     1 stylesheet, shapely-bootstrap
    plugin claims 'bootstrap' first    both load; theme's is not suppressed

13 pages crawled, 0 failures, 0 fatals, 0 theme lines in WP_DEBUG_LOG.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@puikinsh
puikinsh merged commit 4f2101b into master Sep 5, 2026
10 checks passed
@puikinsh
puikinsh deleted the hotfix/1.3.1-link-colour-and-handles branch September 5, 2026 14:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant