Adding the $skinr variable to the body class when using page rules breaks the admin menu css positioning. The absolute positioning on div.skinr-links-wrapper may be throwing off the absolute positioning of the div#admin-menu. The only fix I've found so far is pretty kludgy--
body.skinr-region.admin-menu {
top: -20px !important;
}
Skinr is fantastic, btw. An amazing step toward creating really end-user-friendly UIs. Thanks for all your time and hard work.
Comments
Comment #1
jacineHey kdmarks!
If you change the admin menu settings by checking both "adjust top margin" and "keep menu at top of page" the situation is better. Not perfect, but better.
I hope that helps.
Comment #2
nomonstersinme commentedAnother options is:
works for me...
Comment #3
hedac commentedI still can't get skinr and admin menu working together
Comment #4
nomonstersinme commentedHave you tried any of the above solutions? theres no reason one of them shouldn't work unless your theme is adjusting the top margin.
Comment #5
jacineChanging component and status.
Comment #6
jacineI'm closing this due to lack of response. There's no way to prevent this type of conflict from happening in all situations. Admin menu module knows this, and provides options to help get around it. If the above suggestions don't work for you, the issue is with your theme.
Comment #7
lolmaus commentedOkay, there's a confirmed incompatibility between Admin Menu and Skinr UI.
In short, both modules play with
postionofhtmlorbodytags, interfering with each other.The maintainers of either module have rejected to solve the issue, marking each with "works as designed". See Admin Menu, Skinr.
It stands to reason that you module maintainers should cooperate to resolve the issue.
For the discussion to carry on in a single place, i suggest you talk in the following thread: #1873516: Incompatibility between Admin Menu and Skinr UI modules.
Comment #8
nedjoWhile it's possible that a fix might require changes in both Skinr and Admin menu, it's more likely that what we need is a simple workaround in one of the two. Given the current install stats (Admin menu runs on nearly 1 in 4 Drupal 7 sites while Skinr runs on around 2%), a workaround makes most sense in Skinr (why force a quarter of all sites to run a workaround that affects a small minority of installs?).
Comments in this issue suggested some possible simple CSS fixes in Skinr. Testing those and producing a patch is the clearest way forward.
Comment #9
nedjoUpping the priority. Since this bug breaks 1 in 4 D7 sites, it's a major barrier to Skinr usage.
Comment #10
nedjoAdditional potential solutions were suggested in #1588158: admin menu showing at bottom. #1753486: Skinr indiscriminately adds contextual-links class to skinr theme_hook elements even when no skins are available may also be related.
Comment #11
nedjoThis issue isn't present in the Skinr fork Fusion accelerator. Todo: determine why and whether the fix applies here.
Comment #12
moonray commentedFusion accelerator doesn't allow skinr classes on the body tag, as far as I know. That's how they don't have the problem.
Comment #13
moonray commentedI'm not getting this issue on my sites any more. Can someone confirm this is solved?
Comment #14
marcelodornelas commentedHi guys, the quickest and cleaner way to fix this is to edit the views page and set HIDE CONTEXTUAL LINKS to YES.
Comment #15
moonray commentedNo further confirmation that this bug is still present. Closing.
For reference see #1753486: Skinr indiscriminately adds contextual-links class to skinr theme_hook elements even when no skins are available