Skin talk:Chameleon

Jump to navigation Jump to search

About this board

14.63.88.169 (talkcontribs)

Hi,

I just apply bootswatch's less files.

like follow:

$egChameleonExternalStyleModules = array(

__DIR__ . 'amelia_flatly_variables.less' => $wgScriptPath,

__DIR__ . 'amelia_flatly_bootswatch.less' => $wgScriptPath,

);

afte apply this to LocalSettings.php, It's cause the "RuntimeException"

Install chamelon by using composer. I think all components are successfully installed.

What do I do? I can't found any information about this at Google.

Thx.

F.trott (talkcontribs)

I have no idea. Do you have any more information, e.g. a file and line number?

178.199.61.84 (talkcontribs)

Exactly the same thing for me, I don't know where this error is logged....

Does someone know which component generate this error (for checking logs) ?

debian9 apache2 mariadb php7 mediawiki 1.27 last stable, skin chameleon working fine, but when I try to load something beginning with $egChameleon --> "Exception encountered, of type "RuntimeException"" on all webpages loaded,

F.trott (talkcontribs)
2605:E000:1316:C0F1:4477:BEDB:7D58:22A2 (talkcontribs)

Works fine for me on MW=v1.29, Nginx=v1.13.9, PHP=v7.0.1, Ubuntu=v16.04

However, since this latest update from bootstrap via composer, fk'd up my glyphicons, so it MAY be related?

Chameleon=v1.6 & Bootstrap=v1.2.3

Reply to "bootswatch cause "RuntimeException""

How to make the footer stick to the bottom of the screen?

8
Kghbln (talkcontribs)

I spent many hours to achieve this with no conclusion:

Doing this assures that the footer is sticky at the bottom of the screen, even if there is more content on the page. You are able to scroll down and see all the content available as you proceed.

@media only screen and (min-device-width: 768px) {
    .smwofootergrid.container {
        position: sticky;
        bottom: 0;
    }
}

.smwofootergrid.container {
    width: 100%;
}

Good. Now the big issue. This solution has two big issues.

1) One mobile devices the footer takes up about two thirds of the screen from the bottom, i.e. there is only a small window to look through at the content.

2) Assume that I have only one line of text on a wiki page. So the footer comes right after that and I have about two thirds of the screen from the bottom which is unused. That's equally bad.

Alternatives I have tried.

html,
body {
    height: 100%;
    margin: 0;
    padding:0;
}

.smwomaingrid {
    min-height: 100%;
}

Alle the tips in forums suggest to add a min-height of 100% to the content area. This however leads to the issue that even if I have just a line the footer is positioned way below the actual end of screen and one needs to scroll to see the footer.

Doing the following is a compromise:

html,
body {
    height: 100%;
    margin: 0;
    padding:0;
}

.smwomaingrid {
    min-height: 65%;
}

The issue here is that I still have a couple of centimeters of white space until the end of the screen.

What I am looking at is having the footer sticky a the bottom just for desktops and have the footer align to the bottom of the screen even if only one line of text is there, both for desktop and mobile.

I am absolutely clueless.

Kghbln (talkcontribs)

Actually no. The footer should not be sticky at the bottom of the screen. If there is more content that one has to scroll. However the footer should be at the bottom of the screen even if only one line of text is on the page. This is how things would appear sane. Any help much appreciated.

F.trott (talkcontribs)
Kghbln (talkcontribs)

I wrapped both into a grid but the result is even worse. Having a div within a structure causes fatals.

Kghbln (talkcontribs)

This is painful. This post presents a solution, which is not working, but links to another one which is working better. The second one hover has glitches on mobile when one scrolls down the page completely.

Kghbln (talkcontribs)

I am quite happy now and this is the only issue I currently see. I think it is not a big issue since one hardly has only one or two lines of content on a page.

201.6.4.251 (talkcontribs)

I have the exactly same problem. Im using Chameleon + bootstrap3. What exact files i need to modify to use the sticky footer?

Thanks!

Kghbln (talkcontribs)

This is the commit made to the .less file used by Chameleon. ".smwofootergrid.container" is the class wrapping the footer. Change this to the class name you are using for your footer. This solution appears to be much easier than I originally expected.

Reply to "How to make the footer stick to the bottom of the screen?"
Ruud habets (talkcontribs)

I am in a managed hosted situation where I have no acces to a prompt (Linux or Windows). Is there another way to install the Chameleon skin? For example: can I install the skin on another host and transfer the files to my web-host?

ruud

F.trott (talkcontribs)

Yes, this is the recommended way in that case. But Composer is making changes to existing files, so you need to mirror the complete MW installation, not just Chameleon. (If you ask me, having a staging area instead of working on the production server directly is a good idea anyway, in case something goes wrong.)

