Template talk:Click

From TheKolWiki
Jump to: navigation, search

This template may be useful for crafting type templates, but may also have some significant accessibility issues. I have applied it to Template:Toymaker, but am reluctant to apply it to any other templates until Safari and IE users grant feedback on the functionality of this template under those browsers. If it doesn't significantly break the pages, and if the image still loads, it may be worthwhile to use this template in place of the current link to the image. --Aardvark (Talk | Contribs) 05:42, 20 March 2006 (CST)

  • I fired up IE 6.whatever and it seems to be working fine. --Ricket 06:34, 20 March 2006 (CST)


{{click|width=30px|height=30px|image=Lime.gif|link=Lime}} yields Lime.gif

I like the concept and functionality. However, is it possible to get rid of the height width bit that stretches the image? Most of our images for items are 30x30 anyways.... And it works just fine in my Mozilla... Good find!--jin 21:43, 20 March 2006 (CST)

Didn't realize it was stretching; for some reason, my browser reported 42x36 as the image size. Sure, I can hardcode that bit into the template and get rid of a few parameters by doing so. Uno Momento. --Aardvark (Talk | Contribs) 02:47, 21 March 2006 (CST)
Hmm. I seem to be observing wierdness with it now. I might have goofed the CSS; gonna poke around a bit.--Aardvark (Talk | Contribs) 02:57, 21 March 2006 (CST)
I found the problem. Image:CrimboHat.gif is 42x36. Image:Lime.gif is 30x30. I've restored the paramater, because if the image is sized wrong, the template just won't work. But I fixed the example above, in either case. --Aardvark (Talk | Contribs) 03:01, 21 March 2006 (CST)


This template seems to be causing problems. If you look at the Established Standards page, you'll see the crimbo hat up top covering the E on the page title. I don't have a clue where to begin on fixing that, short of reverting back to the old version of the toymaking template. Aardvark, can you fix this? --jin 20:32, 22 March 2006 (CST)

Dang. I'm not sure of how else to fix this either, so I'm reverting {{toymaker}}. Shame. --Aardvark (Talk | Contribs) 20:39, 22 March 2006 (CST)
Although I'm unsure of the specific cause, it could, potentially, have been caused by a code problem on Established Standards. If there's an unclosed <div>, that could possibly have caused the problem. (That page has so many templates, etc., that it is feasible that that's where the problem is coming from). I'll pore over the code later, and see if that might be the reason for the breakingness. --Aa</ffont color="green">rdvark (Talk | Contribs) 02:40, 23 March 2006 (CST)

Have the issues for this template been resolved? It's been added to various templates and I didn't see any mention.--Dehstil 14:03, 3 June 2006 (CDT)

One other issue with this template is that it forces line breaks around the image being used, due to it using <div>. --Quietust 08:59, 13 June 2006 (CDT)

A cleaner way

text before Oven.gif text after

No scary html, height/width designations, or incompatibility. HTML-wise it links conventionally like a normal linked image should, producing no voodoo behavior. The cost is that you have to use the full url of an image, but since you're going to the image to find the height and width the other way, I figure this is nicer. Any objections?

Also, I've tried automatically finding the url through [[Media:Cooking.gif]], but so far all efforts have failed.--Dehstil (t|c) 16:16, 10 July 2006 (CDT)

  • Also, another advantage is you can put stuff before and after it on the same line without using tables.--Dehstil (t|c) 16:19, 10 July 2006 (CDT)
  • I'll take the silence and continued use of the other method as an objection...a secret objection.--Dehstil (t|c) 15:54, 11 July 2006 (CDT)
    • The trouble with that method is that you have to manually check the directory used for the image, which gets really annoying after a dozen or so times (getting the image size isn't difficult, since they're mostly consistent - images and familiars are 30x30 and most map spots are 100x100). Perhaps we could find a parser extension to grab the path of an image and get it installed. --Quietust 16:02, 11 July 2006 (CDT)
      • Something like this? (That was easy) Phlip 21:24, 4 August 2006 (CDT)
        • Sweet, now we need to someone to install it...eventually. By the way, we still need randomlyselect hooked like a parserfunction or use #rand minus the cache line.--Dehstil (t|c) 21:29, 4 August 2006 (CDT)
        • Who do we need to nag? Mag? I think we scared him away.--Dehstil (t|c) 18:33, 9 August 2006 (CDT)
  • *Bump!* Heh. I'm all in favor of implementing this. Another problem with {{click}} is the fact that it doesn't play nice a lot of the time - see the old version of my Campground attempts at what should have been perfectly reasonable by putting them next to each other. --Alpaca (T/C) 18:30, 1 August 2006 (CDT)

Now that we have an extension to give us the media URL, this method works now. The only trouble is that images whose names contain underscores do not work, since the wiki converts the underscore into a space and the 'media url' converts the space into a +, which causes it to not render. --Quietust 00:03, 8 September 2006 (CDT)

  • The speediest course of action would be to rename images like "Image:Still sm.gif" until implementaion is corrected.--Dehstil (t|c) 00:10, 8 September 2006 (CDT)
    • OK, that's easily fixed... I used the wrong function (oops)... I'll tell jin how to fix it. Phlip 00:41, 8 September 2006 (CDT)

Failure with images including an Underline

In rewriting this, one of the two of you (and you know who you are ;-) ), broke this template for images with underlines in their filename. Scroll down the Recipe page to see the ones which broke. (The level 15 crafting skills specifically) --JRSiebz (|§|) 00:20, 8 September 2006 (CDT)

  • Funny that as I was writing this in a new section, you discussed in in the existing section. --JRSiebz (|§|) 00:21, 8 September 2006 (CDT)

