Skin talk:Chameleon

Jump to: navigation, search

About this board

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

"Menu"-component ignores "modification"

3 (talkcontribs)


apparently the modification is ignored when used with Menu-components:

This code should hide the menu for users that have no edit-rights:

<component type="Menu" message="riskmanagermenue">

<modification type="ShowOnlyFor" permission="edit" namespace="" />


Unfortunately this modification is ignored; I tried it with "HideFor", but without success.

Is this a known bug?

Thank you for this great skin!!!


F.trott (talkcontribs)

Modifications for the moment only work on top-level components. The problem is that the modifications have to be applied by the parent of the component they are acting on. This is implemented for Structure and Cell, but not yet for others, like NavbarHorizontal.

It would be great if you could add an issue at

Stephan (talkcontribs)


Reply to ""Menu"-component ignores "modification""

mw-headline and non-clickable links

Summary by Cavila

Fixes have been merged

Cavila (talkcontribs)

Hi Stephan, I sometimes found that headings with the mw-headline class caused links above it to become non-clickable. It may have been due to an attempt to prevent anchor links from being buried beneath the upper navigation menu, creating a margin of 50px between the top of the page and the anchor link (it's quite possible that the issue occurs only when the font you're using for subheadings has a generous margin of its own). Anyway, whatever the exact cause of the problem, there's an easy CSS fix for that I think, which is to substitute "block" for "inline-block" - unless it creates other issues I'm not aware of.

.layout-fixedhead h1 >, .layout-stickyhead h1 >, .layout-clean h1 >,

.layout-fixedhead h2 >, .layout-stickyhead h2 >, .layout-clean h2 >,

.layout-fixedhead h3 >, .layout-stickyhead h3 >, .layout-clean h3 >,

.layout-fixedhead h4 >, .layout-stickyhead h4 >, .layout-clean h4 >,

.layout-fixedhead h5 >, .layout-stickyhead h5 >, .layout-clean h5 >,

.layout-fixedhead h6 >, .layout-stickyhead h6 >, .layout-clean h6 > {

    content: "";

    display: inline-block;

    height: 50px;

    margin-top: -50px;


F.trott (talkcontribs)

Would be great if you could submit a pull request on Github.

Cavila (talkcontribs)

Will do when I find the time, probably later this week.

Cavila (talkcontribs)

After upgrading to MW 1.28 and Chameleon 1.5, I found that the layouts for sticky and fixed headers are behaving differently. The headers stay fixed for a while, but disappear when scrolling further down the page. Can I adjust this to get the former behaviour?

F.trott (talkcontribs)

Do you have a link?

Cavila (talkcontribs)

I'm afraid I don't have anything to show you, but I can see that there's an event that changes "position:fixed" to "position:absolute" on page scroll. It could be something specific on my side so I will have a closer look first.

Cavila (talkcontribs)

Solved! It was probably a specific css change that caused this, but I'm unable to pinpoint it. Whatever it was, the problem did not recur since I thoroughly revised my css/less files.

ClemFlip (talkcontribs)

Hi Friends,

Is it possible to put the TOC (table of content) in a <div> that stays fix while scrolling?

Like what you can see in this page:

Do you know how can I do that using Chameleon?


F.trott (talkcontribs)

There is no component that could do this for all pages right now. If you only need it for a few pages, here is a workaround that kinda works (with some caveats):

First you'll need some Javascript. Add the following to your LocalSettings.php:

$wgHooks['ParserAfterParse']['addModules']=function( Parser &$parser, &$text, StripState &$stripState ){
	$parser->getOutput()->addModuleScripts( 'skin.chameleon.jquery-sticky' );
	return true;

Then all pages that should have a sticky TOC should have the following structure:

<div class="row">
<div class="sticky col-lg-3 pull-right">__TOC__</div>
<div class="col-lg-9">

I did not test what happens when you use this on mobile devices. And it does not play nice with stickyhead and fixedhead layouts.

F.trott (talkcontribs)

I added this as an enhancement request:

However, I am currently very slowly updating Chameleon to Bootstrap 4, so better do not hold your breath. It may take some time to add any new components.

ClemFlip (talkcontribs)

Thanks a lot. It works for me! :)

Do you know if it's possible to add the class="active" to the TOC item while scrolling.

The idea is to add style to the menu item that is activated while scrolling. In the same way that the bootstrap website:


F.trott (talkcontribs)

Depends on how much coding you are prepared to do. It should not be too hard to create some JS script to do this. A widget might do the trick, but I don't have any experience with widgets at all, so can't help you there. If I had to do it, I would probably just implement it as a mini extension using the ResourceLoader to load the script.

Of course, you could ideally also add this to Chameleon directly and provide a pull request on Github.

Reply to "TOC in a fix div"

Turn pencil into "Edit with form" [Resolved]

Stefahn (talkcontribs)

Hi Stephan,

on my wikis I use SMW and SemanticForms extensively. Thus I use $sfgRenameEditTabs = true; (see here) and "Edit with form" becomes "Edit".

However this doesn't seem to work in Chameleon. The "Edit with form" link is still in the "..."-menu (titled as "Edit" because of $sfgRenameEditTabs = true;).

How can I make the pencil icon the "Edit with form" link and move the "Edit source" link to the "..."-menu?

F.trott (talkcontribs)

In principle it should work. There's a special case in the code for SF, but there may have been changes in recent versions of SF.

Stefahn (talkcontribs)

I checked your commits and found out that your fix was after the release of 1.3. I was still at 1.3. Now I cloned the master and the issue is resolved :)

BTW: If you release a new official version (1.4) I could update the theme by going into "/mediawiki/skins/chameleon/" and run composer update.
If I want to run the latest master version I need to use git clone (or git fetch).
Is that right? (talkcontribs)

