This is the talk page for discussing improvements to the ShowHide/Archive 1 page.


French ?


I've installed this on fr.guildwars and you can see on this page that it's always in english. In fact, maybe you can't see it but i assure you that if it's already translated to french, then there is a problem somwhere. Maybe i could just set my strings by overriding the english ones like it's clearly explained but i dont think this would be wise. Thanks. — TulipVorlax 02:17, January 31, 2010 (UTC)

One more example. — TulipVorlax 02:28, January 31, 2010 (UTC)
If you'd look at ShowHide/code.js you'll see that we only have i18n for English. And the documentation page explains how to customize messages for different languages. If you have another language, then either customize the messages, or post the translations here so they can be added. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)

Sure :

English : Show / Hide

French : Montrer / Cacher

TulipVorlax 03:19, February 13, 2010 (UTC)

We also need show all and hide all. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)

Dutch, German and French

// Dutch
nl: {
show: "tonen",
hide: "verbergen",
showAll: "alles tonen",
hideAll: "alles verbergen"
// German
de: {
show: "anzeigen",
hide: "verbergen",
showAll: "alle anzeigen",
hideAll: "alle verbergen"
// French
fr: {
show: "montrer",
hide: "cacher",
showAll: "montrer tous",
hideAll: "cacher tous"
} Mark (talk) 12:13, June 27, 2010 (UTC)

Just to leave a trace --Cizagna (Discusión) • HelperCentral hispana 08:59, 16 November 2010 (UTC)

Polish version

Hope you can add this to the script:

Show Pokaż
Hide Ukryj
Show all Pokaż wszystko
Hide all Ukryj wszystko

Anoon6@fandom(talk | forum społeczności | Wikia Polska News) 17:46, January 17, 2011 (UTC)

Added. Cheers, Grunny (talk) 23:53, January 17, 2011 (UTC)

Japanese messages?

Hi, would you please add Japanese messages? They are:

Show 表示
Hide 非表示
Show All すべて表示
Hide All すべて非表示

Thanks. --Zeeksphere 11:48, June 9, 2011 (UTC)

Done. Cheers, Grunny (talk) 01:18, June 10, 2011 (UTC)
Confirmed, thank you. :) --Zeeksphere 09:34, June 10, 2011 (UTC). :) --Zeeksphere 09:34, June 10, 2011 (UTC)

I've got a problem

I've got a problem. This [hide] for Episodes should be on the right. Also adding style="background:#ACF", makes the [hide] disappear. — Balistic 19:02, September 5, 2009 (UTC)

That's due to the way you are marking up that template. JS and CSS can't do anything if you use bad markup. Instead of <center/> (which is a deprecated html tag) use text-align: center;. Also put the header on the same line as the div start/end tags, putting it on it's own like causes an extra <p/> tag to be created which similarly forces a break. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)

Should NavPic be enabled ... or discarded

Dantman, wrt ShowHide#Magnify_and_shrink_pictures_without_leaving_the_article I think the so-called magnify sprite ought to become the "collapseLink" whenever the NavPic class has been used. Currently that sprite is just a redundant link to the image's page in the File: namespace. This is the same href target as for the the image area itself.

What do you think?

  • Is that intuitive?
  • ... complex to implement?
  • ... simple enough to implement?

--najevi 08:50, November 10, 2009 (UTC)

That magnify glass only appears when using thumbs what you request could be a restriction for the people that dont use thumb. What i still dont understand is why Dantman is supporting the NavPic class since it got broken the moment the code got copy to en.wikipedia and then the CSS got "improve", the only wiki i have ever seen using this class has been the de.wikipedia where the original code comes --Cizagna (Talk) Central Dofus 23:00, 10 November 2009 (UTC)
Yes, I can see your point now. It would be messy to try and treat Thumb images differently within Show/Hide.
  • However, I wonder if the Show/Hide button function might shift to the image area itself. i.e when the reader clicks on the small image it expands the collapsed content. When they click on the large image it collapses the collapsible content. In other words since the image area istelf is the common feature let that assume the function of magnify/shrink in lieue of displaying show/hide buttons.
Again this would be enabled only when a div.NavPic element is specified and not when a div.NavFrame element is specified. I suppose that the Magnify sprite could one day be implemented by Wikia engineers and not coexist well with the div.NavPic. Who knows?
Otherwise the NavPic class label becomes superfluous baggage. --najevi 11:27, November 11, 2009 (UTC)

NavFrame link

--Cizagna (Talk) Central Dofus 09:00, 11 November 2009 (UTC)

I learned something by playing around with your question above! I'll call your multiple line text the "preamble text" rather than header text because I sincerely believe the header text should be outside of the div.NavFrame element. I'll refer to you note about the 'header' changing size the "collapsible content" in my explanation below.

The executive summary is that it is best to:

  1. place the header before the div.NavHead and preferably before the div.NavFrame
  2. avoid placing any preamble text in between the div.NavHead tags and
  3. instead place it either immediately before or immediately after the first div.NavHead tag

