Module talk:InfoboxImage

Module:InfoboxImage is indefinitely protected from editing as it is a heavily used or highly visible module. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit protected}} to notify an administrator to make the requested edit.

This is the talk page for discussing improvements to the InfoboxImage module.

Add new text under old text. New to Wikipedia? Welcome! Learn to edit; get help. Start a new topic Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: 1, 2, 3, 4Auto-archiving period: 12 months

Archives

Archive 1 Archive 2 Archive 3 Archive 4

This page has archives. Topics inactive for 365 days are automatically archived 1 or more at a time by Lowercase sigmabot III if there are more than 4.

With the current implementation of this module, the upright parameter is ignored if the maxsize or sizedefault parameters are defined. This appears to be because image syntax ignores upright if a size in pixels is defined. It means that if either of those parameters are used in an infobox template (see {{Infobox bridge}} for example), then it's not possible to use the upright parameter at all in articles, which is not the intended behavior.

I don't have the Lua skills to do so, but I think the module should be rewritten so that a pixel size is not passed if the upright parameter is used and the size parameter is not. Pi.1415926535 (talk) 03:27, 30 May 2025 (UTC)Reply

I think there are two separate cases to consider:

1. Both |upright= and either |maxsize= or |sizedefault= are specified
2. Both |upright= and |size= are specified

In the first case, I think the current module behavior is likely incorrect -- the caller specified a size via |upright= and it's being handled as if no size was specified. The second case is less clear, because conflicting sizes are being provided. I'm reluctant to change the current behavior for the second case, because there may be unintended consequences to the 5M articles that use this module.

Of course, fixing the incorrect behavior also may have unintended consequences, also, so we should be careful. For example, the proposed behavior now allows people to set absurd values to |upright= and there is no check or limit.

I've modified the sandbox to fix the first issue, and updated the tests to exercise the new code. Pinging @WOSlinker to see if they have any comments on the change: other editors are also welcome to comment. — hike395 (talk) 09:17, 30 May 2025 (UTC)Reply

Later: I added some logic to ensure that |upright= doesn't produce an image larger than |maxsize=, assuming the default user preference. This fixes one potential issue. Updated sandbox and testcases. I'm hoping some other templateeditor or admin takes a look at the diff. — hike395 (talk) 10:01, 30 May 2025 (UTC)Reply

@Hike395: Thanks for looking into this! Just to clarify - will this still allow an image scaled with upright to be larger than maxsize if the user preference is set to a larger-than-default value? That seems important for accessibility reasons. Pi.1415926535 (talk) 16:09, 30 May 2025 (UTC)Reply

Yes: if upright is specified, then maxsize will scale with the user's default image size. So if maxsize=300, and the user's preferred thumbnail size is set to 300px, then the output image will be limited to be less than 300*300/220 = 409px for that user. There's no way to avoid this. — hike395 (talk) 00:39, 31 May 2025 (UTC)Reply

Great, that is the behavior I believe it should have. Pi.1415926535 (talk) 00:45, 31 May 2025 (UTC)Reply

To the original observation the upright parameter is ignored if the maxsize or sizedefault parameters are defined. This appears to be because image syntax ignores upright if a size in pixels is defined: this is expected behaviour, and is documented at WP:PICSIZE, inside the "Implementation details" box (direct link), last paragraph. --Redrose64 🌹 (talk) 13:39, 31 May 2025 (UTC)Reply

@Pi.1415926535 and Redrose64: Picking this back up. My sandbox edits do not contradict WP:PICSIZE. If a absolute size and an upright are both specified, then the absolute size is used. What I did was scale maxsize and sizedefault relative to the user preferred image size. Those two parameters are only defined in this module: WP:PICSIZE does not discuss them.

Is it ok to promote the sandbox to main? I see that since this edit, Pi.14 has removed maxsize and sizedefault from a number of infoboxes. It would be good to restore those, if I can promote sandbox to main. — hike395 (talk) 08:48, 5 August 2025 (UTC)Reply

@Pi.1415926535 and Redrose64: Any comments or thoughts before I propose this as an edit? Pppery just fully protected this Module, so I can no longer edit it, so even a simple support/agree would be helpful. — hike395 (talk) 14:46, 12 August 2025 (UTC)Reply

To be clear, my full protection was completely unrelated to this dispute, which I didn't even know existed; if you look at my edits at the time I adjusted the protection level of hundreds of templates. * Pppery * _{it has begun...} 17:35, 12 August 2025 (UTC)Reply

