• Resolved edtiley

    (@edtiley)


    I’ve been working on a plugin that uses Eli Geske’s jQuery Star Rating code to give me the stars behavior and added some stuff of my own to add functionality in a WordPress MultiSite environment.

    Got the plugin working quite nicely, then turned my attention to styling the site. Wanting to be mobile friendly, I made a Twenty Twelve child theme, and got to editing the CSS. After a good bit of time invested, I realized the star ratings are not working!

    Activate another theme, and the stars work! I’ve gone back in time to developmental versions of the plugin to the simplest version I have (before the Multisite code was added) and yup, the code breaks under Twenty Twelve.

    I’m thinking it is a selector conflict with the CSS in Twenty Twelve, but I’ve spent HOURs trying to find it without success.

    I’ve created two test sites with the only difference between them being that one uses Twenty Eleven and the other Twenty Twelve. One works, the other doesn’t.

    http://www.thecoastline.net – Twenty Eleven
    http://www.saultwaters.com – Twenty Twelve

    (NOTE: Neither of these sites is MultiSite)

    The code can be viewed on a page on either site by clicking “Source Code” in the menu.

    This is driving me nuts! Does anyone have an idea of what the conflict might be?

    TIA

Viewing 10 replies - 1 through 10 (of 10 total)
  • Hi.

    You’re right, the conflict is being caused in the Twenty Twelve CSS file. More specifically, it’s due to a margin being applied to the <li> tags that contain the stars.

    The offending code in the Twenty Twelve style.css is:

    .entry-content li, .comment-content li, .mu_register li {
    margin: 0 0 0 36px;
    margin: 0 0 0 2.571428571rem;
    }

    This is overriding the CSS for the Star Ratings. To fix this add an !important after the margin declaration for the .eg-rtbtns ul, .eg-rtbtns li selectors, so that you are left with:

    .eg-rtbtns ul, .eg-rtbtns li{
    margin: 0 !important;
    padding: 0;
    }

    Hope that works!

    Thread Starter edtiley

    (@edtiley)

    OMG thank you!

    It would have taken me several days more to figure that out! Offending code is right.

    Thank you to the lady from Wales, from a descendent of coal miners from the (now overgrown and gone) Welsh village of Tiley.

    Â chroeso/You’re welcome! Glad it helped. 🙂

    Plugin stylesheet loads too early. Plugin should enqueue this egstar-rating.css at a later order, so it loads after theme stylesheet. With the same CSS specificity, the plugin one will win because it loads after.

    Thread Starter edtiley

    (@edtiley)

    add_action( 'wp_enqueue_scripts', array( $this, 'register_plugin_styles' ) );

    What hook would you suggest other than wp_enqueue_scripts?

    The codex warns against using wp_print_styles on front pages.
    The setup_theme hook has already come and gone, so I’m thinking that it is somehow a “feature” that the theme’s css file loads last.

    A single “! important” is hardly a big PITA.

    add_action()
    http://codex.wordpress.org/Function_Reference/add_action

    Try a later number, 10 is default, so try 20

    add_action( 'wp_enqueue_scripts', array( $this, 'register_plugin_styles' ), 20 );
    Thread Starter edtiley

    (@edtiley)

    Interesting. Sorry to channel Mr. Spock.

    I modified the plugin adding the 20, and if you look at the source on http://www.thecoastline.com you’ll see that the plugin’s CSS loads after the theme’s.

    Now the question is, philosophically as much as technically, which is better? Should the plugin break the theme? Or should the theme break the plugin?

    In the end, one should have priority over the other. But which is “best practice?”

    I’m going to unhook resolved just in case someone wants to chime in on that one. Matt?

    It depends on the purpose of that particular stylesheet.

    If you want additional stylesheet to work on the top of theme stylesheet, then loads it after. But the specificity is a separate issue. Same CSS selector, one declared later will win. But a more specific selector will win even if it’s loaded before.

    In this particular case, I think it’s not right to say Twentytwelve breaks your plugin just because it has this

    .entry-content li { margin: 200px ;}

    It’s equivalent to saying that theme should not define list property in entry content.

    So if that part is crucial to the functionality of the plugin. It should be taken care of so that it won’t break theme. Load it after or add more specificity to that list styling like this.

    .ipubstars .eg-rtbtns ul,
    .ipubstars .eg-rtbtns li { margin: 0; }

    Then it doesn’t matter if it’s loaded before or after theme stylesheet.

    Thread Starter edtiley

    (@edtiley)

    Again, interesting.

    not right so say Twenty Twelve breaks your plugin

    I’m an old newspaper guy. Never let facts get in the way of a good headline! At any rate it sparked an interesting thread, and I learned a couple of things.

    crucial to the functionality of the plugin

    If it weren’t crucial it shouldn’t be in the stylesheet

    add more specificity

    The logic of that is unassailable. It’s one of those concepts that just kind of makes you say, “Oh yeah, I should have thought of that!”

    Thread Starter edtiley

    (@edtiley)

    Thanks paulwpxp,

    Sample urls no longer valid.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Twenty Twelve Breaks My Plugin’ is closed to new replies.