There's actually two problems - one is that it's putting + instead of _, and the other is that it's giving it the wrong directory as a result: Compare _https://cdn.coldfront.net/thekolwiki/index.php/File:Big_head_todd.gif to the URL in Media:Big_head_todd.gif. --Quietust 00:29, 8 September 2006 (CDT)

  • A kludge fix is simply to the rename the offending images... --Gymnosophist 00:44, 8 September 2006 (CDT)
    • It seems it has now been fixed. Phlip 06:16, 9 September 2006 (CDT)

span class="auralonly"

For some reason, this tag is causing the image to appear twice in Firefox for me (but not in IE or Opera). It may be due to me having the Web Developer toolbar installed, though I don't see how (since it doesn't change anything unless I tell it to). --Quietust 18:20, 10 September 2006 (CDT)

  • Hmm, with webdeveloper disabled, it seems fine. A buggy extension, grr. A very minor enhancement vs. a very minor bug: Keep it or no? It helps keep track of where an image is used and allows (with a few tweaks to your browser) you to get to the image page without scolling through the page source or anything. On the other hand, if your browser's implementation of css is broken, you might get two images.--Dehstil (t|c) 18:48, 10 September 2006 (CDT)
    • Hm, it must be something else - I uninstalled Web Developer, and it still happens. It's probably a misconfiguration somewhere in my browser settings. --Quietust 19:06, 10 September 2006 (CDT)
      • I have it too. The web developer toolbar has never done something this cooky before. Another note, the left bar display Forum, Kol Coldfront, and Kol IRC twice.--SomeStranger (t|c) 19:15, 10 September 2006 (CDT)
        • Nevermind that, just hard refresh the page and it fixes itself. The other stuff is still broken though.--SomeStranger (t|c) 19:16, 10 September 2006 (CDT)
          • Oh, I'm waiting for mag or whoever to remove the second set of links from the skin since it's already in Mediawiki:Sidebar. And yeah, the problem was that ".auralonly" was in the style sheet; which needed to be refreshed.--Dehstil (t|c) 19:20, 10 September 2006 (CDT)
            • Ah, that fixed it. --Quietust 20:23, 10 September 2006 (CDT)
            • What on earth does this addition do anyways?--SomeStranger (t|c) 19:37, 10 September 2006 (CDT)
    • Why is this diplaying two images? See all on Recipe, or the esamples here, or any item with a recipe? --JRSiebz (|§|) 23:21, 13 September 2006 (CDT)
      • This is the same problem I was seeing before, only this time force-reloading my stylesheets isn't fixing it. --Quietust 23:22, 13 September 2006 (CDT)
        • For some reason all mediawiki messages revert themselves to some random version way back, then revert back...which have something to do with the whole "load that stuff into a static file" thing you were talking about earlier.--Dehstil (t|c) 23:26, 13 September 2006 (CDT)
        • I guess we could revert some the stuff that rely and recent changes to mediawiki messages.--Dehstil (t|c) 23:32, 13 September 2006 (CDT)

Image size (and other parameters)