If I'm understanding correctly what your edit does, I support it. I'm confused about your statement Pi.14 has removed maxsize and sizedefault from a number of infoboxes - to my knowledge, I haven't edited any infobox templates to remove these. Pi.1415926535 (talk) 05:12, 13 August 2025 (UTC)Reply

@Pppery: apologies. I didn't mean to imply causation here -- I just wanted to point out that I can no longer edit the template directly.

@Pi.1415926535: more apologies. I recall seeing edits to infoboxes which removed maxsize and sizedefault, but now I cannot find them to check who did them. — hike395 (talk) 12:33, 13 August 2025 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please copy Module:InfoboxImage/sandbox to Module:InfoboxImage

This is a change in handling the case where |upright= and either |maxsize= or |sizedefault= is specified. In this case, the sandbox version obeys |upright=, but if it exceeds maxsize/220, then it is set to maxsize/220. The current behavior is to ignore |upright= when either |maxsize= or |sizedefault= is specified, which is incorrect.

This edit does not change any behavior if |upright= is not specified. Also, if |size= and |upright= are both specified, the behavior remains unchanged: |size= is obeyed in that case.

Are you sure that this description is correct? On the testcases page, I am seeing the Mustela image with

upright=1.5|sizedefault=272|maxsize=300

. The live module renders the image at 1.5x my thumbnail size. The sandbox image is rendered at 272px. This seems to be the opposite of the description above, if I am reading it correctly. It also seems to be a fix that helps the module to match normal image rendering (px is preferred over upright). Is this what you want? – Jonesey95 (talk) 17:01, 15 August 2025 (UTC)Reply

You may be interpreting the unit tests backward? Here are the results when main and sandbox are called with the case that you are highlighting:

