Support » Plugin: SiteOrigin CSS » Any YITH plugin breaks SiteOrigin CSS

  • Resolved diegora

    (@diegora)


    If you install any YITH plugin, it breaks the “Custom CSS” editor page.
    The plugin still works and you can edit things, sort of, but the editor looks broken, wrong colors, wrong position on screen, kinda hard to edit.
    Any fix?

Viewing 6 replies - 1 through 6 (of 6 total)
  • MORE INFO: it appears that YITH plugins include CodeMirror assets and, when the plugin is activated, SO Custom CSS starts using YITH’s CodeMirror CSS styles instead of SiteOrigin’s ones. Don’t know how to explain it better.
    Have tried at least 3 YITH plugins and all do the same to SiteOrigin Custom CSS’s editor.
    Help Pls.

    Plugin Support alexgso

    (@alexgso)

    Hi diegora,

    Thank you for the compatibility report – we really appreciate it. We’ve identified the cause of this issue and this issue will be fixed in the next SiteORigin CSS update. You can follow this issue on our GitHub here.

    In the meantime, you can manually resolve this issue by editing wp-content/plugins/so-css/css/admin.css and adding the following CSS at the end of the file:

    #siteorigin-custom-css .CodeMirror {
      clear: none;
    }

    Hi Alex, Thanks for the attention!
    BUT “clear:none” style doesn’t really fix it.
    Yes, it fixes the positioning of the edit box and the plugin is usable again, but SiteOrigin’s Custom CSS is STILL using YITH’s CodeMirror styles, the background is not ‘white’ anymore, it’s ‘#fafafa’… but the real annoying change is hard to explain: When you try to scroll down the code lines with the mouse wheel, it keeps forcing you back to the line where the cursor is, that didn’t happen before.
    Do you intend to really address the issue or the “clear:none” is going to be the fix in the next update?
    Thanks

    Plugin Author Andrew Misplon

    (@misplon)

    Hi @diegora

    The problem doesn’t lie with SiteOrigin CSS but we’ll do our best to resolve. YITH are loading CodeMirror assets incorrectly. They’re using standard handles but the version number is incorrect. They’re using their plugin version number instead of the CodeMirror version number. They also appear to have customized the CodeMirror CSS which is fine but not if standard handles are being used. For example, do you notice how there is no clear: both in the first rule here. Perhaps that was in an older version but then my version number complaint applies. In the case of customized assets, prefixed handles should be used. WordPress plugins and themes are developed in this way so that assets like jQuery or in this case, CodeMirror aren’t loaded twice or numerous times. This system only works if the correct version number is used and the assets aren’t customized. Hopefully, this helps explain what’s happening here. We’d be happy to log this issue with YITH and even submit a pull request but these plugins aren’t hosted on GitHub that we can see.

    Ok, thanks. I’ll let them know they done goofed.
    And can we please include “background-color:white” in your hot-fix! 🙂

    Plugin Author Andrew Misplon

    (@misplon)

    For sure, I’ll chat to Braam here at SiteOrigin tonight about how he wants to proceed. We’ll get a release out as soon as we’re able. I’ll keep you updated.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Any YITH plugin breaks SiteOrigin CSS’ is closed to new replies.