In Progress

13.1.x server-side CSS regeneration corrupts saved post CSS: u002d escapes not decoded + legacy row layout rules silently dropped

6

Hi, we are a licensed agency customer and we manage 70+ WordPress sites running Greenshift. We hit a serious data-corruption bug in the 13.1.x server-side CSS engine. Reporting it in detail because it destroys live layouts and is very hard for site owners to trace.

What happens: on any editor save of a page built with older Greenshift blocks, the regenerated _gspb_post_css post meta is corrupted in two independent ways.

First issue: u002d escape sequences are not decoded. Gutenberg serializes double dashes inside block-comment JSON attributes as u002d escapes (backslash u002d, twice). The new CSS engine copies attribute values (e.g. navColor) into the generated CSS verbatim, without decoding them, producing literal color:var(u002du002dwp–preset–color–palette-color-8, …). That is invalid CSS, silently dropped by browsers, so colors, overlays and backgrounds fall back (e.g. slider nav arrows revert to the Swiper default blue). Verified on 13.1.5/13.1.6 and again on 13.1.8: a fresh slide block saved under 13.1.8 got the same u002du002d garbage in its generated rules.

Second issue: legacy-format row rules are dropped entirely. Rows using the older rowLayout format (gspb_row__col–N classes) lose their generated rules on regeneration: per-id display:flex and col–8/col–4 width rules simply disappear. On our page the stored CSS shrank from 59,128 to 37,736 characters after one save. Result: columns stacked vertically, full-width images, complete layout collapse.

Why it is worse than it looks: page caches mask the damage for days (regeneration happens at save time, visitors keep getting the cached CSS until expiry), so the layout randomly breaks long after the save that caused it and nobody connects the two. Rolling back the plugin files does NOT help: the corruption lives in the regenerated data, and any resave regenerates it broken again. The only recovery is restoring the pre-save _gspb_post_css from a database backup, which most site owners cannot do.

Environment: WP 6.9.x, PHP 8.3 (LiteSpeed), Blocksy theme, CSS management set to save in custom field. The changelog up to 13.1.9 does not mention a fix.

What we ask: decode u002d escapes when reading block attributes for server-side CSS generation; regenerate rules for legacy-format rows (or refuse to overwrite the stored CSS when blocks cannot be parsed, rather than writing a truncated version); a changelog note when fixed, so agencies know when it is safe to resave legacy pages.

Happy to provide the full before/after CSS dumps privately.

Francesco Canovi – Black Studio

Francesco Canovi

Francesco Canovi

OP

⏱

Replies

Responses

  1. GreenshiftWP Avatar
    GreenshiftWP
    Admin

    thank you for report, but plugin has no changes in styles and we don’t see any reports elated to this and can’t reproduce on sites. At first, send the link. Second, check if you use any plugins that change frontend, cache plugins at first. Deactivate them if you use

  2. GreenshiftWP Avatar
    GreenshiftWP
    Admin

    Just retested again. Not confirmed. Please share the link

  3. Francesco Canovi Avatar
    Francesco Canovi
    Member

    Thanks for the fast reply. The corruption is not a cache or frontend-plugin artifact: those cannot write into a post meta. _gspb_post_css is written only by Greenshift’s CSS generator, so whatever is stored there is your engine’s own output.

    First issue (u002d escapes). Here is the verbatim generated value from that meta after an editor save under 13.1.8: color:var(u002du002dwpu002du002dpresetu002du002dcoloru002du002dpalette-color-8,#ffffff). Those u002d are literal characters in the stored meta (80 of them on this page). Gutenberg serializes the double dashes of CSS custom-property names as u002d escapes inside the block-comment JSON; the generator copies the attribute value into the CSS without decoding it, so var(–wp–preset–color–palette-color-8) becomes that invalid string. Browsers drop it silently. The escape is in the database, before any caching layer, so no cache plugin can produce it.

    Second issue (legacy rows dropped). The working CSS, restored from a DB backup, contains per-id flex row containers and gap-aware column widths for legacy rowLayout blocks, e.g.: #gspb_row-id-gsbp-83e2f08{justify-content:space-between;display:flex;flex-wrap:wrap} together with .gspb_row__col–8{width:calc(66.66666666666667% – 25px)} and .gspb_row__col–4{width:calc(33.333333333333336% – 25px)}. After one editor save under 13.1.x these are not regenerated: the number of per-id display:flex row rules on the page dropped from 71 to 38, and the gap-aware calc() widths disappeared, so the columns lose their flex context and stack. Total stored CSS shrank from 59,128 to 37,736 characters after that single save.

    Both conditions are needed to reproduce, which is likely why a fresh test does not trigger it: the page must contain older blocks whose attributes reference preset color vars (the values that serialize with double dashes), and, for the second issue, a row in the legacy rowLayout format (gspb_row__col–N classes).

    I can’t leave you a live broken link: the affected page is production and we already restored the pre-save _gspb_post_css from a backup, so it is currently correct and resaving it would re-corrupt it. What I can share privately is the full before/after _gspb_post_css dumps plus the source block markup, so you can reproduce on your own legacy-format page. Where should I send them?

    1. GreenshiftWP Avatar
      GreenshiftWP
      Admin

      sorry, currently I can’t reproduce. No issues and no decodes. This bug was real in one of broken updates but it was fixed immediately and this was few months ago. Definitely not in actual versions.
      please create test page and give me link. You can also make staging environment on hosting and reproduce bug here, then send me link

  4. GreenshiftWP Avatar
    GreenshiftWP
    Admin

    In another support topic user had similar problem, but it’s not related to plugin itself, it’s related to sanitizer of Gutenberg. I guess, you use also some kind of plugin that modify content

    So, check this comment

    https://shop.greenshiftwp.com/support/duplicate-post-page-fix/#comment-929

  5. Francesco Canovi Avatar
    Francesco Canovi
    Member

    You’re right, and thank you for the sanitizer pointer. I verified on our side, and Greenshift is not at fault. The affected page’s stored post_content had all its block-comment escapes stripped: 164 occurrences of u002d, plus u0022, u003c and u003e, none of them preceded by a backslash. So the double dashes and the other escaped characters were already destroyed in the markup before your CSS generator ever reads it; the generator was faithfully reproducing an already-corrupted attribute.

    Root cause found: Yoast Duplicate Post 4.7, its Rewrite and Republish feature. In post-republisher.php the republish_post_elements() method passes the copy’s WP_Post object to wp_update_post() without wp_slash(), so the internal wp_unslash() strips the backslashes from the escapes. The initial duplication slashes correctly (post-duplicator.php), only the republish merge-back does not. We’ll report it to Yoast and repair our content on our end. Apologies for the wrong framing, and thanks for your patience. You can close this topic.

Post a Reply

About the Author

Francesco Canovi
Francesco Canovi
Forum Topics (3)
13.1.x server-side CSS regeneration corrupts saved post CSS: u002d escapes not decoded + legacy row layout rules silently dropped In Progress Missing license tab in settings Resolved Swiper block – empty locked slides added by template on each editor load Resolved