It might be nice to have a way of specifying the image size (and perhaps caption/location/etc) in this template. The current syntax is a bit too byzantine for me to tell if this is possible or note. :) --Starwed 07:23, 21 July 2007 (CDT)

  • The image size is always the size of the image used. the the "hover text" (alt. text, title, or whatever you want to call it) ends up being the destination of the link. Or you saying you want to be able to scale images somewhere? --JRSiebz (|§|) 22:21, 21 July 2007 (CDT)
    • The way this template is done, it is not possible to scale the images or put in special alt-text. We'd need a special wiki extension in order to get that sort of functionality. --Quietust (t|c) 22:38, 21 July 2007 (CDT)
      • Is this still the case? Because I'd certainly love to see this, as well. I'm a very big fan of productive image clicks and eliminating unproductive ones. I prefer to only leave in the default [[Image:]] click behavior when the page its on is, in some sense or another, the "first" it appears on. So it'd be nice to be able to use things like question.gif in a resized format without the image having an unproductive click; would make it a much prettier way of denoting unknown things on pages, for example. I would otherwise like to hear more about why the template can't be modified to accomodate these features. It seems like it should be able to, but perhaps I'm missing something. And I'm always fond of learning more about template coding these days. --Flargen 13:50, 12 December 2008 (UTC)
    • Yeah, I was hoping there would be an easy way to scale images. (I was toying with a "StackImage" like template for locations, and by default the location images are way too big.) Since there's not, doesn't really matter.  :) --Starwed 08:42, 22 July 2007 (CDT)

Template seems to be broken

Looks like something with the update messed up the template. Take a look at my userpage for example.-Toffile 04:38, 10 September 2008 (UTC)

Fix Template: Alt Text

Someone please edit this template to include proper alternate text on mouseover/screenread instead of the full URL into the Wiki. Should be able to change
Image:{{{image|nopic.gif}}}{{#if: {{{link|}}} | {{!}}{{{link}}}}}
assuming my syntax is anywhere near correct. - Msanychta (talk|contribs) 17:45, 6 September 2009 (UTC)

Yes? No? Maybe so? - Msanychta (talk|contribs) 01:58, 14 September 2009 (UTC)

Fix Template: captchas

Using this template triggers the captcha test. Would using localurl instead of fullurl fix that? --Club (#66669) (Talk) 20:01, 27 May 2010 (UTC)

  • The short answer looks to be "no". Fullurl seems to be the only way to get the image from the wiki, using wiki codes, without the wiki putting its own wiki (link) formatting onto said image. Which is exactly what you want to achieve with this template: make the image a clickable link to some page (or completely unclickable), whereas the wiki by default makes [[Image:...]] link to the image's page. And the wiki won't let you use the <img> tag as a workaround. --Flargen 04:27, 8 June 2010 (UTC)


I know this template has been just changed to work with the updated mediawiki from its old kludgey mess, but we should work on phasing it out completely, as now it is pretty much just a limited call to the now expanded image tag. Image linking, alt text, and resizing can all be done natively. And no more full url alt text when using click! Examples:

Old Way New Way
Regular image, links back to image: description page [[image:foo.gif]] [[image:foo.gif]]
Image, which for some reason we want unclickable {{click|image=foo.gif}} [[image:foo.gif|link=]]
Image, which links to a page {{click|image=foo.gif|link=bar}} [[image:foo.gif|link=bar]]
Image, alt text [[image:foo.gif|bar]] [[image:foo.gif|bar]]
Image, with link, and alt text N/A [[image:foo.gif|link=plugh|bar]]

-JRSiebz (|§|)

  • Yes, it probably needs to be phased out with a bot. Getting an unclickable image is slightly less obvious with normal image linking, but still works. Starwed made the click changes because the existing click was busted after the mediawiki change, and it seemed best to make it work again so pages would look fairly presentable still. --Flargen 09:00, 26 June 2011 (CEST)
    • Agreed, this should be phased out. Also... "Deprecated" is what you mean here (to mark as do not use in the future), NOT "Depreciated" (to allocate value to cost over time). I've fixed the section header. --Wrldwzrd89 13:37, 26 June 2011 (CEST)
      • All templates have been updated to no longer use {{click}} - once the job queue empties out (which is, rather annoyingly, only visible here), then we can get to updating normal pages. --Quietust (t|c) 23:35, 22 July 2011 (CEST)
        • QuietBot has removed pretty much all known instances of this template - if there's no objection, the template can be deleted. --Quietust (t|c) 21:22, 3 August 2011 (CEST)