Template talk:Infobox

From Embroidery Machine WIKI
Jump to navigation Jump to search

{{#ifeq:{{{bottom}}}|yes | {{#ifeq:|yes

|

{{#ifeq:{{#if:| {{{smallimage}}} | none }}|none | | }}

{{#if:{{#if: | {{{smallimageright}}} | }} | {{#ifeq:{{#if: | {{{smallimageright}}} | }}|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}}

|

{{#ifeq:none|none | | }}

{{#if: | {{#ifeq:|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}} }}{{#ifeq:Template talk|Template | {{#ifeq:Infobox|Infobox

 |   
   {{#ifeq:|true
   |   
   |
   }}
 }}

}} }}{{#ifexpr:{{#ifeq:Template talk|User talk|1|0}}*{{#ifeq:|yes|1|0}}| Template:Userpage }}

}}{{#if:|}} {{#if:yes||{{#ifexist:Template talk:Infobox/Archive 1| }} }} {{#if:{{#ifexist:Template talk:Infobox/Archive 1|y}}{{#ifexist:Template talk:Infobox/Archive A|y}}|{{#ifeq:|no|| }} }}
{{#ifeq:Template talk|User talk|This is Infobox's talk page, where you can send messages and comments to Infobox.|This is the talk page for discussing {{#if:|Infobox and anything related to its purposes and tasks|improvements to the {{#if:|{{{display_title}}}|Infobox}} {{#switch:
|Talk          = {{#switch:
 |disambiguation|disambig|disamb|dab
 |redirect|redir
 |na                  = page
 |#default            = article
}}
|User talk
|MediaWiki talk
|Help talk
|Template:Ns:TimedText talk
|Template:Ns:Module talk
|Template:Ns:Portal talk
|Embroidery Machine WIKI talk  = page
|Template:Ns:Book talk     = book
|File talk     = file
|Template talk = template
|Category talk = category
|#default             = {{#switch:
 |portal
 |project
 |disambig|disamb|dab
 |redirect|redir
 |na                  = page
 |book                = book
 |image|file          = file
 |template|temp|templ = template
 |category|cat|categ  = category
 |#default            = article
}}
}}}}.}}
{{#if:Template||*This is not a forum for general discussion of the article's subject.}} {{#switch:yes||{{#if:Template|no|yes}}=
Article policies
{{#if:| }}{{#if:| }}{{#if:| }}{{#if:| }}{{#if: | }}
Shortcut{{#if:|s}}: {{#if:|
  • [[]]
  • }}{{#if:|
  • [[]]
  • }}{{#if:|
  • [[]]
  • }}{{#if:|
  • [[]]
  • }}{{#if: |
  • [[ ]]
  • }}
{{#if:

| {{#ifexist:

 | 
 |
 }}
}}
Archives: {{#ifexist:Template talk:Infobox/Archive index|Index, }}{{#ifexist:Template talk:Infobox/Archive A|Template:Archive list alpha, |}}Template:Archive list

<inputbox> bgcolor=transparent type=fulltext prefix=Template talk:Infobox{{#switch:{{{noslash}}}|yes=|no=/|{{{noslash}}}=/}} break=no {{#ifeq:auto|auto|| width=auto }} searchbuttonlabel=Search archives </inputbox>

{{#ifeq:yes|no| | }}{{#if:MiszaBot II90 | }}{{#ifeq:{{{auto}}}-yes|no-yes |

}}

{{#if:

|

}}

More rows

This template has, apparently a limit of 80 rows, This, in turn, limits other templates, such as {{Infobox church}}, which therefore do not use this one. Can we add more rows, perhaps taking advantage of Lua? Is there any reason Lua could not allow us to code an effectively infinite number of rows? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 15 April 2013 (UTC)

the switch to lua is in development, see Module:Infobox. once this is completed, there should be no limit on the number of rows. Template:Infobox church could be switched right now using the method used by {{infobox power station}}. Frietjes (talk) 16:51, 15 April 2013 (UTC)
That's great; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:05, 15 April 2013 (UTC)
The limit hasn't been 80 rows for a long time. There have been 99 directly-usable rows since September last year (and the documentation has also shown 99 since 6 Sep 2012); and even before that, the "embedding" feature has permitted, in theory, an infinite number (subject to template expansion limits). --Redrose64 (talk) 17:11, 15 April 2013 (UTC)

Infobox subbox bodystyle

{{#invoke:Infobox|infobox}}

Is there any reason why we can't merge {{Infobox subbox bodystyle}} with this template? It looks like we would just need change

style="border-spacing: 3px; width:22em;

to

style="{{#ifeq:{{{subbox|}}}|yes
 |border-collapse:collapse; border:none; width:100%; margin:0px; font-size: 100%; clear:none; float:none;
 |border-spacing: 3px; width:22em;
 }}

It seems like this was the original intent from the discussion at WT:WikiProject Infoboxes. Some CSS experts may also be able to suggest some improvements? Thanks! Plastikspork ―Œ(talk) 23:13, 27 April 2013 (UTC)

Added some comparison on the right. I am being picky on the loss of border-spacing between cells, but otherwise there is not much good method to prevent additional space around sub-boxes. Some reading below:
As a side-note, {{Navbox subgroup}} uses border-collapse:collapse either, and try to re-create border-spacing using borders and empty rows. — Peterwhy 05:27, 28 April 2013 (UTC)
I had only tried it in cases where there was no background cell colouring, so it wasn't so obvious that there was space being removed. I like your suggestion of using a negative margin instead. in any case, I'm just glad to see there is some momentum for adding this feature to this template. thank you. Frietjes (talk) 16:05, 28 April 2013 (UTC)
Another point to note: my experience with MediaWiki mobile view has not been happy, and I know mobile view always wants to control how tables look. It could be a hard time to ensure mobile users see sub-boxes consistently. — Peterwhy 19:50, 28 April 2013 (UTC)
the additional padding is not entirely a bad thing, if we want a visual cue that these are subheadings. of course, its good to be able to make this additional padding optional. as far as mobile goes, they didn't support hlist for quit some time and that didn't seem to be a show stopper. I say we go ahead unless there is a more obvious way to achieve the same thing. I will see if some other "CSS experts" have any ideas. thank you. Frietjes (talk) 20:21, 6 May 2013 (UTC)
That leads back to one of my questions: what is this sub-box actually meant for? If I would like to use that for collapsible section, then I don't think sub-box is what I wanted. — Peterwhy 01:55, 7 May 2013 (UTC)
it's primarily meant for uses outlined in the documentation for Template:Infobox subbox bodystyle. if you simply want to collapse something you can use {{hidden}}, but this is meant to be more general. Frietjes (talk) 15:58, 7 May 2013 (UTC)

Request

{{#if:{{safesubst:#switch: y

|no
|n
|0        = 
|         = 
|¬        = 
|yes
|y
|1        = yes
|#default = yes

}}

    | {{#ifeq:yes|yes

|

{{#ifeq:{{#if:[[File:{{#ifeq:{{{semi}}}|yes |Padlock-silver.svg |Padlock.svg }}|25px|alt=|link=]]| [[File:{{#ifeq:{{{semi}}}|yes |Padlock-silver.svg |Padlock.svg }}|25px|alt=|link=]] | }}|none | | }}

{{#if:{{#if: | {{{smallimageright}}} | }} | {{#ifeq:{{#if: | {{{smallimageright}}} | }}|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}}

|

{{#ifeq:|none | | }}

{{#if: | {{#ifeq:|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}} }}{{#ifeq:Template talk|Template | {{#ifeq:Infobox|Infobox

 |   
   {{#ifeq:|true
   |   
   |
   }}
 }}

}}

    | {{#switch:
 {{#if:{{#if:  | Talk }} 
 | {{#if:  | talk }}    
 | {{#ifeq:Template talk|Template talk
   | talk
   | other
   }} 
 }}

| talk = {{#if:editprotected|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|Template:Anchor (or Anchors): too many anchors, maximum is 10.}}{{#ifeq:|yes

|

{{#ifeq:{{#if:| {{{smallimage}}} | File:Padlock.svg }}|none | | }} {{#if:{{#if: | {{{smallimageright}}} | }} | {{#ifeq:{{#if: | {{{smallimageright}}} | }}|none | |
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}}

|

{{#ifeq:File:Padlock.svg|none | | }} {{#if: | {{#ifeq:|none | |
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}} }}{{#ifeq:Template talk|Template | {{#ifeq:Infobox|Infobox

 |   
   {{#ifeq:|true
   |   
   |
   }}
 }}

}}

| other | #default = Error: Protected edit requests can only be made on the talk page.{{#if:

          | 
          |
         }}{{#if: 
          | 
          |
         }}

}}}} okay, so it seems there are no objections to the negative margin version? I will add an edit request. Frietjes (talk) 21:56, 21 May 2013 (UTC)

please change

style="border-spacing: 3px; width:22em;

to

style="{{#ifeq:{{{subbox|}}}|yes
 |padding:0; border:none; border-spacing:3px; margin:-3px; width:auto; min-width:100%; font-size:100%; clear:none; float:none; background-color:transparent;
 |border-spacing: 3px; width:22em;
 }}

which seems to be the closest we can get to making this work like a navbox subgroup. note this will have zero impact on existing transclusions, but will allow |{{#if:subbox|subbox=}}yes to be used to embed an infobox inside another infobox (or inside a sidebar). Frietjes (talk) 21:56, 21 May 2013 (UTC)

Will negative values for margin: give consistent behaviour across browsers? See CSS documentation, "Negative values for margin properties are allowed, but there may be implementation-specific limits". --Redrose64 (talk) 23:08, 21 May 2013 (UTC)
we can always update the implementation later if there is a better option. the only other option I see would be to go with the border-collapse variant, which also its issues. Frietjes (talk) 23:13, 21 May 2013 (UTC)
Code placed on Template:Infobox/sandbox. Are we good to go? — Martin (MSGJ · talk) 09:34, 22 May 2013 (UTC)
looks good to me. the worst possible outcome, as far as I can tell, of a browser not supporting negative margins would be an extra 3px padding, which is purely an aesthetic issue, and not anything that would cause serious problems. Frietjes (talk) 16:15, 22 May 2013 (UTC)
Okay, deployed. There seems to be some work on a Lua version, so perhaps that will sort out the margin problems. — Martin (MSGJ · talk) 09:14, 23 May 2013 (UTC)

fix for double bolding

{{#if:{{safesubst:#switch: yes

|no
|n
|0        = 
|         = 
|¬        = 
|yes
|y
|1        = yes
|#default = yes

}}

    | {{#ifeq:yes|yes

|

{{#ifeq:{{#if:[[File:{{#ifeq:{{{semi}}}|yes |Padlock-silver.svg |Padlock.svg }}|25px|alt=|link=]]| [[File:{{#ifeq:{{{semi}}}|yes |Padlock-silver.svg |Padlock.svg }}|25px|alt=|link=]] | }}|none | | }}

{{#if:{{#if: | {{{smallimageright}}} | }} | {{#ifeq:{{#if: | {{{smallimageright}}} | }}|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}}

|

{{#ifeq:|none | | }}

{{#if: | {{#ifeq:|none

 | 
|
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}} }}{{#ifeq:Template talk|Template | {{#ifeq:Infobox|Infobox

 |   
   {{#ifeq:|true
   |   
   |
   }}
 }}

}}

    | {{#switch:
 {{#if:{{#if:  | Talk }} 
 | {{#if:  | talk }}    
 | {{#ifeq:Template talk|Template talk
   | talk
   | other
   }} 
 }}

| talk = {{#if:editprotected|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|}}{{#if:|Template:Anchor (or Anchors): too many anchors, maximum is 10.}}{{#ifeq:|yes

|

{{#ifeq:{{#if:| {{{smallimage}}} | File:Padlock.svg }}|none | | }} {{#if:{{#if: | {{{smallimageright}}} | }} | {{#ifeq:{{#if: | {{{smallimageright}}} | }}|none | |
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}}

|

{{#ifeq:File:Padlock.svg|none | | }} {{#if: | {{#ifeq:|none | |
 }}

}}

{{#switch:

| | speedy | delete | content | style | move | protection | notice =

| #default =

This message box is using an invalid "type=" parameter and needs fixing.

}} }}{{#ifeq:Template talk|Template | {{#ifeq:Infobox|Infobox

 |   
   {{#ifeq:|true
   |   
   |
   }}
 }}

}}

| other | #default = Error: Protected edit requests can only be made on the talk page.{{#if:

          | 
          |
         }}{{#if: 
          | 
          |
         }}

}}}} I purpose making this change to the template, which will fix the double bolding problem described in Template:Infobox/doc#Embedding. the double bolding only happens in IE on Windows (see some discussion at MediaWiki talk:Common.css). in most cases, these headings are still double-bold, but most editors don't notice it, since a <th> tag plus a <b> tag looks the same as a <th> tag without the <b> tag. the worst thing that could happen by removing this extra bold tag is that some headings in child boxes become unbold. we could accompany this change with a tracking category/tracking template to find all the uses of |{{#if:child|child=}}yes so they can be checked by bot. comments? Frietjes (talk) 20:27, 24 May 2013 (UTC)

I'm not exactly sure why I added those bold tags in the first place. Removing them seems reasonable. Thanks for figuring out the problem! Plastikspork ―Œ(talk) 01:09, 25 May 2013 (UTC)
great, I will add an edit request. please update the code to this version of the sandbox. this will remove the extra bold tags from the |{{#if:title|title=}} when |{{#if:child|child=}}yes, and add a tracking category to find instances that are using this feature so they can be checked to make sure no necessary bolding was lost. thank you. Frietjes (talk) 14:05, 25 May 2013 (UTC)
Done! Plastikspork ―Œ(talk) 23:39, 27 May 2013 (UTC)

Module:Infobox is now live

This template is now using Module:Infobox. It should (should) behave exactly as the old template did, but if anyone notices any bugs please post about them here. And a big thank you to Toohool who wrote the code, and WOSlinker who helped me to test it. — Mr. Stradivarius ♪ talk ♪ 10:12, 5 June 2013 (UTC)

  • what was the issue with Template:Infobox airline? once this is stable for a few weeks, I will convert infobox school, which requires more than 99 rows. thanks for the hard work. Frietjes (talk) 17:29, 5 June 2013 (UTC)
    • When a wikitable is used against one of the data params it wasn't showing as a table because the table wasn't starting on a new line. For example:
{| class="wikitable"

! table

|}

vs

table

Adding a new line into Module:Infobox fixed it. -- WOSlinker (talk) 18:15, 5 June 2013 (UTC)

good to know. I tend to use html tables in such cases to avoid this exact issue, and issues with whitespace since you can place an html table on a single line, but it's good to know that the other method will work as well. Frietjes (talk) 20:22, 5 June 2013 (UTC)

AIATSIS bug

hi, I noticed today that *all* pages with Infobox now have a bug: a phantom footnote is created (always fn #2 I think) with a deadlink to AIATSIS. I see no way to remove it, it must be inserted by some script related to the infobox, and to Template:AIATSIS. Thanks, Womtelo (talk) 11:10, 7 June 2013 (UTC).

I think I've fixed it with an edit at Template:Infobox language. -- John of Reading (talk) 11:50, 7 June 2013 (UTC)
It would be good to change the touchParameters function so that it only looks at label params where there is something in the corresponding data param. -- WOSlinker (talk) 12:27, 7 June 2013 (UTC)
I don't think it is worth the extra complexity. It was easy enough to fix the template once I'd worked out what the problem was. -- John of Reading (talk) 21:17, 7 June 2013 (UTC)
agreed, that would match the prior functionality. note, there is an infobox problem being discussed at Template talk:Infobox NRHP, although I am still waiting for an example, so it could predate this template change. Frietjes (talk) 21:36, 7 June 2013 (UTC)
I've worked out the true cause of this bug, and it's not touchParameters(). Well, not just touchParameters(). The problem is that once a parameter that contains a reference is processed by Lua, that reference is included in the references section no matter what. In the current case, we have a reference that was included in one of the label parameters. It is actually processed twice, despite not being used in the infobox - the first time by touchParameters() and the second time by pairs(origArgs). Fixing the former use is fairly easy, and I have done it in this revision of Module:Infobox/sandbox, but fixing the latter use would be a real pain. It would require something like adapting touchParameters() to assign the parameters to the argument table, and would mean we would have to impose arbitrary limits on how far apart parameters can be numbered. — Mr. Stradivarius ♪ talk ♪ 04:11, 8 June 2013 (UTC)
Also, I've added a new test case for this bug at Template:Infobox/testcases#Orphaned references. — Mr. Stradivarius ♪ talk ♪ 04:13, 8 June 2013 (UTC)
There's a fix for this bug in Module:Infobox/sandbox now. Because we can't use pairs(), the fix requires us to set an arbitrary limit for how far apart parameters can be numbered. At the moment this number is set to 5 for the subheader and image parameters, and to 20 for the header, label and data parameters. This means that if there was only a |{{#if:data20|data20=}} and a |{{#if:data40|data40=}} parameter, they would both get picked up no problem, but if there was only a |{{#if:data20|data20=}} and a |{{#if:data41|data41=}} parameter, the latter would be skipped. I'm thinking that it might be better to set the number to 50 for the header, label, and data parameters, but it I'm not sure how much it would impact the performance of the module. Does anyone have any good advice? — Mr. Stradivarius ♪ talk ♪ 16:26, 8 June 2013 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────{{safesubst:#if:|(outdent) }} I've put the fix up live now, so we shouldn't see any more phantom reference problems. If you do, please let me know. — Mr. Stradivarius ♪ talk ♪ 08:01, 9 June 2013 (UTC)

Blank line before infobox

The Lua form of the infobox is introducing at least one newline at the very start, where none previously existed - the pre-Lua form began with a parser function {{#ifeq:{{{child|}}}|yes|| which would have served to strip superfluous whitespace, had any existed (in fact it then went straight in with {{#switch:o

|c|close  = 
|s|single
|o|open
|p|pair   = <table{{#if:class="infobox ...| class="infobox ...}}

}}{{#switch:o

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:o

|s|single
|o|open   = 
|c|close
|p|pair   = </table>

}}). Please see Template talk:Infobox U.S. county#Extra space. --Redrose64 (talk) 09:06, 8 June 2013 (UTC)

This isn't a Lua problem - {{Infobox U.S. county}} doesn't actually use {{Infobox}} at all. I've commented in more detail over at the thread you linked. — Mr. Stradivarius ♪ talk ♪ 09:33, 8 June 2013 (UTC)

Non-valid HTML code <br>

Hi, it seems to me this module generates a non valid HTML tag "<br>" (not closed), just before the image caption. One of the consequences of this is that parsoid has difficulties with it and display it. The Lua code seems to be OK to me (selfClosing = true), I don't know what is wrong wit it. But I propose to simply remove this BR tag, which is IMO useless. Regards Kelson (talk) 09:57, 8 June 2013 (UTC)

You're right, and this is a bug in Module:HtmlBuilder. It looks like support for selfClosing = true was never actually added, so the module ignores it and outputs <br></br>. I'm not too familiar with how that module works, though. I'll let Toohool know and see if they can help. I'm guessing that we do need to have the <br/> tag in Module:Infobox for backwards-compatibility reasons, so it would be best to fix the bug rather than rely on the workaround of removing it. Best — Mr. Stradivarius ♪ talk ♪ 10:14, 8 June 2013 (UTC)
@Kelson: The {{#switch:o
|c|close  = 
|s|single
|o|open
|p|pair   = <br{{#if:| {{{params}}}}}

}}{{#switch:o

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:o

|s|single
|o|open   = 
|c|close
|p|pair   = </br>

}} tag is perfectly valid HTML, but it's not valid XHTML - XHTML requires the {{#switch:s

|c|close  = 
|s|single
|o|open
|p|pair   = <br{{#if:| {{{params}}}}}

}}{{#switch:s

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:s

|s|single
|o|open   = 
|c|close
|p|pair   = </br>

}} form, which most browsers will accept in HTML documents as an alternative form of {{#switch:o

|c|close  = 
|s|single
|o|open
|p|pair   = <br{{#if:| {{{params}}}}}

}}{{#switch:o

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:o

|s|single
|o|open   = 
|c|close
|p|pair   = </br>

}}. However, when I follow the link you provide, what I see is a {{#switch:c

|c|close  = 
|s|single
|o|open
|p|pair   = <br{{#if:| {{{params}}}}}

}}{{#switch:c

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:c

|s|single
|o|open   = 
|c|close
|p|pair   = </br>

}} just after the image, which is not valid in either HTML or XHTML. --Redrose64 (talk) 10:40, 8 June 2013 (UTC)

I found that the relevant parts of Module:HtmlBuilder weren't actually that hard to understand, so I went ahead and fixed it. This template should be generating <br/> now. — Mr. Stradivarius ♪ talk ♪ 10:47, 8 June 2013 (UTC)
Wonderful, thank you very much! Kelson (talk) 10:58, 8 June 2013 (UTC)
We don't use XHTML in any way. It's served with a text/html MIME type and a HTML5 doctype. The bug is in any code that assumes it's XHTML despite the MIME type clearly saying otherwise. Superm401 - Talk 00:09, 9 June 2013 (UTC)
Sorry, my mistake. I didn't realize it was outputting a '</br>', which is indeed completely invalid HTML5. Superm401 - Talk 00:20, 9 June 2013 (UTC)

Module:IncrementParams

Shameless plug - if you don't like manually renumbering infobox parameters, then you don't have to any more, as I have just written Module:IncrementParams. You're welcome. ;) — Mr. Stradivarius ♪ talk ♪ 08:33, 13 June 2013 (UTC)

I wrote a javascript script that does something related for infoboxes for the edit window, but it is confused by child boxes since it assumes a global numbering, but it certainly has saved me quite a bit of of time and mistakes. I am currently using it through greasemonkey, but could upload it here. Frietjes (talk) 17:24, 13 June 2013 (UTC)
see User:Frietjes/infoboxgap.js, adds two buttons to your toolbox in template edit mode, (1) infobox gap for inserting a gap in the numbering, and (2) infobox renumber for sequential renumbering, which removes gaps and makes it so the numbering is consistent with the order appearing in the infobox. Frietjes (talk) 18:00, 13 June 2013 (UTC)
Ooh, that looks rather nice - I might start using that. — Mr. Stradivarius ♪ talk ♪ 14:31, 30 June 2013 (UTC)
it works very well in most cases, but as I said, it is confused by child boxes. I actively use it so I fix bugs when I see them. I have some ideas of how to fix the child infobox issue, but I haven't been motivated to do it yet. Frietjes (talk) 18:36, 30 June 2013 (UTC)

No red link if image doesnt exist

There is no red link to the image if it doesnt exsit. It just write the name of the file, e.g.: {{#invoke:Infobox|infobox}} Christian75 (talk) 14:05, 22 June 2013 (UTC) {{#invoke:Infobox|infobox}}

this template does not convert the image name into an image, it uses the full image syntax. templates which call this template frequently use the image name syntax (e.g., see {{infobox bridge}}), but this meta-template does not. Frietjes (talk) 15:47, 22 June 2013 (UTC)

Please help with Eurozone

Hello,

Can someone please help left-justify the legend in the caption of the infobox at Eurozone? It looks a bit horrible at the minute. Thanks. 110.67.148.4 (talk) 13:04, 30 June 2013 (UTC)

I've done it with an extra {{#switch:o
|c|close  = 
|s|single
|o|open
|p|pair   = <div{{#if:| {{{params}}}}}

}}{{#switch:o

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:o

|s|single
|o|open   = 
|c|close
|p|pair   = </div>

}} (diff), but I expect the "official" way to do this is with the captionstyle parameter. -- John of Reading (talk) 13:24, 30 June 2013 (UTC)

Thanks! 110.67.148.4 (talk) 13:26, 30 June 2013 (UTC)
I tried to do it with captionstyle, but it doesn't seem to work. It looks like this is because the caption style is inside <span> tags rather than <div> tags. I've changed Module:Infobox/sandbox to use <div> tags instead, and that fixes the immediate problem - see the test case that I added. I'm not sure if it will have any adverse affects on any existing infoboxes though, so it will need to be tested properly before it goes up live. — Mr. Stradivarius ♪ talk ♪ 14:07, 30 June 2013 (UTC)
Already, looking at the Aristotle test case I see that the change would introduce subtle differences in formatting. There is a space increase between the image and the caption, and the line-height: 1.1em; seems to now be working where it wasn't before. I think this change is probably for the best, but I would appreciate it if someone with better html knowledge than me could investigate. — Mr. Stradivarius ♪ talk ♪ 14:28, 30 June 2013 (UTC)

Direct passing of parameters

I noticed that the ability to pass parameters directly to the module is for testing purposes. Will this ability be permanently retained? I think it will be needed when individual infobox templates, such as {{Infobox road}}, are converted to Lua. -happy5214 08:49, 3 July 2013 (UTC)

Yes, it will stay this way. Saying "for testing purposes" was probably a bad choice of words - really it should be something like "for accessing from the debug console or from other Lua modules". — Mr. Stradivarius ♪ talk ♪ 08:42, 10 July 2013 (UTC)

Below parameter newlines

{{#invoke:Infobox|infobox}} {{#invoke:Infobox|infobox}} it looks like {{infobox}} is adding {{#switch:pair

|c|close  = 
|s|single
|o|open
|p|pair   = <p{{#if:| {{{params}}}}}

}}{{#switch:pair

|c|close  = 
|s|single =  />
|o|open   = >
|p|pair   = >...

}}{{#switch:pair

|s|single
|o|open   = 
|c|close
|p|pair   = </p>

}} around anything pass to the below parameter. my guess is that there is an extra newline in there. I know this is a bit tricky, since we want bullet lists to work, but the same problem doesn't happen for the data fields. Frietjes (talk) 23:42, 9 July 2013 (UTC) — Preceding text originally posted on User talk:Mr. Stradivarius (diff)

probably could just remove the second newline in the below? Frietjes (talk) 23:44, 9 July 2013 (UTC) — Preceding text originally posted on User talk:Mr. Stradivarius (diff)
Yep, the module inserts two newlines to mimic the behaviour of the old template. That's the part of Module:Infobox that goes:

<source lang="Lua">

               .newline()
               .wikitext(args.below)
               .newline()

</source>

Compare this to the part of Template:Infobox/old that goes:
-->{{#if:{{{below|}}}|<tr><td colspan="2" class="{{{belowclass|}}}" style="text-align:center; {{{belowstyle|}}}">
{{{below}}}
</td></tr>}}<!--
As far as I'm aware, we wouldn't break anything by removing the second newline - it's just in there because that's what the old template did. I'll try removing it in the sandbox and seeing if anything interesting happens at Template:Infobox/testcases. — Mr. Stradivarius ♪ talk ♪ 08:24, 10 July 2013 (UTC)
I've tried it, and it shortens the infobox in most cases. Nothing appears to be broken, though. If people could test the sandbox with more infoboxes, that would be very useful. Also, bear in mind that at present the sandbox also contains the changes I mentioned in the #Please help with Eurozone section above. — Mr. Stradivarius ♪ talk ♪ 08:36, 10 July 2013 (UTC)
I don't see any problems with removing the second newline either, and it would eliminate the problem. using a div for the caption also seems sensible. Frietjes (talk) 14:45, 10 July 2013 (UTC)
I've gone ahead and updated the module. Let me see if you spot any issues. — Mr. Stradivarius ♪ talk ♪ 14:35, 11 July 2013 (UTC)

even/odd headerstyles

it occurred to me that the striping used by template:infobox MLB player would be much easier if we had even/odd headerstyles (see, for example, the testcases). does anyone else think this would be a good idea? I was able to hack it using child boxes, but it would have been less convoluted if we had the ability to define more than one headerstyle. Frietjes (talk) 17:23, 13 July 2013 (UTC)

I've added a new version to the sandbox. You can now specify styles for individual headers with the |{{#if:headerstyle1|headerstyle1=}}, |{{#if:headerstyle2|headerstyle2=}}, etc. parameters. It is also possible to specify styles for odd or even headings using the |{{#if:oddheaderstyle|oddheaderstyle=}} and |{{#if:evenheaderstyle|evenheaderstyle=}} parameters. (This is calculated from the total number of headers in the infobox, not from the number of the header itself.) The |{{#if:headerstyle1|headerstyle1=}}, |{{#if:headerstyle2|headerstyle2=}}, etc. parameters take precedence over all the other header style parameters, and the |{{#if:oddheaderstyle|oddheaderstyle=}} and |{{#if:evenheaderstyle|evenheaderstyle=}} parameters take precedence over the existing |{{#if:headerstyle|headerstyle=}} parameter. Have a play around with it and see if it does what you need. If everything looks ok, I can update the main module for you. Best — Mr. Stradivarius ♪ talk ♪ 07:59, 14 July 2013 (UTC)
I've also added some test cases at Template:Infobox/testcases#Individual header styles. — Mr. Stradivarius ♪ talk ♪ 08:13, 14 July 2013 (UTC)
I seem to recall there was a reason for not allowing that much specificity for the styling, which is why I was being cautious by only suggesting even/odd. but if there are no objections, I suppose I see no problem with it either. it's probably less of an issue here as it is with {{navbox}} where editors come up with all kinds of crazy rainbow schemes. Frietjes (talk) 14:59, 14 July 2013 (UTC)
If there was even/odd row styles (not just headers) then Template:Infobox video game could be converted to an infobox. Although the even/odd would have to work when some rows didn't have any data. -- WOSlinker (talk) 20:36, 14 July 2013 (UTC)
Should the order of the even/odd row styles be independent of the headers, or should the first row after every header start with the odd row style? — Mr. Stradivarius ♪ talk ♪ 01:38, 15 July 2013 (UTC)
Infobox video game doesn't use headers but if it did, they would need to be included in even/odd if it was named as a global even/odd parameter. If data1, header3 & data5 were the only rows to display something then data1 would be odd, header3 would be even & data5 would be odd. The even/odd doesn't depend on the numbers. -- WOSlinker (talk) 06:37, 15 July 2013 (UTC)
I got the part of the even/odd being independent of the numbers - that's how the headers work in the sandbox (see this test case). I'm not quite sure of how the rows should interact with the headers though. I can think of three possibilities:
Possibility 1 - even/odd row numbering reset after headers
  • Header 1 - blue
  • Data 2 - white
  • Data 3 - grey
  • Data 4 - white
  • Header 5 - blue
  • Data 6 - white
  • Data 7 - grey
  • etc.
Possibility 2 - even/odd row numbering independent of headers
  • Header 1 - blue
  • Data 2 - white
  • Data 3 - grey
  • Data 4 - white
  • Header 5 - blue
  • Data 6 - grey
  • Data 7 - white
  • etc.
Possibility 3 - even/odd numbering includes headers
  • Header 1 - grey
  • Data 2 - white
  • Data 3 - grey
  • Data 4 - white
  • Header 5 - grey
  • Data 6 - white
  • Data 7 - grey
  • Header 8 - white
  • etc.
I'm not sure which of these we need to choose, or whether we should create some code that means any of these options can be chosen. — Mr. Stradivarius ♪ talk ♪ 08:34, 15 July 2013 (UTC)
If you go for the 3rd option and apply the odd/even style before any headerstyle then I think that would be fine. -- WOSlinker (talk) 08:40, 15 July 2013 (UTC)
{{#if:Frietjes
|@Frietjes{{#if:
 |, [[User:{{{2}}}|{{{2}}}]]{{#if:
  |, [[User:{{{3}}}|{{{3}}}]]{{#if:
   |, [[User:{{{4}}}|{{{4}}}]]{{#if:
    |, [[User:{{{5}}}|{{{5}}}]]
   }}
  }}
 }}
}}:
|{{#invoke:Error|error|Error in replyto template: Username not given. See Template:Replyto for usage.|tag=}}

}} I'd have no problem with taking the individual header styles out if there has already been a consensus found for it. I thought it was just an oversight that they were left out, but if there was a good reason to do so then I certainly wouldn't be against it. Do you have a link to the discussion, by any chance? — Mr. Stradivarius ♪ talk ♪ 01:38, 15 July 2013 (UTC)

And also, if someone really wants to create a crazy rainbow scheme, it's not all that hard to do even with the present template. :) — Mr. Stradivarius ♪ talk ♪ 08:34, 15 July 2013 (UTC)
yes, it is possible, although to extend this to multiple labelstyles and multiple datastyles and multiple headerstyles requires a bit more effort. I will see if I can find a specific thread about this (so far all I found was this), but as I said, I don't have any serious problem with it. the likelihood of significant deviations is far less here than it is for navboxes. Frietjes (talk) 17:33, 15 July 2013 (UTC)
One of the reasons that there wasn't separate styles for each item before was because it would have made the template code a lot larger and that there's only a few infoboxes that would have a need for the use of it anyway. Since it's now in Lua, the code size is not as much of an issue. -- WOSlinker (talk) 17:51, 15 July 2013 (UTC)

Predecessor/successor fields in officeholder infobox

A discussion has been started here regarding the "predecessor" and "successor" fields in {{{{#if: |subst:}}infobox officeholder{{#if: ||{{{2}}}}}{{#if: ||{{{3}}}}}{{#if: ||{{{4}}}}}{{#if: ||{{{5}}}}}{{#if: ||{{{6}}}}}{{#if: ||{{{7}}}}}{{#if: ||{{{8}}}}}{{#if: ||{{{9}}}}}{{#if: ||{{{10}}}}}{{#if: ||{{{11}}}}}{{#if: ||}}}}, and whether the usage should be changed or the fields should be removed entirely. —Designate (talk) 22:40, 16 July 2013 (UTC)