The issue has resurfaced due to changes in Page Forms (previously SemanticForms). See for a discussion.

F.trott (talkcontribs)

From the issue on Github: As a workaround use both $wgPageFormsRenameEditTabs=true and $sfgRenameEditTabs=true to make this work.

Reply to "Turn pencil into "Edit with form" [Resolved]"

Which files to copy from a local install

Cavila (talkcontribs)

There are some of us (without shell access) who first need to install Chameleon locally and then transfer the required files to the server. I was just wondering if you could make a list of files other than those in the skins folder, so mostly dependencies, that should be copied over.

F.trott (talkcontribs)

You could just go to an empty directory and do a composer require mediawiki/chameleon-skin. However, while that would build the complete file structure, you would still have to deal with the autoloader somehow. I think your best bet is to really work with a complete local clone of your MW installation.

Cavila (talkcontribs)

Thanks and wow, that's what I call a lightning reply! Option 2 sounds like the best way to go.

Reply to "Which files to copy from a local install"

deprecated ResourceLoader module "jquery.ui.position

Legaulph (talkcontribs)

I'm getting these errors on the QueryForm for MediaWiki 1.28.0 Semantic MediaWiki 2.4.4 and page forms 4.0.2

VM2638:70 This page is using the deprecated ResourceLoader module "jquery.ui.position".
(anonymous) @ VM2638:70
VM2638:81 This page is using the deprecated ResourceLoader module "jquery.ui.widget".
(anonymous) @ VM2638:81
VM2638:65 This page is using the deprecated ResourceLoader module "jquery.ui.core".
Please use "mediawiki.ui.button" or "oojs-ui" instead.
(anonymous) @ VM2638:65
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:176 Exception in module-execute in module ext.pageforms.main:
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:176 TypeError: initFunction is not a function TypeError: initFunction is not a function
    at HTMLDocument.eval (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:4), <anonymous>:151:553)
    at fire (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:45)
    at Object.add [as done] (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:45)
    at jQuery.fn.init.jQuery.fn.ready (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:49)
    at eval (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:4), <anonymous>:174:168)
    at mw.loader.implement.css (eval at <anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:4), <anonymous>:175:400)
    at Object.<anonymous> (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:161)
    at fire (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:45)
    at Object.add [as done] (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:45)
    at Object.always (load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=chameleon&version=1156l11:46)
F.trott (talkcontribs)

Are you sure this is Chameleon-related?

Legaulph (talkcontribs)

No I sent an email to SMW user group as well

Reply to "deprecated ResourceLoader module "jquery.ui.position"

Dropdown menus not working on Mediawiki 1.28

T0lk (talkcontribs)

I could use some help troubleshooting this. Here is my site. None of the drop downs work, for example when using fixedhead.xml clicking the icon for "Account" should show a menu, but does nothing. Everything was fine in 1.27.

F.trott (talkcontribs)

It's a known (and fixed) problem. Try using the dev-master version (or wait for a release).

T0lk (talkcontribs)

Thank you. Updating using composer require mediawiki/chameleon-skin "1.x-dev" fixed the problem. (talkcontribs)


I'm using MW 1.27.1 and Chameleon 1.4.

MediaWiki logo (neither the default logo nor my customized logo) doesn't link to any page. I want the logo link to main page. I've checked the source code of a wiki site and there's no href attribute in the in the a tagː (talkcontribs)

sorry sourcecode got cut of

here is the complete sourcecodeː

StasR (talkcontribs)

Release Notes Chameleon 1.4

Released on 20-Sep-2016


   Logo: add addLink attribute to Logo component (talkcontribs)


I've added attribute addLink = "yes" in logo component in the xml format file. Logo is now linking to main page.

F.trott (talkcontribs)

Oops, sorry. The default should have remained "yes" when the attribute was not present. I fixed it just now and will include it in Chameleon 1.5.

Lua Modules appear not to run in Mediawiki when using Chameleon skin

Albert Ke (talkcontribs)


I noticed that Lua programs running in the mediawiki are not working properly when using the Chameleon skin. For example the module “clickable buttons 2” that create buttons with text (see e.g.: won’t create any clickable buttons when using chameleon skin.

However, as soon as a different skin is chosen, the buttons work fine.

See copied above example at: (default skin is customized, and Lua works, buttons show. Here an image when displaying same page using Chameleon skin:

Any idea what a work around could be to get Lua modules to work with the Chameleon skin?

Versions: (

Chameleon 1.5

Mediawiki 1.27.0

PHP 5.6.28

Lua 5.1.5



F.trott (talkcontribs)

Thanks for the report! Could be as simple as some JS files not being loaded, but I need to investigate.

I opened an issue for this:

F.trott (talkcontribs)

In any case I noticed on your site that a SecurityError is raised which seems to come from the HeaderTabs extension. Could you try to disable that extension for a moment and see if it helps?

Albert Ke (talkcontribs)

Thanks for the prompt reply. I disabled the HeaderTabs extension. Reloaded the pages in different browser, logged in to get the skin to Chameleon 1.5, same thing, buttons disappear as soon as using the Chameleon skin. I'll put the HeaderTabs extension back on, but will install a newer version (if there is one) soon to see if that solves the security error.

Thanks, Albert.

F.trott (talkcontribs)

I think I know what's happening. At some point I removed the call to include MW legacy CSS. I think this call is now also used for mw.ui.button, the CSS module containing the button formatting rules. So I'll have to reintroduce that call and get rid of the legacy stuff in a different way.

Give me a few days, I'm not home right now.

Albert Ke (talkcontribs)

Totally fine, already happy that you opened an 'issue' and are on it. Thanks!, Albert.

Reply to "Lua Modules appear not to run in Mediawiki when using Chameleon skin"