Template talk:Item icon

#ifexist

This template has the exact same issue {{Crafting/Item}} had not too long ago. There's a discussion about it on its talk page. Can we please stop re-making the same mistakes? — Rhoot 06:57, 14 June 2012 (UTC)

Extension

How big a mess would it make if I defaulted the extension this templates calls to .png? - Infinite - talk 16:14, 15 June 2012 (UTC)

Oh, it.. already is? That is so weird. - Infinite - talk 16:20, 15 June 2012 (UTC)

Vertical Alignment

Example 1 — Inline text

{{item icon|Might Jute Insignia}} {{Healing}}

Healing Jute Insignia  Healing

Example 2 — STDT Table

{| {{STDT}}
|-
| {{item icon|Healing Jute Insignia}} || {{Healing Power}} +

Healing Jute Insignia

Healing Power +

---

Discussion

For some reason, this template aligns the bottom of the icon to the bottom of the text. Compare with the attribute icons, e.g. {{healing}}, that align the middle of the icon with the top of the text. The latter looks much, much better imo, especially in {{STDT}} tables, which seems to middle-align text & icon.

Does anyone object to updating {{item icon}} to follow the same style pattern as the attribute icons? – Tennessee Ernie Ford (TEF) 15:37, 22 June 2012 (UTC)

I see absolutely no difference between the two in Chrome. Could you upload a screenshot? —Dr Ishmael 15:50, 22 June 2012 (UTC)

The reason it happens is cause I added the overflow span to {{item icon}}, to avoid tables looking like crap. I have a fix for this and other things at MediaWiki talk:Common.css, but I don't think anyone has that on their watchlist. :P

I'll fix it temporarily, though. — Rhoot 15:57, 22 June 2012 (UTC)

Cool. I'm glad you could see to the (ahem) root of the problem. – Tennessee Ernie Ford (TEF) 16:06, 22 June 2012 (UTC)

I don't like the overflow:hidden format — in fact, I don't like the whole "hide the red links" paradigm that pervades the community here. I've always believed that red links are red links for a reason, and if they make a page look ugly, then it's ugly for a reason. —Dr Ishmael 16:23, 22 June 2012 (UTC)

Normally I'd agree with you, but for icons in tables it makes sense to keep them the same size as the actual icon would be, regardless of whether or not the icon exist. The one time I agree with hiding red links is when it's to an image, and it's likely that image going to be missing for some time. Then (IMO) it should show another image instead, that still makes it clear there is content missing. — Rhoot 17:00, 22 June 2012 (UTC)

As long as the red link points to the missing image (or article), I don't care if it displays as File:Correct link to missing image.jpg or [[File:Correct link to missing image.jpg|Missing image]]. In general, I agree with Ish: don't remove red links, don't create a stubbed article, and don't redirect just to avoid seeing red. I've several times created links to articles on topics I thought were missing, only to be unable to find them later b/c they were stubbed or redirected. – Tennessee Ernie Ford (TEF) 18:08, 22 June 2012 (UTC)

(Reset indent) (yeah I'm v late to the party..) personally I hate having the missing images hidden. --Chieftain Alex 23:19, 13 November 2012 (UTC)

40 px

Would it be useful to have a 40px version since thats the size that the infoboxes use? -Chieftain Alex 21:16, 26 February 2013 (UTC)

Use with generics

Is there any good way to make generics display specific icons? For example:

• {{Item icon|Sword}} to [[File:Iron_Sword.png|20px|link=Sword]] Sword (or the blue icon for sword on the discover panel, I don't find the icon anywhere)
• {{Item icon|Iron Imbued Inscription}} to Iron Imbued Inscription

We already have a lot of cases where Item icon shows the default black lock icon, mostly on crafting pages.--Lon-ami (talk) 16:25, 29 June 2013 (UTC)

I tried to do it here:

{{#if: <!-- hiding linebreaks -->
{{#vardefine:smw_icon|{{#if:{{{icon|}}}|File:{{{icon}}}.png|{{#show:{{{1|}}}|?Has game icon|link=none|default=File:Skill.png}}}}}}
{{#vardefine:smw_name|{{#show:{{{1|}}}|?Has canonical name|default={{{1|}}}}}}}
}}<span class="{{#if:{{{large|}}}|medium|small}} item-icon thumb-icon" style="display:inline-block;overflow:hidden;{{#if:{{{large|}}}|width:35px;height:35px|width:20px;height:20px}};vertical-align:middle;">[[{{#var:smw_icon}}|{{#if:{{{large|}}}|35x35px|20x20px}}|link={{{1|}}}]]</span> {{#if:{{{2|}}}| [[{{{1}}}|{{{2}}}]] | {{#if:{{#var:smw_name}}| [[{{{1}}}|{{#var:smw_name}}]] | [[Item]] }} }

Maybe someone better at this mediawiki stuff can fix it up. Psycho Robot (talk) 17:08, 4 July 2013 (UTC)

{{item icon|Sword|icon=Simple Sword.png}}

Sword, added an icon parameter so you can define arbitrary icons. You can also upload "File:Sword.png" and we can have it default to that. It's rather overkill for a template that's suppose to display items, but who cares.--Relyk ~ talk < 20:11, 4 July 2013 (UTC)

The disadvantage of "File:Sword.png" is that we would duplicate a file. Isn't there any way to link the original? #REDIRECT doesn't seem to work.

Thanks for the work ;).--Lon-ami (talk) 20:16, 4 July 2013 (UTC)

duplication isn't a problem, we're simply picking a default icon for the weapon type.--Relyk ~ talk < 20:27, 4 July 2013 (UTC)

How does the "has game icon" property work? Seems we should add these kind of things there, nope? I was confused as of why things like this Wintersday Gift displayed no icon when the file is called exactly like it File:Wintersday_Gift.png, and I noticed it uses the property system (which I don't understand too much :/).--Lon-ami (talk) 16:05, 7 July 2013 (UTC)

Wintersday Gift is not an item and therefore does not get Property:Has game icon (which is set in infoboxes). If the article isn't an item, then you shouldn't be using "item icon". I've proposed a generic icon template (User:Relyk/sandbox/icon) for generating an icon. For instance, --Relyk ~ talk < 16:30, 7 July 2013 (UTC)

It's useful when you want to refer a group of items in tables, to keep with the format. Better a shortcut like this than linking 6 items. Doesn't hurt anyone, and the wiki has references like this everywhere, specially crafting pages.--Lon-ami (talk) 21:17, 7 July 2013 (UTC)

Not working with halloween skins

As can be seen on Mad King Chest (historical), this icon isn't working properly with the various halloween skins. I can't figure out why. I know its a problem with this template and not the Contains template because look! Greatsaw Greatsword Skin Psycho Robot (talk) 19:01, 8 November 2013 (UTC)

It seems to be a file system error, it's happened before with other images (can't remember which ones offhand). —Dr Ishmael 19:15, 8 November 2013 (UTC)

old examples: All of the pact weapons / Guild Wars 2 Wiki:Reporting wiki bugs/archive 3#Image display cache problem. Chieftain Alex 19:27, 8 November 2013 (UTC)

That's exactly what I was thinking of. —Dr Ishmael 20:26, 8 November 2013 (UTC)

Spawns horrible property spam if used with empty parameter

{{item icon|}} adds some horrible property monstrosity. I'm not sure if this here template is the root cause, or if it's further down the chain. This is as far as I managed to track it. I'd try to fix it myself, but it all looks like someone merged Lisp and Twitter to me. --zeeZ (talk) 17:24, 29 June 2015 (UTC)

icons are slightly short

On Firefox and Chrome (haven't checked on other browsers), icons that should be 20px appear as 19px. See comparison on Firefox (39.0) and Chrome (43.0.2357.134 m). This is caused by a mix of overflow:hidden and the internal element alignment (there's a 1px gap between the top of the outer span and the img). I found the following work in fixing height:

*[[File:Elaborate Ritualist Bag.png|20px]] [[Elaborate Ritualist Bag]] (no wrapper)
*<span class="small item-icon thumb-icon" style="display:inline-block;overflow:hidden;width:20px;height:20px;vertical-align:middle;">[[File:Elaborate Ritualist Bag.png|20x20px|link=Elaborate Ritualist Bag|bottom]]</span> [[Elaborate Ritualist Bag]] (img bottom)
*<span class="small item-icon thumb-icon" style="display:inline-block;width:20px;height:20px;vertical-align:middle;">[[File:Elaborate Ritualist Bag.png|20x20px|link=Elaborate Ritualist Bag]]</span> [[Elaborate Ritualist Bag]] (no overflow, img middle)
*<span class="small item-icon thumb-icon" style="display:inline-block;width:20px;height:20px;vertical-align:middle;">[[File:Elaborate Ritualist Bag.png|20x20px|link=Elaborate Ritualist Bag|bottom]]</span> [[Elaborate Ritualist Bag]] (no overflow, img bottom)

•  Elaborate Ritualist Bag (no wrapper)
•  Elaborate Ritualist Bag (img bottom)
•  Elaborate Ritualist Bag (no overflow, img middle)
•  Elaborate Ritualist Bag (no overflow, img bottom)

That one missing pixel height keeps bothering me otherwise. --BryghtShadow (talk) 18:01, 16 July 2015 (UTC)

Are you talking about that 1px line of white between the stacked icons? That's because the height of the li element is 21px. —Dr Ishmael 18:52, 16 July 2015 (UTC)

No no, if you check the displayed dimensions of the icons above, they're all 20x20px, because of the annotated changes to the styles. If you check the dimension of the current item icon, it's 20x19px. To demonstrate (because it's height related), putting the current icon beside the above fixes makes the missing pixel more obvious:
 Elaborate Ritualist Bag
(icons are: 1. "current", 2. "no wrapper", 3. "img bottom", 4. "no overflow img middle", and 5. "no overflow img bottom")
--BryghtShadow (talk) 19:54, 16 July 2015 (UTC)

Buggy in Google Chrome

After following up with Doodle on why she made this edit, we discovered that this template breaks bullet lists when viewed in Google Chrome. It looks fine in Internet Explorer, though.

• Mystic Coin
  • This bullet should appear broken on Chrome.

I don't have Chrome so I can't bug fix atm. --Idris (talk) 05:51, 27 October 2017 (UTC)

Chrome sees the "display:inline-block;" bit of the div in item icon, and moves the bullet from the first line down onto the second line. Adding any character before it seems to fix it. I propose using & thinsp; and a -1pt negative margin. -Chieftain Alex 06:41, 27 October 2017 (UTC)

I can't comment if that's fixed the Chrome bug, but it continues to look fine in IE. Thanks for taking a look at this! --Idris (talk) 06:57, 27 October 2017 (UTC)

Looks good in Chrome now. - Do_odleplex 07:01, 27 October 2017 (UTC)

Empty query results

Motivation

Motivated by this edit, where previously this template was called with the disambig page instead the actual item page, I was asked if it is possible to set the Category:Pages with empty semantic mediawiki query results if no game icon is returned (as we already do for item acquisition templates) to avoid such cases.

Estimated affected pages

A #dpl check gave the following results:

• ~29500 pages are calling this template directly (note there are several other templates that call this template, those aren't counted in here)
• ~92000 pages are set as unnamed parameter 1
• ~18500 unique pages are set as unnamed parameter 1
• 69 unique pages, which are set as unnamed parameter 1, are disambig pages
• 34 unique pages, which are set as unnamed parameter 1, are disambig pages without an icon set (at least 5 pages somehow got stuck and wasn't setting the property correctly, fixed now)
• ??? pages are actually item icon with the parameter 1 being set to one of these 34 disambig pages (tedious job going through WhatLinksHere)

Problems

There are two major differences between this template and an item acquistion template:

• While in the item acquisition templates the default case is purely cosmetical, here the normal query result as well as the default result are used again in the file call. Hence, simply adding a category will interfere and break the file call.
• While the item acquition templates are called only once, this template may be called hundred times. Therefore, any unnecessary check, as in theory checking for empty query results should always be empty, is fatal and should be avoided.

Suggestion

Since I'm not aware of any method to set a category silently, e.g. {{#vardefine:Skill.png[[Category:<category>]]}}[[File:{{#var:icon}}]] (simplified!) will not be parsed, I suggest to use the silent property declaration #set.

The code then would look like the following:

<!-- Currently used code -->
[..]
{{#vardefine:itemicon_smw_icon|{{#show:{{#var:itemicon_item_page}}|?Has game icon|link=none|default=File:Skill.png}}}}
[..]
[[{{#if:{{{icon|}}} | File:{{{icon}}} | {{#var:itemicon_smw_icon}} }}|bottom|link={{#var:itemicon_item_page}}]]
[..]

<!-- Suggested code -->
[..]
{{#vardefine:itemicon_smw_icon|{{#if:{{{icon|}}} | File:{{{icon}}} | {{#show:{{#var:itemicon_item_page}}|?Has game icon|link=none|default=File:Skill.png{{#set:<property>=<text>}}}}}}
[..]
[[{{#var:itemicon_smw_icon}}|bottom|link={{#var:itemicon_item_page}}]]
[..]

Advantages

This would allow us to track incorrect item icon usage, e.g. using disambig pages instead of correctly using item pages or calling this template with nonexisting pages. Furthermore, it could be also used in the following templates: skill icon, trait icon, effect icon, and item acquisition templates.

A property can store more information than the Category:Pages with empty semantic mediawiki query results does, which only shows the page where something is wrong. The property, e.g. text property Has empty query result, can store the template, the property and the parameter, allowing to identify the potential problem easier and faster. For example, the property may bes et to the following text:

The query showing the property <code>[[Property:Has game icon|Has game icon]]</code> of the page [[{{{1|}}}]], called by the template [[Template:Item icon|Item icon]], returns an empty result.
The query asking for the property <code>[[Property:Contains item|Contains item]]::{{{1|}}}</code>, called by the template [[Template:Contained in|Contained in]], returns an empty result.

Potential disadvantages

• This might be an overkill.
• Does the smw query always execute the default case no matter if there are results or not? If yes, then we skip this immediately. If no, i.e. the default case will only be executed/parsed when there are no results found, then it might be worth a try.

Any thoughts? --Tolkyria (talk) 15:44, 23 June 2020 (UTC)

Late reply, sorry. As I am the one who brought this up, I would really like to see this implemented. I can not speak for the technical implementation but I can give a little insight why it would be useful. As of late I am editing a lot of achievement category pages (editing the achievements and creating collection items) and by that some errors appear in Category:Pages with empty semantic mediawiki query results which can then easily be found and fixed with a little effort. But for example linked disambiguation pages cant be found that way. With the new property Has empty query result implemented it would be possible to know exactly what needs fixing and the functionality would be expandable to other types of templates. —Kvothe (talk) 11:37, 26 June 2020 (UTC)

Sounds like a good idea to me. --BuffsEverywhere (talk) 01:05, 4 July 2020 (UTC)

Sorry, currently I can't see any way to implement my suggestion; it seems that the default case is always getting parsed/executed, no matter if a result is returned or the query is empty. --Tolkyria (talk) 12:57, 7 July 2020 (UTC)

Edit: To be precise, it's possible if we set the default case (Skill.png) externally, for example by using an additional #if.

E.g. {{#if: {{#vardefineecho:itemicon_smw_icon|{{#show:<query>|default=<!--empty-->}}||{{#vardefine:itemicon_smw_icon|File:Skill.png}}<!-- set here whatever we want -->}}.

But then, as described above, we are checking for nonexisting files while in theory this is never the case. However in practice we need this concept to reach this theoretical state. (Edit: 15:54, 7 July 2020 (UTC))