Module talk:InfoboxImage

Category:Pages using deprecated image syntax nominated for deletion
Please see this CfD discussion about. – Jonesey95 (talk) 01:38, 7 October 2020 (UTC)

Broken parameter in frameless mode if it includes CSS
If the  parameter includes CSS (e.g., via the   template), then it displays the plain-text CSS rules into the map tooltip and the image description in the image popup (i.e., the Lightbox-style image mode that pops up after clicking on the image). This is strange considering invoking the image using the  syntax directly (in the default mode) doesn't seem to have this issue, but using it in the   mode does:











―Getsnoopy (talk) 20:23, 26 December 2020 (UTC)


 * does not have a caption. See Extended image syntax. The parameter is used for the link title instead. A link title is displayed as plain text. Module:InfoboxImage could examine  and omit using it as link title if it doesn't look like plain text. A tracking category could be added instead. PrimeHunter (talk) 11:41, 13 March 2021 (UTC)
 * I've update the code to not use the title param if it contains templatestyles. -- WOSlinker (talk) 15:52, 13 March 2021 (UTC)

Template-protected edit request on 8 June 2021
I would like to have Judge Rose's photo on her Wikipedia profile page updated. I'm passing this request along from Judge Rose herself. I have an updated photo from her that I can send to you but wanted to confirm that I'm in the right place to request this change. 8thcirc (talk) 19:04, 8 June 2021 (UTC)
 * Red information icon with gradient background.svg Not done: this is the talk page for discussing improvements to the page Module:InfoboxImage. If possible, please make your request at the talk page for the article concerned. If you cannot edit the article's talk page, you can instead make your request at Requests for page protection.  P.I. Ellsworth   ed.  put'r there 22:55, 8 June 2021 (UTC)

none options for link and alt
We should probably add none options for link and alt. It would be useful in places such as archives but likely other non-infobox templates using this as well since this is the most versetile image handling template. --Trialpears (talk) 15:14, 11 August 2021 (UTC)
 * Seems like a good idea. -- WOSlinker (talk) 21:10, 11 August 2021 (UTC)

Module breaks when there are multiple images on Wikidata
In a recent edit the Module broke because there were three different images set on Wikidata, and the Module tried interpreting them as one, which doesn't work. Is there a way to recognize this and use them all separately? -- Asartea   Talk  &#124;  Contribs  15:49, 29 August 2021 (UTC)

Module update
I've done some work in the sandbox. The original intent was to add an error category for when URL links are used for images, as currently it just returns an empty string. While working on the code I've also cleaned up the code, including:
 * Consistent spaces
 * Consistent usage of quotation marks
 * Using table.param instead of table["param"]
 * Reordering the placeholder_image table alphabatically
 * Removing ";" from the end of lines as Lua does not use that.

I've replaced the following block of code at Module:InfoboxImage:

with Module:InfoboxImage/sandbox:

I've added URL testcases to Module:InfoboxImage/testcases. The new tests and all previous tests pass Module talk:InfoboxImage/testcases.