Ruud habets (talkcontribs)

I used to have my own VPS to have complete control over my MW install. But I ended up doing more maintenance the system, rather than maintaining content. So I will probably settle for the available themes. thanks anyway.

Reply to "howto install without composer"
Kghbln (talkcontribs)

I am banging my head against the wall for many hours [sic!] now however I completely fail to somehow adapt the SearchBar.

Does anybody know how to make it fluid, i.e. have it with a width of 95% on all screens desktop and mobile screens. Usually something like the following CSS helps:

box-sizing: border-box;
display: block;
width: 100%;
max-width: 95%;

However in this case it is completely useless.

The xml for this is standard:

<row>
	<cell span="12">
		<component type="SearchBar" class="pull-right" buttons="search"/>
	</cell>
</row>


Moreover I get a bluish shadow when the search box is clicked on. Here I have not even been able to detect where the color comes from needless to say how to change it.

Any hint or help will be appreciated.

Kghbln (talkcontribs)

Sometimes it helps to rant. ;)

I have just come up with the following CSS which is ok for the time being:

.form-inline .input-group {
	width: 100%;
}
.p-search.pull-right {
	box-sizing: border-box;
	width: 100%;
	display: block;
}

Without setting the first class to 100% it will not work. I am loosing the pull right here, but in my case this is hopefully acceptable.

Still I think there must be a better solution.

F.trott (talkcontribs)

Well, fluid mode is an attribute of the grid, not of a single component. So to have just the search box fluid and nothing else you'd have to put it in a grid of its own.

Also, the 12-column cell containing the search box is itself contained in a 9-column cell, which obviously limits its width.

Kghbln (talkcontribs)

This does not work since a grid cannot be the child of a row. The solution I posted turns out to be borked too since the search box aligns left for whatever reason. What I am trying to achieve is to have the search box at 100% of the whole cell which is a child of row. I just do not get it how to do it. Currently the search box is only about 5cm wide on a desktop screen so I figured that it will be nice to have a wider one. The wider one however does not work on a narrow screen.

F.trott (talkcontribs)

I got the impression that you want it stretched over the whole page. To stretched it over one cell only, try this:

.p-search, .p-search .form-inline .input-group {
  width: 100%;
}
.p-search .form-inline .input-group .input-group-btn {
  width: 0;
}
Kghbln (talkcontribs)

No I indeed only wanted to stretch over one cell. Wow, this works cool! Admittedly I would never have come up with this. Great, a day of frustration comes to a good end!

Kghbln (talkcontribs)

To self answer the second question about the border color and border shadow of the box when one clicks into the search box. Finally found it:

.form-control:focus {
    border-color: #91c800;
    box-shadow: inset 0 1px 1px rgba(0,0,0,.075),0 0 8px rgba(145,200,0,0.6);
}

I used to be in a grump and now I am in a fluff. :)

F.trott (talkcontribs)
:D
Kghbln (talkcontribs)

One not on this one. It does not work for Chrome, just for Firefox.

Reply to "How to make the SearchBar fluid"

Weird scrolling behaviour in Chrome

6
Summary by Loman87

Solved by adding "overflow-anchor: none;" to Mediawiki:Common.css

Loman87 (talkcontribs)

Hi,

I just want to report a strange behaviour that occurs in Chrome: when the browser zoom is set at 125%, pages start to autoscroll up or down. You can check this issue here, adjusting the page zoom to 125%. This doesn't happen if the zoom is less or more, nor in Firefox, since this last one has default zoom at 120% and 130%.

Have anyone noticed a similar behaviour?

Thanks,

Lorenzo

87.233.232.236 (talkcontribs)

Yes, it's occurring for me with the following stack:

MediaWiki 1.28.3
PHP 7.0.22-0ubuntu0.16.04.1 (fpm-fcgi)
MySQL 5.7.20-0ubuntu0.16.04.1
Elasticsearch 2.3.3
Chameleon 1.5 (2040cf2) 21:57, 23 November 2016
F.trott (talkcontribs)