{{subst:#invoke:InfoboxImage|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|sizedefault=272|maxsize=300}} →

{{subst:#invoke:InfoboxImage/sandbox|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|sizedefault=272|maxsize=300}} →

Here, the main module is generating a pic with size=272px, while the sandbox module is generating a pic with upright=1 (rendered at your preferred size). So the logic is correct.

The logic has not changed when both size and upright are specified. They are both emitted and MediaWiki prefers size over upright:

{{subst:#invoke:InfoboxImage|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|size=200}} →

{{subst:#invoke:InfoboxImage/sandbox|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|size=200}} →

— hike395 (talk) 17:18, 15 August 2025 (UTC)Reply

Indeed, I do not understand what "Expected" and "Actual" refer to on that page. I'm used to seeing the live template followed by the sandbox, with appropriate headers to match. In that case, and based on the apparent consensus above, I have no objections. It looks like this change will require an administrator, which I am not. – Jonesey95 (talk) 17:25, 15 August 2025 (UTC)Reply

@Redrose64: Do you object to this request? * Pppery * _{it has begun...} 19:48, 15 August 2025 (UTC)Reply

I'm not a Lua expert, and have never claimed to be. --Redrose64 🌹 (talk) 22:18, 16 August 2025 (UTC)Reply

 Done * Pppery * _{it has begun...} 04:35, 17 August 2025 (UTC)Reply

I’ve recently been coming across a lot of Infoboxes with substatially large images in their infoboxes. 300-400px in size. Can we modify this module to default to a maxsize of 250px? If for some reason a particular infobox wants to override that, that’s another matter, but that way we can at least cut down on the number of large images? If there is no objection to this change, I’m happy to write the code in the sandbox and do a formal edit request. Zackmann (^{Talk to me}/_{What I been doing}) 07:37, 30 September 2025 (UTC)Reply

A few comments:

1. I would be extremely cautious about setting defaults in this template. It's used on 5M pages and in system messages. The probability of unintended consequences is high.
2. Looking at the usage of |sizedefault=, I see many templates use |sizedefault=frameless. With the current code, such a default will ignore maxsize.
3. Looking at the usage of |maxsize=, many templates set maxsize larger than 250px. The largest ones appear to be 325px. To be conservative, the default maxsize should set to a high value (e.g., 325px). I think, however, it would be safer not to have a default maxsize.

— hike395 (talk) 10:11, 30 September 2025 (UTC)Reply

We should not standardize on a pixel size, per MOS:IMGSIZE (Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified, because it ignores the user's base width setting.). See the discussion above, which proposes to somehow default to the viewer's preferred thumbnail size, and the 2022 discussion that led to the one above. – Jonesey95 (talk) 10:44, 30 September 2025 (UTC)Reply

Per this recent edit, setting |maxsize= does not standardize on a pixel size. If we do set |maxsize=250, then it limits |size= to 250 and limits |upright= to 1.136. px is not forced or favored in any way.

Also -- I just cleaned up all uses of |sizedefault=frameless, so that is no longer a factor in any decision. — hike395 (talk) 13:52, 30 September 2025 (UTC)Reply

Thanks for both of those. Based on the above discussion, which I had forgotten about because I got so mixed up, it looks like the sizedefault of frameless will override the maxsize as long as size= is not specified. I tested sizedefault=frameless|maxsize=250 in my sandbox and got a 300px image, which is the same as my thumbnail preference. If I set sizedefault=frameless|maxsize=250|size=100, I get a 100px image. Based on that, it looks like a sizedefault maxsize of 250px would prevent images from getting larger than the editor's preferred thumb size unless size= is specifically set. Caveat: I might not be testing all possible cases. – Jonesey95 (talk) 14:12, 30 September 2025 (UTC)Reply

To clarify: the behavior with |sizedefault=frameless is a bug. Maybe I should fix the bug rather than cleaning up occurrences of |sizedefault=frameless, although fixing the bug would add 3 lines of special-purpose code for that case.

To see the correct behavior, if you try maxsize=250 you should get 250px, if you try upright=1|maxsize=250 you should get 300px, while if you try upright=1.5|maxsize=250 you should get 340px (limited by maxsize). — hike395 (talk) 14:44, 30 September 2025 (UTC)Reply

Yeah, now I'm confused again.

• When I set maxsize=250, I get 250px (my thumb size is 300px, and I thought sizedefault=frameless was being set by default, so I was expecting 300px).
• When I set |upright=1|maxsize=200, I get 270px (about 137% of maxsize, so it doesn't match maxsize or the upright setting).
• When I set |upright=1|maxsize=250, I get 300px (my thumb size preference; this seems correct).
• When I set |upright=1|maxsize=300, I get 300px (my thumb size preference; this seems correct).
• When I set |upright=1.5|maxsize=300, I get 412px (about 137% of maxsize and my thumb size, so it doesn't match maxsize or the upright setting).

The code I am using in a Preview window in my sandbox looks like {{subst:#invoke:InfoboxImage|InfoboxImage|image=Mustela erminea upright.jpg |upright=1|maxsize=300}}. Somebody please explain it to me like I'm not very smart. – Jonesey95 (talk) 16:22, 30 September 2025 (UTC)Reply

The maxsize parameter is to limit the value of the size parameter. Normally in an infobox template you would have image = {{subst:#invoke:InfoboxImage|InfoboxImage|image={{{image|}}}|size={{{image_size}}}|maxsize=300}} and then when used on an article with {{Infobox something|image=abc.jpg|image_size=500}}, the image size would be limited to 300. -- WOSlinker (talk) 18:26, 30 September 2025 (UTC)Reply

To understand the behavior, see the discussion above. The maximum size (in px) for InfoboxImage when upright is specified is (maxsize/220)*(your thumbnail preference).

When you set maxsize=200, you are saying that the max upright is 200/220 = 0.909, which is 272px.

When you set maxsize=250, you are saying that the max upright is 250/220 = 1.136, which is 341px. Upright=1 thus gives 300px for you.

When you set maxsize=300, you are saying that the max upright is 300/220 = 1.364, which is 409px for you. Upright=1 thus gives 300px, but upright=1.5 gets limited to 1.364 which is 409px.

The 220 comes from the default user thumbnail size. Hope this helps. — hike395 (talk) 22:37, 30 September 2025 (UTC)Reply

Here is an example of what a default maxsize would help prevent… - Zackmann (^{Talk to me}/_{What I been doing}) 01:06, 1 October 2025 (UTC)Reply

@Zackmann08: sorry for the bad news, but that article uses {{Infobox royalty}} that already has |maxsize=300. Adding a default maxsize would do anything in this case. What this module produces with that input is [[File:Olu Atuwatse I Dom Domingos.jpg|300x|upright=1]]. The "300x" is a syntax error, so the Wiki image markup just displays the image at full resolution (which is 5286x4119px).

We could attempt to harden the output of the module so that junk doesn't "leak through". This is separate from maxsize. — hike395 (talk) 02:46, 1 October 2025 (UTC)Reply

@Hike395: I added the |maxsize=300 here as a result of finding that page. But good to know that maxsize wouldn’t have prevented it. — Zackmann (^{Talk to me}/_{What I been doing}) 02:49, 1 October 2025 (UTC)Reply

Continuing from Template talk:Infobox settlement#Max size :) My Special:Preferences#mw-prefsection-rendering-files says 250px, and I don't remember having changed this myself.

So the use of 220 in this module needs to be abstracted away into some sort of a variable, because it looks like this isn't making a lot of sense otherwise. --Joy (talk) 10:18, 17 October 2025 (UTC)Reply

And if Wikipedia:Image use policy#Displayed image size tells editors Except with very good reason, do not use px [...], which forces a fixed image width measured in pixels, disregarding the user's image size preference setting., then this module should also support relative sizes as well, instead of forcing this sort of pixel-based thinking from editors. --Joy (talk) 10:20, 17 October 2025 (UTC)Reply

The default thumbnail size used to be 220px but changed to 250px in April 2025. See Wikipedia:Tech_news/Archive_13#Tech_News:_2025-16. -- WOSlinker (talk) 17:59, 17 October 2025 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please copy the sandbox to main.

Two changes:

1. (technical) --- factored out list of placeholder images and tracking categories into Module:InfoboxImage/data to neaten beginning of module
2. (substantive) --- per discussion above, the systemwide default thumbnail size is now 250px. Factored this value out of existing code and turned it into constant at beginning of module. This introduces two expected "errors" into the test cases.

Pinging @WOSlinker who brought this up. — hike395 (talk) 02:28, 18 October 2025 (UTC)Reply

 Done -- WOSlinker (talk) 09:46, 18 October 2025 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please change the profile photo to the following image https://commons.wikimedia.org/wiki/File:Walter_Masterson.jpg Wikispiraling (talk) 23:54, 24 November 2025 (UTC)Reply

@Wikispiraling: This page is for discussions concerning use and development of the module Module:InfoboxImage. I can only assume that you are intending to ask for the image you have mentioned to be put in the article Walter Masterson; if so the request belongs in the talk page of whatever article that is, not here. JBW (talk) 00:04, 25 November 2025 (UTC)Reply

 You are invited to join the discussion at Template talk:MergedMap. -- Joy (talk) 12:48, 27 November 2025 (UTC)Reply

Is there a reliable way to get captions from wikidata? I don't think this module deals with captions at all, which is surprising. We have an issue on Template:Infobox martial artist where the caption is not always matching the image. This module was using the preferred image but Module:Wikidata was taking the caption from a different image — Martin (MSGJ · talk) 09:23, 6 January 2026 (UTC)Reply

That infobox is checking the image and caption params independently.

{{if empty|{{{image|}}}|{{#invoke:Wikidata|claim|P18}}}}
{{if empty|{{{caption|}}}|{{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}}}

Maybe needs to check both params are empty before using any wikidata values?

{{#ifeq:{{{image|}}}{{{caption|}}}||{{#invoke:Wikidata|claim|P18}}|{{{image|}}}}}
{{#ifeq:{{{image|}}}{{{caption|}}}||{{#invoke:Wikidata|getImageLegend|FETCH_WIKIDATA}}|{{{caption|}}}}}

WOSlinker (talk) 10:04, 6 January 2026 (UTC)Reply

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please remove the images.it is misleading it's not real.thanks Abidthegreat (talk) 07:28, 26 March 2026 (UTC)Reply

This is the wrong place for this request. I would suggest that you start a conversation at Talk:Malik ibn Anas. -MPGuy2824 (talk) 10:58, 26 March 2026 (UTC)Reply

I would like to propose a comprehensive update to Module:InfoboxImage and its data submodule Module:InfoboxImage/data. The goal is to improve performance (especially on long articles with multiple infoboxes), fix a silent bug regarding alt text validation, and structure the data layer according to Lua best practices in MediaWiki.

I have prepared and tested the updated code in the local sandboxes. Here is a breakdown of the key improvements:

• File Namespace Caching (Performance): The current production code queries and rebuilds the file namespace aliases table via `mw.site.namespaces[6]` twice on every single invocation (once inside `IsPlaceholder` and again in the main function body). On long pages or transclusions, this creates unnecessary overhead. The proposed version builds this namespace cache list exactly once at the top-level scope during the initial module load.
• Redundant Code & Asserts Cleanup: Removed several `assert(image ~= nil)` checks right after `mw.ustring.gsub`. In the Scribunto environment, these standard string operations never return `nil` when provided with valid string inputs, meaning these assertions were purely redundant and polluting the code logic.
• Namespace Stripping Helper: Unified the file prefix stripping logic into a streamlined internal helper function `stripNamespace`, reducing code duplication between functions.

• In the current live module, the validation that prevents reserved keywords (like `thumbnail`, `thumb`, `center`, etc.) from being used as description text is executed on line 164 (`alt = nil`).
• However, the variable `alt` has already been appended to the `result` string on line 147. This means the keyword-filtering mechanism was completely bypassed and **silently failing**.
• The sandbox version corrects this by evaluating and filtering the `alt` string before it is appended to the final output link structure.

• Native O(1) Hash Table Lookup: The current live `/data` module stores placeholders as a sequential array list and runs a `for` loop at runtime to reconstruct a key-value hash map. This completely negates the performance caching benefits of `mw.loadData`. The new version stores the data directly as a lookup table (`["Filename.svg"] = true`), allowing instantaneous $O(1)$ lookups natively without execution loops.
• De-duplication: Removed several duplicate filenames present in the legacy list (e.g., `CarersLogo.gif`, `Diagram Needed.svg`, `No male portrait.svg`, etc.).
• Decoupled Tracking Categories: The main module now fully relies on the tracking categories strings directly passed by `mw.loadData`, decoupling infrastructure names from the logical parser engine.

The sandboxes have been cross-verified against multiple test cases (bare filenames, fully formatted `File:...` links, raw URLs, templates, and strip markers). The output markup is identical to the current production version, but executes with significantly less processing overhead.

Please let me know if there are any objections or feedback before I submit an official Edit Request. Thanks!

GKNishimoto (talk) 13:39, 4 June 2026 (UTC)Reply

A couple of things to note:

• mw.loadData already caches the data load once per module load (see [1]), so there's no need for the new code at sandbox lines 23-26.
• Remember that Lua parsing/interpreting time is significant. Thus when you have a long list of data (as in Module:InfoboxImage/data), it's innately O(n), because the parser has to touch every element anyway.

Because of these, my preference is to perform mw.loadData locally within each function. This performs lazy evaluation of loadData -- it's not loaded until its needed. For this module, the lazy load occurs 100% of the time, so it isn't critical at this time. But if someone changes the code in the future, lazy loading could be helpful. If you always load the module at lines 23-26, then you'll always incur the Lua parsing overhead for the data.

The conversion of Module:InfoboxImage/data to use a hash table directly is nice, although won't help performance. Because the time is dominated by Lua parsing, the conversion of the list to a hash (which only happens once one module load) will not be noticable.

Also: please don't remove comments from the code. They're helpful for future developers.

— hike395 (talk) 15:08, 4 June 2026 (UTC)Reply

Thank you for the excellent feedback, hike395. You make a very sharp point regarding the Scribunto environment mechanics and the overhead of Lua parsing time versus execution loops. I have fully updated the sandboxes to incorporate your suggestions, balancing the structural improvements with the engine's best practices:

• Lazy Loading Implemented: I removed the module-level eager loading of the data submodule. The call to mw.loadData('Module:InfoboxImage/data/sandbox') has been moved locally inside trackingCat and i.IsPlaceholder. This ensures that the data layer is only processed when actually needed, preventing unnecessary overhead if the module's scope changes in the future.
• Comments and Assertions Restored: All documentation comments and essential logical descriptions have been added back to ensure readability and maintainability for future developers.
• Hash Table & Bug Fix Retained: The data submodule structure remains as a direct lookup hash table (which, as you noted, provides a cleaner and more native design even if parsing time dominates), and the critical fix for the bypassed alt-text validation keyword filter is intact.

The Module:InfoboxImage/sandbox and Module:InfoboxImage/data/sandbox are now fully aligned with both performance optimization and proper lazy-evaluation architecture. If there are no further objections, I will proceed with the official Edit Request. Thanks again for the review! --GKNishimoto (talk) 16:57, 4 June 2026 (UTC)Reply

Hello. How can I display a logo in an infobox with its original dimensions? For example this: File:2027 FIBA Women's AmeriCup logo.webp
This is a quite small logo, so I don't want to upscale it to the default 250px. I tried something: |size=x270px but that's completely wrong...
Thank you for your ideas. Maiō T. (talk) 21:42, 15 June 2026 (UTC)Reply

@Maiō T.: It depends upon the specific infobox. Which article is it? --Redrose64 🌹 (talk) 22:35, 15 June 2026 (UTC)Reply

@Redrose64: It's 2027 FIBA Women's AmeriCup.

It would be great if a parameter like this could be used: |size=auto or something similar... Maiō T. (talk) 09:30, 16 June 2026 (UTC)Reply

@Maiō T.: For {{Infobox international basketball competition}}, the |size= parameter (which is an alias for |image_size=) must be an integer; values containing units, such as |size=x270px, are ignored. Since the native size of File:2027 FIBA Women's AmeriCup logo.webp is 177 × 270 pixels, and you want it 270px high, simply set |size=177. --Redrose64 🌹 (talk) 12:09, 16 June 2026 (UTC) --Redrose64 🌹 (talk) 12:09, 16 June 2026 (UTC)Reply

Okay. But that's a little inconvenient. It might be a good idea to add the following line to the module: if nativesize<250 then infoboxsize=nativesize otherwise infoboxsize=250 or something (translated into module language). Maiō T. (talk) 17:35, 16 June 2026 (UTC)Reply

How is |size=177 more inconvenient than |size=x270px? --Redrose64 🌹 (talk) 21:33, 16 June 2026 (UTC)Reply

Sorry, I expressed myself a little imprecisely. 😉 |size=177 is inconvenient, because I have to find this exact non-round number on the page of that specific image. Actually, |size=x270px was inconvenient too. My idea is to not write the size number at all. Maiō T. (talk) 22:10, 16 June 2026 (UTC)Reply

@Redrose64: Wow!!! I tried using a completely crazy parameter |size=orig, and it works! The logo is displayed in its native size... Did you personally make any changes to the module? Maiō T. (talk) 19:12, 12 July 2026 (UTC)Reply

No, I didn't because I don't accept that any change is necessary. By altering |size=x270px to |size=orig, all you have done is exchange one invalid value for another. As I noted above, this parameter is documented as accepting an integer and nothing else is valid. Why did you not simply set |size=177 as you were advised? --Redrose64 🌹 (talk) 19:19, 12 July 2026 (UTC)Reply

@Redrose64: Sorry, but it's not a very good idea to write a different ugly non-round number in every infobox. Now it's almost perfect. I simply enter an invalid parameter value and the result will be a nice, unblurred logo in its original size. By the way, this wasn't possible a few days ago; when I entered an invalid value back then, the logo was displayed with the default width of 250px. Someone must have made some kind of change to the module... Maiō T. (talk) 08:32, 13 July 2026 (UTC)Reply

Module:InfoboxImage has not been altered in the last nine months. Of the various templates and modules used by Template:Infobox international basketball competition, only two have been edited since you first opened this thread:

• Module:Check for unknown parameters (history) - changes for pushpin maps
• Template:Infobox international basketball competition (history) - display the word "City" as "Cities" when appropriate

Neither of these changes can possibly have affected the display of the image. Please note, you should not depend upon undocumented behaviour of invalid parameter values, these might change at any time. --Redrose64 🌹 (talk) 17:25, 13 July 2026 (UTC)Reply

Standard WP image syntax will not enlarge an image if it has a caption (see WP:PICSIZE). The code at {{Infobox international basketball competition}} had some silly defaults that did nothing except break this feature. I fixed the Infobox code and added a caption at 2027 FIBA Women's AmeriCup, and behold: the image now displays at its original size. — hike395 (talk) 01:32, 14 July 2026 (UTC)Reply

Wow Hike, this is cool !!! I tried removing the "caption" parameter and it still works perfectly... Thank you very much. I think this topic could be closed. Maiō T. (talk) 11:22, 14 July 2026 (UTC)Reply

Hike, could you add the "upright" option to the following template as well? - Template:Infobox tournament season - Thanks. Maiō T. (talk) 20:28, 14 July 2026 (UTC)Reply

 Done — hike395 (talk) 01:43, 15 July 2026 (UTC)Reply