Template talk:Infobox Wikipedia WikiProject

Changes

This template suffers from a number of flaws. Changes to fix them could include

• Making it possible to specify multiple parents and categories -- not one at a time, but all together
• What you're calling a "notice" should be changed to "article scope banner" or something; everyone else is calling them "banners"
• Generalising the box so that it can replace the navigation templates -- some sections should only appear on the main page, though
  • Make a "main page" option; some items are not displayed unless it's true
  • Make sections for listing departments and SIGs (task forces, work groups, whatever)

Some changes are being discussed at Wikipedia talk:WikiProject reform#New Approach. -- TimNelson 07:45, 14 June 2007 (UTC)

Width and bodystyle parameters

The default parameter for image size is not working; if left blank, it just shows the code and doesn't default to 300px. Does someone know how to fix this? Thanks. --Funandtrvl (talk) 18:58, 23 April 2009 (UTC)

fixed imagesize option, made 25em the width default. --Funandtrvl (talk) 20:33, 23 April 2009 (UTC)

The problem is not with {{Infobox WikiProject}}, but with {{Infobox}}. {{Infobox}} is hard coded (presumably for consistency between all infoboxes) to a width of 22em. {{Infobox WikiProject}} attempts to use the bodystyle parameter to override this rather than to add additional, optional CSS markup like it is designed. It might be possible to do something like this:

