CSS issue on flexi content items

  • Resolved James Monroe

    (@jhmonroe)


    4 months ago

    I have 12 flexi content items inside a flexi content block.

    Selecting all of them and Setting background color in the right sidebar for a flexi content item does not seem to override the default css you wrote for the block since that block css is output as inline styles.

    The little color picker shows that it has changed to black #000000 for all of them

    But when I load the page and view the CSS, you have written the background-color as #ededed and when I change the background color of the flexi content items as a group it will not override this.

    Then when I view the LAST flexi item in the page source/inspector, it has output the background css 12 times on this one item. even thought the background-color was not output for the previous 11.

    https://www.dropbox.com/scl/fi/722ovtim1iifqvdq61pev/Screenshot-2025-09-14-at-6.16.40-PM.png?rlkey=q4zyw08yk4nyh99le6nrj6h6f&dl=0

    The only way to edit the style for each flexi item is to do it one at a time (which is frustrating if a user has MANY flexi content items). This correctly applies the CSS to each block individually.

    Please alter the block editor code you use so multiple blocks can be edited at once to override your defaults. or please remove your defaults so the background is transparent

    Thanks!

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Noruzzaman

    (@noruzzaman)

    3 months, 3 weeks ago

    Hi @jhmonroe

    I did not get this issue from my side. Can you please update to v1.0.8 and check again? If same problem still there, maybe you can record a small video and show that will help me to understand better and I will resolved it.

    Thanks
    Noruzzaman

    Thread Starter James Monroe

    (@jhmonroe)

    3 months, 3 weeks ago

    Here you can see the CSS issue in action. The default color you use is #ededed. I select all items and change it to solid red. i view the page on frontend and there is not red on any of the flexi items except the last one. you can see in CSS at the end of video

    https://www.dropbox.com/scl/fi/rocptn8wdk2ya53ytmx9b/gslider-css-issue.mov?rlkey=nnhw6in9joqj1sv24lu8wnwjh&dl=0

    Plugin Author Noruzzaman

    (@noruzzaman)

    3 months, 2 weeks ago

    Hi @jhmonroe

    Thanks a lot for sharing the video that was really helpful in understanding the issue. The reason this happens with multi-select styling is due to the way my current CSS is being loaded. If I rendered all styles as inline CSS, the multi-select updates would apply instantly, but I have avoided that approach because it injects CSS directly into the DOM, which I personally feel is not a good long-term practice.

    With the current implementation, when you update styles on multiple items at once, the changes only apply to the last selected item on the frontend. However, if you reload the editor page and save again, the issue resolves correctly.

    Also, the default background color you mentioned (#ededed) is not actually causing this it does not affect the multi-select behavior. From my quick research, I noticed that many major Gutenberg plugins (like Spectra) simply disable style updates when multiple blocks are selected, probably because of similar conflicts.

    That said, I am actively looking into possible ways to improve this behavior in my blocks. For now, the best workaround is to reload and save after applying multi-select styles.

    And again thanks a lot for taking the time to record and share the video. It really helps me track down these edge cases faster.

    Best,
    Noruzzaman

    Thread Starter James Monroe

    (@jhmonroe)

    3 months, 2 weeks ago

    Hey!

    CAN CONFIRM that your workaround works. Save, reload editor page, save again. refresh frontend and the bulk edits to the flexi items finally show! So happy there is a simple solution.

    Thank you for such a thoughtful explanation and I’m glad this use case was helpful.

    This explanation totally makes sense — while I am only using Core WordPress (with the block editor and not the extra gutenberg plugin, just what’s in core), I have seen other odd buggy things related to the block editor and also with how many places css loads from (core, core blocks, parent theme, child theme, plugin css, database css of user overrides, etc!). I’ve been adding tickets in gutenberg github when I find odd bugs so hopefully they will slowly go away over time as the block editor improves and as the team starts to streamline how and when css is compiled.

    You can see it working beautifully here (2 blocks above footer): https://monroeand.co/

    🙂

    • This reply was modified 3 months, 2 weeks ago by James Monroe.
    Plugin Author Noruzzaman

    (@noruzzaman)

    3 months, 2 weeks ago

    Hi @jhmonroe

    Great to hear the workaround solved it and the site looks great on my side too. I will build more essential blocks for the plugin next. If you have any suggestions for new blocks, please let me know. Your feedback will help me make it even better. Thanks again.

    Best
    Noruzzaman

    • This reply was modified 3 months, 2 weeks ago by Noruzzaman.
    Thread Starter James Monroe

    (@jhmonroe)

    3 months, 2 weeks ago

    The plugin is REALLY good! As a container that can contain any other WordPress blocks, the most important thing is that it has the best controls to adjust its appearance, sizing, and responsiveness. If you really nail all the controls you’ll have the best gutenberg slider block there is

    Plugin Author Noruzzaman

    (@noruzzaman)

    3 months, 2 weeks ago

    Hi @jhmonroe
    Thank you so much for the kind words and encouragement. Really glad you are enjoying the plugin. I will keep working on improving the controls and responsiveness so it can be the best Gutenberg slider block possible.

    Best
    Noruzzaman

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.