You are not the first on reporting something like this (https://github.com/cmln/chameleon/issues/51). I was not able to reproduce this before, but on your site I finally can see this myself. Yay. ;-)

I'll see if I can fix this. Going out on a limb here, but for the moment I suspect that this could be do to a rounding error in the JS functions for "sticky".

87.233.232.236 (talkcontribs)

Hi Stephan,

This only occurs in Chrome and seems to be part of a more broad browser issue (although it may still be related to Chameleon).

Someone here suggested adding "overflow-anchor: none;" to your css. After having added this to the body tag, it seems to be fixed in my wiki (which does not use the sticky menu by the way).

F.trott (talkcontribs)

Nice find, thanks!

Loman87 (talkcontribs)

Thanks for this! I couldn't find a solution. Adding "overflow-anchor: none;" to Mediawiki:Common.css. works fine for me :)

I guess I can mark as resolved this thread.

Bye!

Loman87 (talkcontribs)

Hi,

I would like to add more icons to the navbar since for default there are only the 'edit pencil' and the three dots. I would need the icons for other page tools, e.g. Discussion (but also for Nex page, Previous Page and Index page when I am in the Page Namespace, generated by the Extension:ProofreadPage). Is that possible? I can't understand if it is just a CSS matter or if I have to work on components instead.

Thanks,

Lorenzo

F.trott (talkcontribs)
Loman87 (talkcontribs)

Thanks! I'll try something and I'll let you know...

Loman87 (talkcontribs)

Hi,

I tried but I failed :( (I am not a developer)

Finally, I did just some editings to the existing layouts in order to have something suitable for my needs (with no icons). My new layout is a combination of stickyhead and standard: the result is not astonishing but satisfying. I can share the layout if someone likes it.

In any case, after the installation I had some issues with personal tools (icons disappeared and alert bubbles had bad formatting), with the style of some special pages and with the icons of wikieditor. Just CSS stuff that I was able to solve by myself, but with which I can help if anyone should need.

Bye!

Reply to "How to add icons in the navbar"

FYI this skin works nearly out of the box with VisualEditor

3
T0lk (talkcontribs)

Extension:VisualEditor says it will only work with a limited number of skins, however it can use Chameleon too. On my wiki the only thing that doesn't work is the progress bar when you edit or save a page that doesn't show up.

F.trott (talkcontribs)

Thanks for the info! I'll look into it.

Chameleon is indeed supposed to work with VE. The only problem is that VE is (still) under development with frequent changes to the user interface, so it is somewhat of a moving target when it comes to integrating it.

I opened a task here: https://phabricator.wikimedia.org/T144471

T0lk (talkcontribs)

Just want to update that the progress bar now appears and VisualEditor works as expected. Not sure what changed, but upgrades to Core 1.29.2 plus the latest VE extensions were installed recently.

Reply to "FYI this skin works nearly out of the box with VisualEditor"
Kitsguru (talkcontribs)

I install Chamelion and Extension:Bootstrap today and have it working the way I want - well for the most part.

When I logout the Navbar and footers completely disappear. I am relatively new to mediawiki but php, js and css savvy. I am at a complete loss as to what is happening.

The sidebar appears fine if I switch to vector when logged out. Any insights would be appreciated.

Product Version
MediaWiki 1.29.1
PHP 5.6.31 (apache2handler)
MariaDB 10.2.9-MariaDB
Semantic MediaWiki 2.5.5
F.trott (talkcontribs)

Do you by any chance use the layout "clean"?

Kitsguru (talkcontribs)

Yes I am using the clean layout - and I figured out the issue in that I have permissions set that you must be a logged in to edit.

I cloned the clean layout and changed the ShowOnlyFor to read. Now works as I expected.

I also filed and issue on github to set the default to read instead of edit. Not much point hiding all the navigation if not logged in. Unless you know how to get to the login page.

Reply to "Navbar disappears when not logged in"

"Menu"-component ignores "modification"

3
77.2.183.193 (talkcontribs)

Hello,

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="" />

</component>

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

Is this a known bug?

Thank you for this great skin!!!

Daniel

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 https://github.com/cmln/chameleon/issues

Stephan

89.244.190.48 (talkcontribs)
Reply to ""Menu"-component ignores "modification""

mw-headline and non-clickable links

3
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 > span.mw-headline::before, .layout-stickyhead h1 > span.mw-headline::before, .layout-clean h1 > span.mw-headline::before,

.layout-fixedhead h2 > span.mw-headline::before, .layout-stickyhead h2 > span.mw-headline::before, .layout-clean h2 > span.mw-headline::before,

.layout-fixedhead h3 > span.mw-headline::before, .layout-stickyhead h3 > span.mw-headline::before, .layout-clean h3 > span.mw-headline::before,

.layout-fixedhead h4 > span.mw-headline::before, .layout-stickyhead h4 > span.mw-headline::before, .layout-clean h4 > span.mw-headline::before,

.layout-fixedhead h5 > span.mw-headline::before, .layout-stickyhead h5 > span.mw-headline::before, .layout-clean h5 > span.mw-headline::before,

.layout-fixedhead h6 > span.mw-headline::before, .layout-stickyhead h6 > span.mw-headline::before, .layout-clean h6 > span.mw-headline::before {

    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.