|bodystyle = {{#if:{{{bodystyle|}}}|{{{bodystyle}}}}}{{#if:{{{width|}}}| {{{width}}} !important;}}

This would add the bodystyle property to the template (which it should have, since it's available in {{Infobox}}), and adds a place to fill in a width, flagging it as an !important property. However, since there would be two width specifications within the same bit of CSS, I'm not sure if it would actually override the first width--at least not consistently across all browsers.

The better solution would be to request that an admin add (the template is protected) an actual width parameter to the {{Infobox}} template rather than trying to juryrig a solution to override a hard coded setting. There may be a consensus decision behind that particular width, however, thus there may be little or no interest in making the width variable.

Is there a reason that we even need a width parameter? The standard width seems okay to me in most cases. I'd suggest that we drop the width parameter, add the bodystyle parameter in (like it should have been all along), and then you could try experimenting with overriding the width using the CSS tag "!important". Dropping the width parameter should not break any existing implementations; it will just be ignored. I'm going to implement this change now:

|bodystyle = width: {{{width|22em}}}{{#if:{{{bodystyle|}}}|{{{bodystyle}}}}}

Hope that helps. --Willscrlt (→“¡¿Talk?!”) 20:46, 23 April 2009 (UTC)

I found that some implementations of this template depend on the imagesize defaulting to 300px (or some other reasonable default), because the image used is larger than 300px. Without the default size (and using the #if: to suppress it if not specified is the same as not including it) the image is too big and the template looks terrible. Some sort of default imagesize always needs to be included. It could be smaller (probably should default to 150px for people on mobile devices and dial-up connections), but whatever the size, it needs to have some default value included.

As for the width issue. Simply inserting a width into the bodystyle to try to change the width does not work. Or rather, it may work on some browsers, but it's not consistent. The underlying template, {{Infobox}} has a preset width of 22em. bodystyle is added after that, but in the same CSS statement. While generally CSS styles defined after other styles take precedence, that doesn't always happen when you have two conflicting styles in the same statement (ex: style="width: 22em; width: 25em;" -- which one takes precedence? The 22em or the 25em width? That's exactly what is happening right now.). If they were specified in two different statements (ex: <div style="width:22em;"><div style="width:25em;">This is 25em</div></div>, the second style (25em) would probably take priority. Of course sticking a wider element inside a skinnier one is improper, so that might not even render correctly in some browsers. The point is that you cannot solve this problem in the {{Infobox WikiProject}} template by trying to override the {{Infobox}} template's hard coded default width using a width parameter to try to trick the {{Infobox}} template into being your preferred size. While it may appear to work on your browser on your computer, it's almost certainly going to render differently in other browsers on other platforms.

I once again removed the width parameter from the {{Infobox WikiProject}} template. Until and unless {{Infobox}} is modified to support that feature, there is absolutely no point in having it in this template. You can try setting bodystyle to something like this and see if it works:

| bodystyle = width:25em !important;

There is no other way to try to get width to work unless the underlying {{Infobox}} is modified. That discussion would need to take place on that template's talk page. Advertising a width parameter and incorporating it into the template is asking for trouble because of the inconsistent way it will render across different browsers. Please don't add it back in unless {{Infobox}} is modified to support it. Thanks! --Willscrlt (→“¡¿Talk?!”) 23:58, 23 April 2009 (UTC)

Major renovation with new features

Hi. Funandtrvl and I just finished a reworking of this template. Very little of the original template code remains, but I checked over 100 WikiProjects, and I couldn't see any indication that my modifications broke any existing implementations (I worked very hard to make sure of that). If I broke something for your WikiProject, please let me know on my talk page, so I can fix it. The new template includes a lot more parser function logic, and it takes someone pretty experienced with templating not to mess it up now (the trade-off of trying to add new features while supporting older implementations).

There is a similar template, {{Project information}} that accomplishes much of the same thing using similarly named parameters. Unfortunately, identically named parameters did not work identically (especially in the 'userbox' section). I standardized between the two templates. In addition, the way that different editors implemented parameters was inconsistent (usually because they didn't read the instructions or the instructions were unclear). The template can now tell if someone includes "Category:" in the category parameter or not (and adapt accordingly). The same is true for all namespaces other than Portal. Portals support custom images (instead of the default Portal.svg image. Assessment had no default value, though there is a standard location for it; it now defaults to that location if you set Assessment to "yes". Many projects did not fill in all the parameters, but the headings still showed up; they now are suppressed for omitted or blank parameters. Shortcuts, userboxes, categories, and portals have been improved in how they accept and display when multiple items are included.

You should be aware that I changed the way a few things default. 'helps-organise-children' and 'has-goals' used to have default values, but they now default to blank. They can also accept a free-form comment, such as text linked to a page with a more detailed explanation than will fit in an infobox. (The old defaults were 'helps-organise-children=no' and 'has-goals=yes'.)

I have also tried to make the template much more portable to other wikis and languages by using namespace magic words ("{{ns:User}}" instead of "User"). This helps ease translation and adapts to variations in other wiki projects. It's not yet fully independent of the English Wikipedia, but it's a lot closer than it was. I applaud Thumperward's earlier conversion to using the standard {{Infobox}} template. There are some things it limits us in (like the lack of a configurable width discussed above), but it really helps to make things more portable and maintainable.

I hope everyone likes the changes and considers them improvements. If not, speak out below, and let's figure out how to make this template even better. Remember, for problems that need fixing quickly, please leave me a message on my talk page. Thanks! --Willscrlt (→“¡¿Talk?!”) 08:51, 24 April 2009 (UTC)

Portals don't line up with other entries

For some reason, portals seem to have an excessive left margin in this template, and do not correctly line up with the other (text-only) lines. Neither this template, nor {{Portal frameless}} seem to contain a margin that could be responsible. Any ideas? --NetRolller 3D 20:04, 24 August 2011 (UTC)

sort parameter

Can someone fix this so that if you mark csb=yes, you can optionally specify a sort key to be appended so that these projects will sort properly in Category:WikiProjects_relevant_for_countering_systemic_bias? Sorry I'm not a template expert...

--Obi-Wan Kenobi (talk) 03:00, 21 March 2014 (UTC)

Not sure how to do this, but you could try contacting someone in Category:Wikipedians willing to assist with templates. APerson (talk!) 21:17, 21 March 2014 (UTC)

Aren't they already sorted by the name parameter? [[Category:WikiProjects relevant for countering systemic bias|{{{name|}}}]] What else do you want to happen? Jackmcbarn (talk) 03:01, 22 March 2014 (UTC)

As Jackmcbarn said, there already is a sort key, the "name=" parameter of the template. That name should not include the "WikiProject" prefix; then, say, WikiProject Chad is sorted under "Chad" in Category:WikiProjects relevant for countering systemic bias. Nothing needs to be done here. Huon (talk) 10:24, 22 March 2014 (UTC)

4 parents

I have a project that actually has 4 parents, but I've only been able to list 3 of them. Would anyone have an objection if I added code to support a 4th one? I'm fairly experienced working on template code. Stevie is the man! ^{Talk • Work} 20:03, 9 December 2015 (UTC)

Seems reasonable to me. Sizeofint (talk) 06:25, 10 December 2015 (UTC)

 Done this was a simple addition. I also updated the documentation. Stevie is the man! ^{Talk • Work} 17:51, 10 January 2016 (UTC)