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

jacine’s picture

Hey 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.

nomonstersinme’s picture

Another options is:

body.skinr-region {
  position: inherit;
}

works for me...

hedac’s picture

I still can't get skinr and admin menu working together

nomonstersinme’s picture

Have you tried any of the above solutions? theres no reason one of them shouldn't work unless your theme is adjusting the top margin.

jacine’s picture

Component: Code » Module conflict
Status: Active » Postponed (maintainer needs more info)

Changing component and status.

jacine’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)

I'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.

lolmaus’s picture

Version: 6.x-2.x-dev » 7.x-2.0-beta1
Status: Closed (works as designed) » Active

Okay, there's a confirmed incompatibility between Admin Menu and Skinr UI.

In short, both modules play with postion of html or body tags, 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.

nedjo’s picture

While 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.

nedjo’s picture

Priority: Normal » Major

Upping the priority. Since this bug breaks 1 in 4 D7 sites, it's a major barrier to Skinr usage.

nedjo’s picture

nedjo’s picture

This issue isn't present in the Skinr fork Fusion accelerator. Todo: determine why and whether the fix applies here.

moonray’s picture

Fusion accelerator doesn't allow skinr classes on the body tag, as far as I know. That's how they don't have the problem.

moonray’s picture

Version: 7.x-2.0-beta1 » 7.x-2.x-dev
Status: Active » Postponed (maintainer needs more info)

I'm not getting this issue on my sites any more. Can someone confirm this is solved?

marcelodornelas’s picture

Hi guys, the quickest and cleaner way to fix this is to edit the views page and set HIDE CONTEXTUAL LINKS to YES.

moonray’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Fixed

No 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

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.