If you play around with your Common.css to float the entire div.NavHead either right or left then you will see that the background color is really only there to draw attention to the Show/Hide button. You will see your preamble text rendered inside a border (due to NavFrame styles) that is obviously associated with both the Show/Hide button as well as the collapsible content.

First we float the Show/Hide buttons right. Of course this would be done in Common.css/Monaco.css/Monobook.css according to your site preference but I'll do it inline for these six examples.

div.NavHead {
div.NavContent {

1. Preamble text placed outside the div.Navframe (My old habit)

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header

2. Preamble is immediately before the div.Navhead

3. Preamble is immediately after the div.Navhead

Now we float the buttons left instead. It looks ugly if we don't clear:both before the collapsible content is displayed.

div.NavHead {
div.NavContent {

4. Preamble text placed outside the div.Navframe (My old habit)

See this 5 lines header and the link at the bottominstead the top right or top left and you can't fix it via CSS because then you are left with some ugly brakets at the end of your header

5. Preamble is immediately before the div.Navhead

6. Preamble is immediately after the div.Navhead

There you have it! Of the six examples the only one that I really don't like at all is #6. I think I might prefer #3 but then I suspect that could ask 12 people and get at least 5 different responses! Sorry I could not be any more helpful than that!
--najevi 11:04, November 11, 2009 (UTC)

This alternatives are clever yet the issues are still there... and even more,
If i could tolerate this off-center effect then I would be using tables instead of divs and as said before it will keep changing making it noticeable depending on how long is each word on different languages.
Also doing this alternative way requires to go and create new way of coding for styles and HTML making it more complex to use and for me to go and apply them to every single div using navframe on the wikis I'm in charge (where im the only active sysop) is simply insane. So in my personal case, I prefer not to update my older version and if im force to i prefer not to use hide/show at all until the navframe bug is resolve. Hence why im asking for it to be corrected --Cizagna (Talk) Central Dofus 23:21, 11 November 2009 (UTC)

I am sorry! I had misunderstood your intent with the centered block of text in the earlier example. I did not think a header would ever be so many lines so assumed it was only preamble text. Since you are determined to make all text in the entire NavFrame container centered (I can only imagine you are presenting poetry or song lyrics or images in the NavContent container) then the best idea I can come up with is to also center align the ShowHide button.

You could place that above or below the Title as shown below. If the full width colored background is undesirable then you could set background:none inside NavHeader

Personally I would not use text-align-center across the entire NavFrame container for an article but I realize that you may have special requirements for your articles.

1 fix

2 fix alternative

3 fix alternative clean up

Going back to your original example with a new understanding of your goal, I think that the workaround is very simple.

4 original - fix with <br/>


5 original - fix with {{clr}}

or perhaps

6 original - fix with centered title in it's own div (button top-right)

and finally

7 original - fix with centered title in it's own div (button bottom-right)

Where there's a will there's a way! --najevi 03:47, November 13, 2009 (UTC)

As i said before for me its to much time consuming if i have to go and edit every single navframe that exists in the various wikis im the only active admin with no steady user/community who can really help me. Also as you may know im a helper in charge of the spanish community so the time i have available to attend my wikis is very short most of the time patrol so unless i devote a couple of months finding and updating navframes this is simply not achievable if i still need to edit every single navframe, hence why my request for fixing by simply wrapping the link and adjusting editing the CSS since i dont know jquery i would do my changes in a separate version. Also this situation applies also for other wikis where i can inform/suggest this JS but are on similar situation where they have to update every single navfram as that discouraging for them (as spanish wikis the communities are less participating that english ones) to change if they have to do so much work and will say "if its not broken, and we have to do so much... why change it?".
And as a separate note by doing this change your request below title "Beautiful buttons !" will be easier doing it via css as you can hide the braces using with .wrappedlink {color:transparent;} and telling to color the .collapseLink {color:black;} plus rest of stuff --Cizagna (Talk) Central Dofus 17:32, 13 November 2009 (UTC)

A derivative of Dan's script

At w:c:test-najevi:ShowHide_usage/jQ-najevi-v2.js you'll find a derivative that addresses two issues raised above:

  1. The non-essential wrapping of the user specified button labels in square brackets
    • the default strings now include those square brackets explicitly and the user is free to change the default using the message feature provided for that
  2. The span.collapseLink element is now prepended inside the div.NavHead container.
    • I am fairly certain this is what Cizagna was asking for. (It biases the placement of the button to be above the heading text when the heading runs to multiple lines and that is really a matter of personal preference I guess.)

Just tweak your monaco.js as folows:

importScriptPage('ShowHide usage/jQ-najevi-v2.js', 'test-najevi');
importScriptPage('ShowHide usage/jQ-najevi-v1.js', 'test-najevi');
importScriptPage('ShowHide/code.js', 'dev');

-- najevi 08:34, November 14, 2009 (UTC)

FYI the 2nd point mentioned above is not terribly important to the problem Cizagna was describing. It seems that getting rid of the text node appended to the div.NavHead is all that was really necessary. That text node was only created to contain the square brackets so removing it has not introduced any problems. You can verify this for yourself by importing jQ-najevi-v1.js (see above).
-- najevi 09:55, November 14, 2009 (UTC)

Version 3 returns CSS styling power to the user

I was not satisfied with v2 (described above) because I realized that the fundamental problem was that the heading and the toggle button are sharing the same div.NavHead container. (This is at the heart of Cizagna's issue.)

Therefore, in version 3 what I have done is

  1. revived the use of div.NavToggle as the container for the toggle button
  2. and inserted that container after div.NavHead
    • this effectively makes the heading and the button separate. CSS can now be used to style/align one independently of the other.
  3. I found it necessary/expedient to add div.NavClear which was inserted immediately after div.NavToggle
    • it's sole purpose is to allow the user who wants to center-align the toggle button to do so by specifying a clear:both style to "push down" any text that might have been inserted after NavHead but before NavContent.

Daniel, I did not understand why the <legend> tag might be used in a NavFrame. Therefore I left that line of code untouched. I do not have a test case to verify handling of a legend tag.

  • After a short break I plan to see if I can further extend Dan's code to implement my idea for "magnify/shrink" between a pair of images placed inside the NavPic container.

-- najevi 12:10, November 15, 2009 (UTC)

After some working out and streesing me to understand the differences in languages i found the following lines
var $buttonLink = $('<span tabIndex=0 class=collapseLink />').text( msg("hide") )
	.onLink(function(e) { toggleNavigationBar( $(this).closest('.NavFrame') ); });
var $button = $('<span class="NavToggle collapseButton" />')
$navHead.append( document.createTextNode(config.brackets.substr(0, config.brackets.length/2)), $buttonLink, config.brackets.substr(config.brackets.length/2) );
And was astonish that Daniel in fact had partially coded the span but was not actually using it at all, talk about wasting load times. So i add/change this
var $buttonLink = $('<span tabIndex=0 class=collapseLink />').text( msg("hide") )
	.onLink(function(e) { toggleNavigationBar( $(this).closest('.NavFrame') ); });
var $button = $('<span class="NavToggle collapseButton" />')
$button.append( document.createTextNode(config.brackets.substr(0, config.brackets.length/2)), $buttonLink, document.createTextNode(config.brackets.substr(config.brackets.length/2)) );
$navHead.prepend( $button );
For the clever eyes I change also the "append" for "prepend" because thats the way the old navframe handle that and since the documentation does not explain the reason of the change I'm in favor or avoiding compatibility issues unless needed
Now that I have something to target and it has a class i can use/add the following CSS
.NavToggle {
.NavHead {position:relative;}
This will let me handle left, right or center and with the absolute and relative combo it will not interface with the center alignment of the navhead like the old one
All this lets me obtain my desired effect of backward compatibility with out having to edit every navframe div already created so it can be adjusted.
Any way i will try to check tomorrow your 3 versions im curious to see how they will work and if i will require to edit the divs
--Cizagna (Talk) Central Dofus 10:30, 16 November 2009 (UTC)
New linkBefore config option and bug with the $button fixed. *sigh* I guess I have to watch this talkpage instead of expecting people to actually poke me when there is a bug in my code. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)

Beautiful buttons !

  1. Note that the Common.css at this site refers to .collapsibleLink when, in fact, the appropriate class label is .collapseLink
  2. I think that the square brackets ([...]) should be specified by the user rather than hard coded into the javascript. I realize the backward compatibility aspect of how it is done now. Backwards compatibility can be preserved by letting the default button labels include leading and trailing square brackets. Remember that a user can always customize those strings.
var ShowHideConfig = { 
    autoCollapse: 3, 
    userLang: false, 
    en: {
	show: "[show]",
	hide: "[hide]",
	showAll: "[expand all]",
	hideAll: "[collapse all]"

Removing hard coded square brackets from the NavHead DIV will allow a more contemporary button to be styled such as this one:show

without having those square brackets visible at either side:
.collapseLink {
 border:2px outset lightgrey; 
 padding:3px 5px;

--najevi 04:31, November 13, 2009 (UTC)

Brackets are not part of the link, adding those to the message would put them inside. I added a new brackets config, it takes a string such as "[]", "{}", and splits it up, things like "[[]]" will work and it'll split it up into [[ and ]]. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)
That's odd, I just tested removing brackets altogether by specifying
var ShowHideConfig = { 
    brackets: '',
however, the square brackets still appear outside my stylish lightgrey button.
What did you think of the NavToggle and NavClear classes for simplifying the styling of the button versus the heading? (see section just above this one)
-- najevi 16:42, November 15, 2009 (UTC)
The answer is
var ShowHideConfig = { 
    brackets: '  ',
The change Dantman made will pick a string and divide it in two parts the first part is the start of the link, the second or last part is the end of the link so by putting nothing is nothing so the code uses defaults the best way is to use 2 spaces that ways it gives 1 space for each side and 1 space alone with no letters in html its equal to not display.
--Cizagna (Talk) Central Dofus 06:23, 19 November 2009 (UTC)
Will work with brackets set to '' or false now. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk)

Please see help forum thread --Timeshifter 16:58, January 31, 2010 (UTC)

See Collapsed table via NavFrame. I found that I could create show/hide capability with just one line added to
For my needs I did not need to add any other JS or CSS. It might help others to copy this simple method to the ShowHide page. Maybe link to the page too: Collapsed table via NavFrame. --Timeshifter 16:33, February 2, 2010 (UTC)
I have since changed to using table wikitext for show-hide boxes instead of NavFrame wikitext. See

CSS is not discussed on ShowHide


importScriptPage('ShowHide/code.js', 'dev');

to MediaWiki:Common.js is easy enough.

Could a similar, single import line be created to pull in the relevant CSS to MediaWiki:Common.css?

CSS is not discussed at ShowHide.

I ended up copying and adapting CSS from here:

See: Forum:Collapsed table. Can't change background color --Timeshifter 23:07, March 18, 2010 (UTC)

Header Rows within tables

I am trying to find a way to show/hide header rows with all sub-rows as well as the table itself. Is there support for that? The code I am using apparently isn't getting the job done.

This is a test
This should be collapsible.
But it's not.

Rappy 19:46, April 22, 2010 (UTC)

Thats simple. You are not reading the instructions on the page, your code should look like this and will act like the table to the right
This is a test
This should be collapsible.
But it's not.
{| class="collapsible wikitable"
|- class="nocollapse"
|This is a test
!This should be collapsible.
|But it's not.
--Cizagna (Discusión) • HelperCentral hispana 08:53, 16 November 2010 (UTC)

Some features are not working for me

I'm trying to make this work on the w:c:allods but some things are not working as described here. For example, the "[... This content(2) does not auto-collapse ...]" still collapses by default. I also can't add [show all] [hide all] buttons by copying the div text.

I added the importScriptPage('ShowHide/code.js', 'dev'); to my w:c:allods:MediaWiki:Common.js, and this bit for w:c:allods:MediaWiki:Common.css.

I have no idea how it works, so I would appreciate some help. -- IcecreamKitten

Is this working with Oasis?

I am an admin at my wiki, and I can see Oasis there when logged in, and when I have Oasis set in my preferences. Others see Monaco for now.

Is it possible to import Javascript into Oasis as in Monaco? Show/hide does not seem to be working with Oasis in my wiki, and I haven't figured out yet how to get it to work. See:

Show/hide works fine in Monaco. Not sure if Oasis is importing the necessary show/hide Javascript here:

I added some custom CSS here:

--Timeshifter 05:55, October 1, 2010 (UTC)

I haven't checked if your code will work with other Skins than Monobook, but: Right now the importScriptPage function does not work - that's on our list. --Avatar@fandom 00:01, October 2, 2010 (UTC)

(unindent) Since importing does not seem to be working yet, I have now copied the Javascript from here:

I pasted it here:

I still do not see any show/hide links. See:

--Timeshifter 07:58, October 4, 2010 (UTC)

The Oasis problem has been solved

The Oasis problem has been solved


Paste the following into Common.js

function importScriptPage (page, server) {
var url = '/index.php?title=' + encodeURIComponent(page.replace(/ /g,'_')).replace('%2F','/').replace('%3A',':') + '&action=raw&ctype=text/javascript';
if (typeof server == "string") url = (server.indexOf('://') == -1)?'http://' + server + '' + url:server + url;
return importScriptURI(url);

importScriptPage('ShowHide/code.js', 'dev');

On the Cannabis wiki here is the relevant JS page:

This will import the necessary show/hide JS necessary for show/hide tables to work correctly in both Monaco and Oasis skins. --Timeshifter 20:28, October 4, 2010 (UTC)

This still does not work for me.

--w:c:unchartedwaters:User:©TriMoon™ 08:07, November 15, 2010 (UTC)

I am not an expert on show/hide coding. I see though, that the navigation table on the Foodstuffs page in the Wikia skin now has show/hide. It is open initially. I believe, if I am remembering correctly, that if there is only one show/hide table on a page, that it is open initially. This is if you are using that particular kind of show/hide wikitext. To change that something must be added, I believe, to the NavFrame wikitext at the top.
I use a different method in my wiki. Compare to the underlying wikitext in the show/hide tables here:
It only uses this: class="navbox collapsible collapsed"
That is all that is needed to add a closed show/hide link to the top of the table. --Timeshifter 18:26, November 15, 2010 (UTC)
The problem of not showing in oasis was temporal and has been already fix. You should remove the codes you inserted in your MediaWiki:Common.js and MediaWiki:Wikia.js and follow instructions on the article page. Important thing to note is that JS and CSS pages are cache and sometimes take time to refresh from cache. --Cizagna (Discusión) • HelperCentral hispana 08:31, 16 November 2010 (UTC)

(unindent) Thanks. I struck out the added code in one of my above comments. I also removed it from Common.js on my wiki too. After removing the additional code the show/hide boxes continue to work fine on my wiki. They are listed here:

Here is the JS and CSS I use:

I adapted the CSS from what is found here:

MediaWiki:Common.js is the only place the JS import code needs to added. All skins will then use it.

importScriptPage('ShowHide/code.js', 'dev');

This is a good starting point in my opinion:

NavFrames & Oasis

I'm pretty sure the script worked with oasis in this wiki before, but it actually doesn't. Can you help me?

And we have the same problem in this wiki. Thanks, --Weas-El (Talk) 18:45, December 1, 2010 (UTC)

I got the JS working in my wiki, and some CSS to work with it. You need both JS and CSS, I believe, for Show/Hide to work correctly. Here is the JS and CSS I use:
The relevant CSS is at the end and starts with
/* Standard Navigationsleisten, aka box hiding thingy from .de. */
You can look at the wiki code, and see how I implement Show/Hide here:
But I am not an expert, and don't have time to check out what you are doing. You might want to look at this:
Cizagna replies there, and seems to be an expert. You can contact Cizagna here:
--Timeshifter 03:27, December 2, 2010 (UTC)
Thanks for your answer, I'll go over your code later. --Weas-El (Talk) 10:56, December 2, 2010 (UTC)
Something definitely seems to be broken regarding NavFrames; the examples on this page don't work either. -- Porter21 (talk) 07:59, December 3, 2010 (UTC)
Each wiki has to add the necessary show/hide JS and CSS. The show/hide tables listed in the category below work fine:
There is different show/hide wiki code than is used in the above category. But the wiki code used in that category works with the JS and CSS added to that wiki (Cannabis Wiki).
--Timeshifter 08:09, December 3, 2010 (UTC)
I was talking about NavFrames (i.e. collapsible divs), not collapsible tables like the ones in the category you linked to. The templates on Weas-El's wiki also use the "collapsible div" portion of ShowHide, and not the "collapsible table" part. That collapsible tables are working is fine and dandy, but it really doesn't have much bearing on collapsible divs not working.
Collapsible divs do not work even on the dev wiki (i.e. here). I doubt the creator of the script wouldn't know how to set it up properly - and he was the one who did set it up here. -- Porter21 (talk) 08:58, December 3, 2010 (UTC)
See Talk:ShowHide2#Is Show/Hide2 better than Show/Hide?
Maybe Cizagna was discussing how to fix the NavFrame problem when Cizagna wrote this:
Their original show/hide now supports compatibility with the old navframe one, just needs to add
var ShowHideConfig = { linkBefore:true };
I don't know. I thought I read that NavFrames was the old method, and that collapsible tables was the new method. --Timeshifter 10:36, December 3, 2010 (UTC)

(unindent) NavFrames and collapsible tables are both old methods... they work on different types of elements, and which one is best to use varies by your use case. Eventually I had wanted to create a better more flexible new method, NavFrames and collapsible tables just exist in here for compatibility, this was basically a port of the Wikipedia script, rewritten completely in jQuery, half the size, more flexible, more features, and more efficient (jQuery's ready event fires earlier than MediaWiki's built in).

Now as for the bugs... I might as well point it out. Wikia broke ShowHide when they created Oasis. If you switch to monobook you'll see it still works, but in oasis it's broken, almost looking like it's working, but really NavFrames are broken where the show/hide link is inserted, but it actually never hides anything. I couldn't even figure out why myself, , I reported it anyways. Not like I'm optimistic anyways, I asked for a minor css change to do things the right and more flexible way and got rejected. I reported 3 extremely dangerous critical security vulnerabilities in the way Wikia is using MediaWiki in an unsupported configuration, they've only fixed the least critical so far.

It was worse for ArchiveTool... With Oasis Wikia has completely changed the base output, base ids always used in scripts, expected as a standard in all skins are changed, they violated Common.css no longer making it common "the idea is, there will be no 'common'" and making people put their common stuff in Wikia.css, meaning eventually people will start styling nothing but Wikia.css and for newer wikis anyone trying to visit in Monobook could start finding that styles aren't even being applied to that skin anymore.

Basically I've just gotten tired of it, didn't like Oasis anyways, so I've dropped my flag and am not bothering programming anything Wikia related anymore. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk) 13:43, December 3, 2010 (UTC)

I know how you feel; Wikia has adopted a "we know best and don't need to listen to anybody" attitude that's quite irritating, especially when paired with a flurry of questionable decisions. Not loading Common.css for Oasis is among these; while fixable with a little @import, it requires more CSS knowledge than most people have.
As you're here - I hope you don't mind my changes to the ArchiveTool? The editors at my home wiki find it quite useful and would have hated to lose it, so I tried to make it work for the remaining skins.
Regarding ShowHide, changing the line
$navFrame.find('.NavPic, .NavContent').not($navFrame.find('.NavFrame .NavPic, .NavFrame .NavContent')).slideToggle();
$navFrame.find('.NavPic, .NavContent').slideToggle();
makes showing/hiding NavFrames work again (although you get a duplicate "show/hide" button). Not sure why this happens (I'm not an expert by any means), just to mention it. -- Porter21 (talk) 15:10, December 3, 2010 (UTC)
The purpose of the .not() was supposed to make sure that the show/hide button does not toggle nav frames which are nested inside of another nav frame, which was part of the functionality of the original code iirc. ~ NOTASTAFF Dantman(Local TalkAnimanga Talk) 15:45, December 3, 2010 (UTC)
Yeah, it's rather strange. If I add a copy of the script to my wikia.js and remove the .not, collapsing works, duplicated show/hide buttons appear (of which only one works) - if I leave the .not in, collapsing doesn't work, the duplicated buttons appear but neither of them works. -- Porter21 (talk) 17:16, December 3, 2010 (UTC)
I'm still desperately looking for a way to fix the collapsible divs in w:c:inheritance (for example here) and w:c:canavansbooks (for example here). Please help! --Weas-El (Talk) 01:33, December 31, 2010 (UTC)


Please see:

It summarizes some info for implementing Show/Hide with the Oasis/Wikia skin. --Timeshifter 07:21, January 10, 2011 (UTC)

Show/Hide help for a noob?

I am sorry to bug and feel stupid having to ask how this works since I have read the info what seems to be 100 times already.

I wanted to have a normal Show/hide section. I dont need tables tho they would be fine.

I have copied and pasted importScriptPage('ShowHide/code.js', 'dev'); into my MediaWiki:Common.js. Do i just post the little line importScriptPage('ShowHide/code.js', 'dev');

or do I post the whole code located in ShowHide/code.js.

I am using custom skin, not oasis or anything. I really want a simple show hide for archiving my news and couple other things. My site is

I am fairly new to editing so patience and a thurough explination would be very much appreciated.

Thanks again for any help. BornAProphet 04:30, February 3, 2011 (UTC)

Just add the import line. As I did here:
The current version of show-hide is not working in the vector skin. It is working in the other skins. You also need to add CSS.
See also:
It summarizes some show/hide info. --Timeshifter 06:03, February 3, 2011 (UTC)


Having read through the rest of this talk page... has anyone actually gotten NavFrames to show/hide properly in Monobook or Oasis? My home wiki uses collapsible navframes in several areas and they're broken in both skins (the NavFrames also don't work even on this dev page). We can rework things for tables, but if someone has gotten them working properly (without doubled links) I'd obviously prefer that. --lordebon 18:30, February 7, 2011 (UTC)

Can you link to a page with a broken collapsible navframe? --Timeshifter 20:22, February 7, 2011 (UTC)
Sure: this is our templatized implementation of it. But the navframes on the ShowHide page here on the dev wiki don't work either in either Monobook or Oasis. The content inside the frames is always shown and the hide/show links don't change that. Oddly clicking the hide/show links does change it between saying "Hide" and "Show" it just don't affect the visibility of the content navframe. --lordebon 19:45, February 14, 2011 (UTC)

(unindent). I managed to get show/hide to work on my wiki by importing the JS with the single line of code, and then adding some CSS. You are using a different method than what I use.

Your code from that page you linked to:

<div class="NavFrame collapsed">
<div class="NavHead" style="text-align:left; padding-left:16px; background: #CCCCFF;">A Treatise on the Sport of Gnome Punting </div>
<div class="NavContent" style="text-align:left;">
The sport of Gnome Punting... etc.

General wiki-code below for the Cannabis Wiki show/hide tables is from here:

{| class="navbox collapsible collapsed"
!Title text. 

I only understand the method I use (barely understand). Maybe someone else can help you now that we see the problem more clearly. --Timeshifter 00:05, February 15, 2011 (UTC)

That probably works only because it's using a table rather than divs -- the table code seems to be working fine, we were just hoping to not have to rework things to use tables. Ah well, I'll look at converting our template to tables or perhaps trying our own code locally. Thanks for your replies, Timeshifter. --lordebon 14:22, February 23, 2011 (UTC)

Show all/Hide all not working

It's not working in here: (below "Staffel 1") - what's wrong with it? If useful: I'm on windows and mac, both on ff 3.6. I could really use that as opening so many stuff step by step is getting annoying, and I don't want spoilers to be visible :) Marc-Philipp@fandom (Talk) 10:08, February 23, 2011 (UTC)

Per ShowHide#Feature overview, when Dantman wrote this, "All NavFrame blocks on the page are affected however, collapsible tables are not affected by these buttons. This behavior is by design." So Dantman made the Show/Hide all buttons only for NavFrames not collapsible tables. Cheers, Grunny (talk) 02:42, February 24, 2011 (UTC)

Show/Hide button is not shown

I have a Navbox:
The problem is - when this page is viewed in Opera 9.26 unlogged, the Hide/Show button is not shown. There is no such problem for Opera 10.01 and FireFox (both unlogged).
Do you know what the problem is? Teyandee 18:31, June 1, 2011 (UTC)

Does this problem happen in this wikis show/hide examples? --Cizagna (Discusión) • HelperCentral hispana 07:00, 02 June 2011 (UTC)
Yes. Teyandee 15:48, June 2, 2011 (UTC)
I have found something that can help: - Button shows, but with is decreased when collapsed
Teyandee 21:40, June 4, 2011 (UTC)
Those are the old collapsible versions that don't have JQuery, I'm clueeles on the issue what worries me is the unlogged part that means that if you are logged you see and it works the show/hide with no problem? --Cizagna (Discusión) • HelperCentral hispana 05:35, 06 June 2011 (UTC)
When I view the unlogged (as a guest) via Opera 9.27 & 10.01 / FF 3.6.17 the show/hide button is shows and is working. Teyandee 16:27, June 6, 2011 (UTC)
The JS code for the show/hide at w:c:mlp:MediaWiki:Common.js and w:c:help:MediaWiki:Common.js are the same. Dont get me wrong I'm just pointing out details... its seems more than the explorer cant handle the code, what exactly I dont know but those wikis that you have show as example use older versions (really old versions) of the showhide, JQuery its just a set of JS tools that simplifies JS work. Its best that you upgrade all your explorer to the lastest stable version. --Cizagna (Discusión) • HelperCentral hispana 21:38, 06 June 2011 (UTC)
But why are you worrying? It may be an old version but it works. At least for me. And now the button do shows in Opera 9. Teyandee 16:28, June 7, 2011 (UTC)
On the other hand, a new version will be better. Such as w:c:dragonage:MediaWiki:Common.js - it has jQuery and the show/hide button works.
The question is: Do I really have to use the new version? Teyandee 16:55, June 7, 2011 (UTC)
Dragonage is also using an old version of show/hide, the Jquery code it has is about other stuff... What is worrying me is the fact that it only affects unlogged in other words when you are log you have no issues but when you are unlog you have issues.
About your question of using the newer version "thats your call"... newer versions just have more functionalities or effects, sometimes less or simple coding which translateds sometimes is faster processing or faster loading of a page. But if you like the old version... well use the old version as i told you its your call.
--Cizagna (Discusión) • HelperCentral hispana 00:46, 08 June 2011 (UTC)
I understand the advantages of the new version but hee we have an issue which prevents me form using it: It is easier for me to create a Navbox by using w:c:spcfanfics:Template:Navbox than by using something like this: ShowHide#Example. Providing no special functional is needed (like the pictures) I think I will use the current version. Teyandee 16:36, June 8, 2011 (UTC)
I don't understand what you mean by easier, that is a refined template as one can see the coding it has. So if you apply that to this tool it becomes as easier for everyone that way. You can see the template uses collapsible tables (in HTML format) and we are showing also examples with tables (in wiki format). If you mean harder by the configuration examples that is for changing defaults to something else. The picture functionality is for NavFrame (divs). The extra functionality for table is that you can determinate what rows should not be collapsible and be able to nest tables in those row that will not be affected by the collapse of the parent table. You could copy english Wikipedia's collapsible JS for tables they have a similar version with old JS thought its a bit more complex in the classes you can see its help page. It would be another alternative for you. But you may get in troubles if you start copying wikipedias mixed formats as we dont have tidy so HTML and wiki format get along each other. Btw this will never work thats a CSS page not a JS page. --Cizagna (Discusión) • HelperCentral hispana 23:12, 10 June 2011 (UTC) 23:12, June 10, 2011 (UTC)
First of all - sorry for not replying so long. I forgot to put the message I was on vacation.
Second - this is what I meant by easier:
It is easier for me to create a NavBox using a template: w:c:spcfanfics:Template:Navbox that using this much code for the same purpose. But - maybe it can be done easier by defining all of this in a "NavBox" template.
Third - I now see that I have tried to used js-code in css :) I am still trying to understand all this thing so such many questions are arised. For example: now I used the js-code correct, but here is a difference: the show/hide buttons are no longer look like links. Compare: Template:Fan Fiction Articles2 vs Template:Episodes.
Teyandee 06:04, June 24, 2011 (UTC)
Sorry I was also not paying attention to this. My understanding issue relies on the fact that you can create a template for the code both codes here for example
Wiki Markup (wikitext) HTML
{| class="collapsible"
! colspan=2 | Header
|- class="nocollapse"
! Col H1
! Col H2
| r1c1 || r1c2
<table class="collapsible">
<th colspan=2> Header </th>
<tr class="nocollapse">
<th> Col H1 </th>
<th> Col H2</th>
<td> r1c1 </td><td> r1c2 </td>
Will display as below
Col H1 Col H2
r1c1 r1c2
Col H1 Col H2
r1c1 r1c2
The Template you are showing is HTML based and this show/hide is compatible with the template you are showing.
Now this tool its also compatible with "NavFrame". This is the original show/hide tool and instead of using HTML tables(or wiki markup) it uses div tags as following
<div class="NavFrame">
<div class="NavHead"> Header </div>
<div class="NavContent"> Content </div>
Will be display as below
All the extra garbage you are seeing are notes for some one who is learning what it can do and the person who wrote the examples (najevi) its a very meticulous when explaining and gives a lot of details (you can see by reading my old and resolve compatibility issue).
Now to explain a bit of history NavFrame was created originally at the German wikipedia so it could hide the Navigational boxes (NavBox) at the end of the pages Using a combination of JS and CSS coding. Later on it was exported to the English wikipedia. Then they did not like to use Div tags as they require some level of experience to be able to use them properly and the CSS put a series of restrictions they did not like and many where adding the NavFrame to hide stuff and the content on HTML table. So they request to be able to use a tool that only afected tables so it was more clean to the editor side and a 2nd JS tool was added (based on Navframe) call Collapsible tables (Collapsible). The tool was then refine integrating stuff from the Navframe and the Collapsible together and later on adding portions of the CSS directly to the JS. The Collapsible users wanted the autohide function (once the page loads the content gets hided) that the Navframe had so this was partially added. Then this code was exported (more like copied individually to every wiki in wikia) in general from wikipedia but there are many wikis with different versions in different history stages (German wikipedia still uses the old NavFrame). The years pass and here at Wikia we upgrade our JS to use an extra set of JS tools first Ajax and later on JQuery Dantman then translated the JS code of Collapsible and NavFrame (popularity known as Show/Hide) to a JQuery version (1st advantage way less code means faster page loading), the use of the importing JS tool rather than a copy/paste technic (2nd advantage it gets updated, in case of a malfunction see next point for reasons), then he add language compatibility (3er advantage you can use the same code for an english or spanish or a german wiki), finally there was certain effects or extra functionalities that come with JQuery that where added (its your call if this is an advantage or not).
So summarizing... I don't understand your main issue as you keep saying is complicate but the simple examples you are showing here are HTML based tables and the examples this page is showing are Wiki markup tables in other words its the same just need to know it (as wiki markup gets translated to HTML code). The NavFrame is the only difference I can spot as its an older beast and requires a bit more creativity and can easily get messy. As explain in the history portion show/hide its JS and CSS combination tool. Here you only obtain the JS, the CSS you have to figure by yourself as everybody does weird things, and here we are using wikitable that replicates in the boxes inside thats why my examples dont look good compare to the oficial ones except by the NavFrame one that its class its properly codded in this wikis CSS.
About your link question. Its by design but if you want it to look like a link just add the proper CSS to the class collapseLink to look the color you are interested and with underline if you want one of the key difference is that the old JS inserted an href that call the JS instead now there is a event listener that waits for you to click on the words.
Sorry if its to much info but I really can't fully grasp whats the main issue you have as we have drift from the topic of "its not compatible with certain old explorers?".
--Cizagna (Discusión) • HelperCentral hispana 19:20, 18 July 2011 (UTC)
I think the main problem is - how to quickly create a collapsible Navbox. I can think of 2 types:
1) Navbox content can be represented as a list:
2) With a random content, such as
First one are easy to create by using the Template:Navbar and Template:Navbox,
The problem is with the 2nd type navboxes. The thing is to create a NavBar with [v-d-e] links, caption in the center and [show/hide] link at the right. I suggest in can be done by manyaly creating the and attaching it to the Navbox content.
As per "easier" - I just no so familiar with wiki syntax and prefer HTML more. And if all that code can be in one template for easy using then it will be good. Teyandee 12:37, July 31, 2011 (UTC)
The wiki-code is editors side and gets translated to html so if you use html does not matter. The #2 template got modify by Throwawaytv the day you got post. If you understand how this java works is easy to understand. [show/hide] buttons will appear in the first header row as simple as that. To add the [v-d-e] links just warp it in a span style it with float left then continue with your title.
--Cizagna (Discusión) • HelperCentral hispana 05:32, 29 August 2011 (UTC)

Problem with coding

I'm testing the Navframe div on this page of my wiki

I was originally having a severe problem getting the navframe to autocollapse, but now the show/hide tags are screwed up. I have two show/hide tags, one of which is useless, while the first one shows 'hide' when it is already collapsed. I believe I have all the coding in the proper places, so I don't know what I'm doiI'm doing wrong), we have some extremely long descriptions on some of our articles and people were asking whether it'd be possibly to collapse them, so the pages aren't so long.

I also have a question about the Navhead div... is it possible to make a section header with the "= =" tags in that area? I tried it and it refused to work, so I didn't know if it was possible.

I have no idea what I'm doing and would appreciate some help. Immortallies 18:13, August 19, 2011 (UTC)

I took the liberty to remove a lot of duplicate coding (at your MediaWiki:Common.js]] you had 3 instances of show/hide (this one and 2 old ones) thats why you where looking at 3 links.
I need to double check if what you want is possible, but if its done I need to stress you this can be very dangerours because == states like section break so part of the coding of the collapsible table is in one section and the rest is in the other section and if some one delets it, will broke the page.
--Cizagna (Discusión) • HelperCentral hispana 03:34, 29 August 2011 (UTC) 03:34, August 29, 2011 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.

Fandom may earn an affiliate commission on sales made from links on this page.

Stream the best stories.

Fandom may earn an affiliate commission on sales made from links on this page.

Get Disney+