Please let me know if you have comments or questions. Gonnym (talk) 09:04, 2 October 2021 (UTC)
 * There are [//commons.wikimedia.org/wiki/Special:AllPages?from=http&to=&namespace=6 quite a few] images at commons whose names begin with the letters "http". Will this code drop them into the error category? Perhaps "^%[*https?:" would be safer, if that's the correct regex syntax for string.find -- John of Reading (talk) 09:21, 2 October 2021 (UTC)
 * I've added a test for an image from commons that starts with HTTP and it worked. That said I've also now updated the sandbox with your suggested code to make it more correct. Gonnym (talk) 09:35, 2 October 2021 (UTC)

Why is "alt" the fallback for "title"?
In this condition alt is used as the fallback for an image title when title is not present. This appears arbitrary to me and it diverges from the usual behavior of alt in constructs. As a result, articles that use InfoboxImage and alt (but not title) for each image suddenly have a title on the infobox image, but none on all others. Is there a reason that this is the case? Can this behavior be corrected (by removing lines 271 and 272)? IceWelder &#91; &#9993; &#93; 07:38, 26 October 2021 (UTC)
 * Not sure whether anyone is even watching this talk page. You're the most active editor on the module. Would you mind sharing your insight?  IceWelder  &#91; &#9993; &#93; 17:22, 27 October 2021 (UTC)
 * It was just done that way so that the hover over tooltip showed some information. If there are no objections in the next week then I'll remove it. -- WOSlinker (talk) 18:29, 27 October 2021 (UTC)
 * I've updated it. -- WOSlinker (talk) 18:26, 5 November 2021 (UTC)
 * I made this corresponding doc update https://en.wikipedia.org/w/index.php?title=Module:InfoboxImage/doc&type=revision&diff=1065533441&oldid=1048551125&diffmode=source Note that lines 259-262 now seem redundant  Arlolra (talk) 01:58, 14 January 2022 (UTC)

Template-protected edit request on 8 March 2022
Please apply the changes made to the module in Module:InfoboxImage/sandbox, which adds the option for a "class" parameter that allows upper templates to set an HTML class for the infobox image (particularly the newly-introduced "notpageimage" class, which removes the image from the list of page images). Testcase of working usage of the parameter is shown at the right side (you may need to use the browser's element inspector to verify that the class exists). Chlod (say hi!) 09:47, 8 March 2022 (UTC)
 * ✅ -- WOSlinker (talk) 19:18, 13 March 2022 (UTC)
 * I think it would make more sense for this module to provide an API to add the class(es) of interest rather than to provide a class parameter that we'll have to chase the name down should the name ever change. (Or for any other reason.) Izno (talk) 03:25, 14 March 2022 (UTC)

Help with improving default image sizes
A few editors had a contentious but thoughtful discussion about default image sizes in infoboxes that fizzled out due to lack of technical expertise; see this discussion from July 2022. It looks like the next step was to post a request for help here. Basically, we thought that this module might be able to do a better job of providing images for infoboxes that followed editors' thumb size preferences so that we could move away from fixed pixel size specifications in infoboxes. If there is anyone here who is willing to look into how we might default to  (or whether the module already does this, and how to code infobox image calls properly), I would be grateful. – Jonesey95 (talk) 01:03, 10 January 2023 (UTC)

Ditto. On some other wikis you format the image inside the info box, and can just use 'upright' to size, but on WP-en it's too complicated for me to figure out. It would be nice if at e.g. the language infobox we could set the default to, say, upright=0.9, and editors could override with their own upright value if they chose.

Is it possible to set the infobox width to match the user's default image size, or would that be a bad idea? — kwami (talk) 01:45, 10 January 2023 (UTC)


 * Perhaps I am misunderstanding the discussion or request. There is already a parameter upright to this Module, which is passed along to the [[Image:XXX]] wikitext. If you want an infobox image to default to 114% of the size of a user's preference, why not just set 1.14 in the infobox code? What am I missing? — hike395 (talk) 03:51, 10 January 2023 (UTC)
 * In my case, that I don't know what I'm doing with this module! — kwami (talk) 03:53, 10 January 2023 (UTC)
 * Is there a specific infobox we can try to improve? Maybe that will make things clearer (or maybe there will an unanticipated problem and we'll learn from the attempt). — hike395 (talk) 03:55, 10 January 2023 (UTC)
 * Yes, thank you. Infobox language, which I could then extend to Infobox language family. — kwami (talk) 03:57, 10 January 2023 (UTC)
 * Is the idea to default to 0.9 (~200/220) ? Let's try it in the sandbox. — hike395 (talk) 03:58, 10 January 2023 (UTC)
 * Currently, 'image' is set to 90% and 'map' to 100%. — kwami (talk) 03:59, 10 January 2023 (UTC)
 * Looks like it worked, see Template:Infobox language/testcases. My default image size is 250px, and it clearly changed for me. It still allows fixed-size overriding, but the default will obey user preferences. Hopefully this will resolve the dispute that seemed to happen at Template talk:Infobox bridge/Archive 2?
 * I'll leave it to other editors to get consensus on this change, but it seems to work technically. — hike395 (talk) 04:07, 10 January 2023 (UTC)
 * Thanks!
 * Would it be possible to set it so that if we enter, say, 'mapsize' or 'imagesize=1.25', it will set it as upright=1.25, so we don't have to use px? — kwami (talk) 04:18, 10 January 2023 (UTC)
 * I guess we could check to see if the mapsize is <4, use it as upright? I worry that this will be confusing to editors. — hike395 (talk) 05:56, 10 January 2023 (UTC)

It looks like using upright will generally work, as shown at Template:Infobox bridge/testcases (set your thumbnail preference to 300px or higher to see the difference). Somewhere (I forget where, unfortunately), an editor chose to specify an infobox image size to match the pixel size of the mapframe map in the infobox. I don't see a way to apply upright to mapframe maps, so I posted a query at the relevant talk page. – Jonesey95 (talk) 05:04, 10 January 2023 (UTC)


 * Anything other than a number in mapsize gives the same output, ~ equivalent to entering 500. — kwami (talk) 06:25, 10 January 2023 (UTC)
 * I've changed the infobox, checking articles. No problems so far. — kwami (talk) 06:26, 10 January 2023 (UTC)
 * I don't see how |upright= has any effect on anything. — kwami (talk) 06:29, 10 January 2023 (UTC)
 * Have you tried changing your preference for thumbnail size away from 220px? — hike395 (talk) 07:09, 10 January 2023 (UTC)
 * No, but I would think that setting upright=2 would be visible regardless. — kwami (talk) 07:11, 10 January 2023 (UTC)
 * Oh, I bet I know what this is. This is a limitation in MediaWiki. If you start with a tiny image, it won't blow it up larger than its actual size. What's the example of upright not working? — hike395 (talk) 07:14, 10 January 2023 (UTC)
 * I see that at e.g. Malay language, where the map is an SVG but the nominal size is only 257×190px. And indeed, the English map has a nominal size of 512×260px, which is probably what I was getting when I set the size to anything but a number. But the map at Arabic language is nominally 1200px, and 'upright' has no effect there either (neither map nor image). — kwami (talk) 07:20, 10 January 2023 (UTC)
 * I'm a bit confused. File:Arabic albayancalligraphy.svg (the example image in the infobox) is 343px, so it won't get bigger than that. File:Arabic speaking world.svg is 1200px, but upright appears to work (see below). — hike395 (talk) 07:30, 10 January 2023 (UTC)
 * Yeah, looks fine here, but no effect in the infobox. I just saved a test edit on that page, in case the preview wasn't working: nothing. — kwami (talk) 07:37, 10 January 2023 (UTC)


 * I think there was a misunderstanding. I didn't implement upright in Infobox language: I just made the default have scalable thumbnails. In Template:Infobox language/sandbox I implemented imageupright and mapupright to work as you would think, see Template:Infobox language/testcases for the results. — hike395 (talk) 09:43, 10 January 2023 (UTC)


 * Ah, thank you. Yes, that works beautifully.
 * I changed the labels to 'imagescale' and 'mapscale', as there's been some confusion that 'upright' is only used will tall images. — kwami (talk) 10:39, 10 January 2023 (UTC)

Updated strip marker
According to mw:Strip marker, the code for strip markers has changed. You need to replicate this change in order to get that code to work again. Strainu (talk) 20:58, 20 November 2023 (UTC)
 * Implemented in the Module:InfoboxImage/sandbox, but none of the existing tests failed. What is this change supposed to accomplish? Is there a test case where the old code fails and the new one succeeds? — hike395 (talk) 01:15, 21 November 2023 (UTC)
 * Yes, the change is supposed to allow Multiple images to be used with InfoboxImage: see the infobox at ro:Târgoviște. From what I can see, Template:Multiple images has the same implementation as on rowiki, so it's very likely to fail with the old implementation. Strainu (talk) 08:11, 21 November 2023 (UTC)
 * Lines 178-180 already handle the updated format. It's just that lines 175-178 were not updated previously. -- WOSlinker (talk) 09:31, 21 November 2023 (UTC)
 * Is it safe to simply delete lines 175-177? — hike395 (talk) 12:32, 21 November 2023 (UTC)
 * Either would work, so I've applied the sandbox change and removed the other check. -- WOSlinker (talk) 13:27, 21 November 2023 (UTC)
 * Added a test case using Multiple images (although it was not failing previously). — hike395 (talk) 19:42, 21 November 2023 (UTC)

Explicit option to not add image
This module is sometimes called by an infobox which passes on an image parameter if it's given in the call and otherwise automatically passes on a Wikidata image. If an article explicitly wants no image then it can pick one of the suppressed image names like  in  which uses Infobox dam. That was hard to work out, later editors of the article may blank the bad looking image parameter in good faith, and I don't know whether the list of suppressed images is certain to never remove a listed image name. I suggest adding a clear and simple value  to not display any image. A blank  already does this but as mentioned, that doesn't work in some calls of infoboxes. I came here after working on Teahouse. PrimeHunter (talk) 12:09, 1 December 2023 (UTC)


 * Should all instances of a nested Infobox dam disable the image? If so, the fix is straightforward in that template. Gonnym (talk) 12:21, 1 December 2023 (UTC)

Tracking category for URLs in image field
Discussion: Template_talk:Infobox

There are probably thousands of URLs in the image field. Would it be possible to add a tracking category? They should be removed on a regular basis and tracking them would be a big help. -- Green  C  20:49, 19 July 2024 (UTC)


 * Just need to update lines 146, 149, 152, 155, 158 & 161 to return a category. What do you want to call the category? -- WOSlinker (talk) 21:33, 19 July 2024 (UTC)
 * Does infobox emit tracking categories anywhere else? Following CS1|2 naming, Category:CS1_errors:_archive-url, it might be Category:Infobox_errors:_image a holding cell for all errors related to this module. -- Green  C  23:31, 19 July 2024 (UTC)
 * It only emits Category:Pages using infoboxes with thumbnail images at the moment. -- WOSlinker (talk) 06:19, 20 July 2024 (UTC)
 * That's a standard error category format. I would suggest Category:Pages using infoboxes with URL in image field. — hike395 (talk) 12:03, 20 July 2024 (UTC)
 * Let's use the word "parameter" instead of "field", since that is the term here on Wikipedia, or just leave off the last word entirely: "Pages using infoboxes with URL in image". – Jonesey95 (talk) 13:52, 20 July 2024 (UTC)