Module talk:WikiProject banner

IMAGE_LEFT_CLASS may be needed

Please see this edit, which hacked in a class for the IMAGE_LEFT image so that the image would show correctly in dark mode (white on black instead of the previous black on black). It points out the potential need for IMAGE_LEFT_CLASS, and maybe some other image CLASS parameters, in this module/template. – Jonesey95 (talk) 19:38, 25 May 2026 (UTC)

@Jonesey95:  Implemented in the sandbox as |IMAGE_LEFT_CLASS=, |IMAGE_RIGHT_CLASS=, and |IMAGE_CLASS=. The first two override the third (which applies to both RIGHT and LEFT). Tested at Module talk:WikiProject banner/testcases#Image class.

To the closing admin --- please copy the sandbox to main, being careful to comment out the sandbox at line 3.

— hike395 (talk) 18:49, 27 May 2026 (UTC)

 Done * Pppery * _{in solidarity} 16:18, 28 May 2026 (UTC)

DOC=auto parameter syntax highlighting

I created {{para2}} to apply <syntaxhighlight lang="wikitext">-style highlighting to standalone parameters. It's a very simplified version of {{para}} without all the bells & whistles. Its uses are {{para2|foo}} and {{para2|foo|bar}} only, which create |foo= and |foo=bar, respectively, which cover 98% of all use cases. Assuming {{para2}} covers all cases used by Module:WikiProject banner, the only line that needs to be changed appears to be line #13, from this:

return frame:expandTemplate{title='para', args={parameter, value or ''}}

to this:

return frame:expandTemplate{title='para2', args={parameter, value or ''}}

~ Tom.Reding (talk ⋅dgaf)  11:09, 8 June 2026 (UTC)

What is the benefit? — Martin (MSGJ · talk) 12:28, 8 June 2026 (UTC)

For formatting consistency with sections using <syntaxhighlight lang="wikitext">:

{{para|foo|bar}} displays as |foo=bar (current)

{{para2|foo|bar}} displays as |foo=bar (proposed).   ~ Tom.Reding (talk ⋅dgaf)  13:02, 8 June 2026 (UTC)

Got it. Why not add that feature to {{para}}? — Martin (MSGJ · talk) 13:04, 8 June 2026 (UTC)

That was proposed 2 years ago @ Template talk:Parameter#How to syntaxhighlight a standalone parameter?, but rejected due to dark mode incompatibilities, presumably on non-doc pages due to the absence of a non-white background on non-doc pages. See that discussion for more detail and a more accurate interpretation. One of the 2 associated phab tickets is still open.   ~ Tom.Reding (talk ⋅dgaf)  13:13, 8 June 2026 (UTC)

Why would para2 not suffer the same problems in dark mode? And have you seen the comment from FaviFake on that page? — Martin (MSGJ · talk) 07:43, 9 June 2026 (UTC)

Re: dark mode: because para2 would only be used where it isn't a problem, i.e. on documentation pages, and I don't see syntaxhighlight disappearing.

Re: FaviFake: I've responded @ Template talk:Parameter#para2.   ~ Tom.Reding (talk ⋅dgaf)  10:56, 9 June 2026 (UTC)

I've added it to the sandbox, but not totally convinced this is beneificial. I think for a block of code the coloring is helpful, but for a single parameter it seems unnecessary. Compare examples below — Martin (MSGJ · talk) 10:07, 12 June 2026 (UTC)

Proposed

This request is to modify the |DOC=auto portion only. I was not aware of any |para= usages outside of the documentation, so if isolating /doc usage only is difficult, then it might not be worth it.
Documentation is improved by |para2= usage in my option, for example in Module:WikiProject banner#Custom masks.   ~ Tom.Reding (talk ⋅dgaf)  10:55, 12 June 2026 (UTC)

Okay so you probably want to edit Module:WikiProject banner/templatepage#L-288 instead — Martin (MSGJ · talk) 11:50, 12 June 2026 (UTC)

Thanks for the pointer, but I don't know how to do that there.   ~ Tom.Reding (talk ⋅dgaf)  22:16, 12 June 2026 (UTC)

Please check Template:WikiProject Christianity/sandbox#Parameters and see if it looks good? — Martin (MSGJ · talk) 12:29, 17 June 2026 (UTC)

That looks nice. It still looks like all instances of "based on the |class= parameter" need to converted to "based on the |class= parameter".

FYI there is a merger discussion for {{Parameter2}} into {{Parameter}} happening here. That happened much more quickly than I was expecting.   ~ Tom.Reding (talk ⋅dgaf)  13:26, 17 June 2026 (UTC)

How's that looking now? — Martin (MSGJ · talk) 14:01, 17 June 2026 (UTC)

Great!   ~ Tom.Reding (talk ⋅dgaf)  14:04, 17 June 2026 (UTC)

 Done. Will likely need updating once the merge has completed — Martin (MSGJ · talk) 14:16, 17 June 2026 (UTC)

"MAIN_CAT" and config "category" apparent discrepancy

The documentation says that MAIN_CAT applies the category to "all pages displaying the template", and also says that category on a config page applies to "all articles" (implying article space only, but MAIN_CAT applies to all pages, and this template is placed on talk pages and does not categorize article pages). Is this an error in the documentation? I ask because of this request to apply Category:WikiProject Ice Hockey articles to {{WikiProject Ice Hockey}}. Is there a way to limit categorization to just article talk pages? – Jonesey95 (talk) 18:35, 20 June 2026 (UTC)

The main cat should be for every single page that is tagged by the banner. That shouldn't change. The sub-categories at Category:Ice Hockey articles by quality (the ones with the actual rating) are the ones that limit to only article pages. What should perhaps change wiki-wide (but will be a pain) is the naming convention we use for the meta-categories that hold both articles and non-articles. Gonnym (talk) 03:41, 21 June 2026 (UTC)

OK, I have adjusted the documentation accordingly. The category name is still inaccurate, but it seems to match the other subcategories of Category:Articles by WikiProject. Fixing the names of all of those categories looks like a fun project for someone who is not me. – Jonesey95 (talk) 06:36, 21 June 2026 (UTC)

Protected edit request on 15 July 2026

As a follow-up to recent changes related to image CSS classes, please apply Special:Diff/1356645927/1364186968 Special:Diff/1356645927/1364427602 (new, better diff —⁠andrybak (talk) 13:08, 16 July 2026 (UTC)) to:

1. Remove unused function display_error. Last usage of it was removed in Special:Diff/1317754418.
2. Remove unused local variable template_outside_shell. It has been unused since its introduction in Special:Diff/1247210025.
3. Pass args.IMAGE_LEFT_CLASS or args.IMAGE_CLASS as fifth parameter (class) into the image function for the nested banner case. This fixes images of collapsed nested WikiProject banners, which pass |IMAGE_LEFT_CLASS=skin-invert to the module.
   • Example: Template:WikiProject Christianity:
     • Sandbox diff: Special:Diff/1356641126/1364184227
     • Test case demonstrating the fix: "Template:WikiProject Christianity/testcases#Collapsed" with Vector 2022 dark mode

Thanks. —⁠andrybak (talk) 01:34, 15 July 2026 (UTC)

All changes look good to me. Thanks for your attention — Martin (MSGJ · talk) 07:35, 15 July 2026 (UTC)

In the meantime, I stumbled upon another affected template – {{WikiProject Infoboxes}}. Icon for uncollapsed mode is inverted, but nested/collapsed on the talk page is not inverted. —⁠andrybak (talk) 03:21, 16 July 2026 (UTC)

Found another place in the module, where an image class isn't applied – "note images" that are gathered into nested_ratings.

• Isolated diff for the new fix: Special:Diff/1364391952/1364427602. I used noviewer similarly to function image near the top of the module.
• Example affected template – {{WikiProject Portals}}, which has |NOTE_1_IMAGE=Codex icon info.svg and |NOTE_1_IMAGE_CLASS=skin-invert
  • Affected template's sandbox diff: Special:Diff/1364397936/1364426619
  • Demonstration of the fix in "Template:WikiProject Portals/testcases".
  • Off-topic: |NOTE_1_TEXT=See also: [[Portal:Contents/Portals|List of Portals]] ends up as pretty useless title text for the image inside nested_ratings, but that's a separate issue.

I changed the diff link above to the new diff with the fix and with formatting changes by MSGJ. —⁠andrybak (talk) 13:08, 16 July 2026 (UTC)

 Done — Martin (MSGJ · talk) 14:21, 17 July 2026 (UTC)

Category:WikiProject templates with unknown parameters categorization

Could we include problematic pages in their appropriate subcat (if it exists) and in the parent category? This would make it more obvious to maintainers that one of the 500+ subcats is getting filled (or emptied). Courtesy ping to Harryboyles who does a lot of work in this area.   ~ Tom.Reding (talk ⋅dgaf)  14:05, 1 August 2026 (UTC)

Thanks for the courtecy ping. I'm personally not fussed either way as I can use AutoWikiBrowser's List comparer functionality if I wanted to reproduce the current arrangement and filter out pages that appear in a particular WikiProject's subcategory. Harryboyles 01:30, 2 August 2026 (UTC)

Can we just use Category:WikiProject templates with unknown parameters and do away with the hundreds of mainly empty subcategories? — Martin (MSGJ · talk) 12:51, 19 August 2026 (UTC)

My preference is also to have everything in Category:WikiProject templates with unknown parameters. I can see the appeal of having subcats for easier isolation & processing, but for me they are too cumbersome to be the "preferred" scheme. As long as Category:WikiProject templates with unknown parameters is not diffusing, I don't care if the subcats exist or not.   ~ Tom.Reding (talk ⋅dgaf)  14:08, 19 August 2026 (UTC)

inactive vs defunct projects

Hmm... I see I can use

{{#invoke:WikiProject banner|inactive
 |PROJECT     = Extreme sports
}}

...but

{{#invoke:WikiProject banner|defunct
 |PROJECT     = Extreme sports
}}

does not work. Instead I'm directed to use

{{#invoke:WikiProject banner|inactive
 |PROJECT     = Extreme sports
 |PROJECT_STATUS = defunct
}}

On first blush this seems to be unnecessarily complicated, with two levels of applying status. But hey, if it works it works, right?

The problem is, what if it doesn't work?

For instance, the following project is defunct not inactive. Yet, the template claims it is inactive:

I can't ascertain why this error occurs, but I sure suspect the above discrepancy.

Is this really the case? If so, could you please enable the possibility to simply replace inactive for defunct with no need to add (or remove) parameters/flags such as |PROJECT_STATUS=? Thanks CapnZapp (talk) 11:38, 19 August 2026 (UTC)

When you invoke a module, the first parameter specifies the function to be run. In this case it is the inactive function, which starts on line 908. We do not need to duplicate code by adding a defunct function, so I think using PROJECT_STATUS makes sense. Template:WikiProject BBC does not use |PROJECT_STATUS= so I'm not sure what you mean when you say it is defunct not inactive? — Martin (MSGJ · talk) 12:50, 19 August 2026 (UTC)

After a moment of confusion, I now see that Template:WikiProject BBC maintains its own status, separate from that of Wikipedia:WikiProject BBC. It's really unfortunate there isn't a single "master switch" that all related templates get their status from. Oh well.

In this case, the editor that changed the wikiproject's status from inactive to defunct probably wasn't even aware they also needed to put in an edit request to get the template updated. I now realize that if only template editors can edit the templates for wikiprojects the fact you can't simply replace inactive with defunct is of lesser concern. I can (and will) now make that edit request and I expect I don't have to explain how to implement it. CapnZapp (talk) 13:16, 19 August 2026 (UTC)

I think having a central switch for the status of all projects could be problematic because it would mean that a project could be marked as inactive without the knowledge of any of the editors who are watching that project or its template. — Martin (MSGJ · talk) 21:04, 24 August 2026 (UTC)

I am possibly misunderstanding you but just to be sure: I am in no way arguing for a single master switch for all projects. I am envisioning one switch per project (instead of two, as we have today, where editors can - and do - change one without realizing they need to change the other). If people feel this switch is best protected behind an edit request, so be it. Otherwise, the most convenient option would be for the switch to be easily located on the Wiki project's page. Br, CapnZapp (talk) 08:03, 25 August 2026 (UTC)

So the banner would have to read the content of the project page for the setting of this switch? That would add quite an overhead to every page calling the template. — Martin (MSGJ · talk) 08:13, 25 August 2026 (UTC)

Let's switch this around: how would you, as someone in the know, solve this so people can change statuses by changing a single thing, MSGJ? Best regards, CapnZapp (talk) 21:54, 25 August 2026 (UTC)

This was unintuitive to me as well, and I was forced to go through the same process as CapnZapp when defuncting project templates in Category:Defunct WikiProjects (702) a few weeks ago.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 19 August 2026 (UTC)

So where are we standing now? It's apparent that naive suggestions aren't working - something about the current implementation makes it non-trivial to make changes. Yet consensus appears to be that the current system is unfortunate and unwieldy. And there does not seem to be any good reason why a project's status is held by two independent pages so that any status change requires an editor to 1) edit the project's page and 2) make an edit request to change its banner template.

As an outsider it feels as if this can be rather simply fixed, assuming a knowledgeable template editor, so unless people actively disagree with "the fact a WikiProject's status and its banner template's status (for instance Wikipedia:WikiProject BBC and Template:WikiProject BBC respectively) are stored independently is a bug", I'll put in an edit request for someone to fix this structure so that a project's status is stored only once. CapnZapp (talk) 13:48, 27 August 2026 (UTC)

Well, there are 2 separate issues.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 27 August 2026 (UTC)

one variable (issue 1)

The 1st one mentioned here is that it is better to have one variable in the banner control the status, and not 1 variable if inactive, and then 2 variables if defunct. If simplifying this requires duplicating a few lines of code (or creating an alias), then I think it is worth the cost.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 27 August 2026 (UTC)

The reason I didn't continue this issue is because I now realize that if only template editors can edit the templates for wikiprojects the fact you can't simply replace inactive with defunct is of lesser concern. Of course, if issue 2 below breaks this assumption (that you need to request an edit or have template editor permissions in order to effect a status change) it should be addressed. CapnZapp (talk) 08:59, 28 August 2026 (UTC)

That's only true if the WikiProject banner is template-protected. Not all are; some are semi-protected, a few are fully-protected; many are not protected at all. Consider the first ten WikiProject banners (other than subpages) listed at this link:

• Template:WikiProject AIDS - semi-protected
• Template:WikiProject AI Cleanup - unprotected
• Template:WikiProject A Cappella - unprotected
• Template:WikiProject A Song of Ice and Fire - semi-protected
• Template:WikiProject Abandoned Drafts - unprotected
• Template:WikiProject Abandoned articles - unprotected
• Template:WikiProject Abkhazia - semi-protected
• Template:WikiProject Abortion - semi-protected
• Template:WikiProject Academic Journals - template-protected
• Template:WikiProject Accessibility - unprotected

So, from an admittedly small sample, only one out of ten are template-protected, and half are unprotected. --Redrose64 🌹 (talk) 17:52, 28 August 2026 (UTC)

WP:TPE protected or not, the point still stands that most WikiProject templates are harder to edit than their respective project pages. All WikiProject pages in the above list are unprotected. Raising the bar for changing a WikiProject's status may or may not be desirable, though I'm in favor of it, as it would lead to less flip-flopping.   ~ Tom.Reding (talk ⋅dgaf)  18:04, 28 August 2026 (UTC)

(WP:TE points to Wikipedia:Tendentious editing.) WhatamIdoing (talk) 21:40, 28 August 2026 (UTC)

one location (issue 2)

The 2nd issue is having both the template and the WikiProject page's status controlled at one location. I agree with MSGJ that the status should be hard-coded into the template, otherwise there is an enormous amount of overhead that has to occur to retrieve a value that doesn't change frequently. But if the status is hard-coded into the template, then it becomes harder to change a WikiProject's status, usually requiring WP:TPE semi-protected permissions or higher. There might be some merit to this, since the overhead is much, much lower, but there's a reason that the threshold to protecting pages is relatively high, and preemptive protection is not normally done. In other words, all or most project participants should be able to edit the project's status. This would be a WP:WP Council decision probably, and it would require the implementation of the 1st issue beforehand to make switching statuses in the template simpler and more intuitive.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 27 August 2026 (UTC)

I don't have a strong opinion on what solution is chosen. As long as the goal of only having to edit one spot is accomplished, I (perhaps naively) think that's good enough. CapnZapp (talk) 09:10, 28 August 2026 (UTC)

I have advertised this discussion over at Wikipedia talk:WikiProject Council § Discussion at Module talk:WikiProject banner § inactive vs defunct projects. Any other place where notifying could be worthwhile? CapnZapp (talk) 09:10, 28 August 2026 (UTC)

I saw the note at WT:COUNCIL. I like the idea of one action/edit being enough. Is there any reason why we can't have a bot copy the status, as reported on the main page, to the talk page banners? WhatamIdoing (talk) 21:43, 28 August 2026 (UTC)

Categories

Also, it would make sense to have Category:Defunct WikiProject banners alongside Category:Inactive WikiProject banners, since defunct is a much more severe level of inactivity, and to match Category:Defunct WikiProjects.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 19 August 2026 (UTC)

If such a category would genuinely be useful, then it can be added. What about Category:Semi-active WikiProjects and Category:Draft WikiProjects? — Martin (MSGJ · talk) 21:06, 24 August 2026 (UTC)

Ideally there's a separate category for each WikiProject activity status (active, semi-active, inactive, defunct, draft, if I haven't missed any).   ~ Tom.Reding (talk ⋅dgaf)  22:58, 24 August 2026 (UTC)

• Category:Active WikiProject banners & Category:Active WikiProjects
• Category:Semi-active WikiProject banners & Category:Semi-active WikiProjects
• Category:Inactive WikiProject banners & Category:Inactive WikiProjects
• Category:Defunct WikiProject banners & Category:Defunct WikiProjects
• Category:Draft WikiProject banners & Category:Draft WikiProjects

Like this.   ~ Tom.Reding (talk ⋅dgaf)  23:06, 24 August 2026 (UTC)

The active project banners are currently in Category:WikiProject banners with quality assessment or Category:WikiProject banners without quality assessment. I once tried merging these categories but it stopped some tool/script (e.g. rater) working correctly — Martin (MSGJ · talk) 08:11, 25 August 2026 (UTC)

I've created Category:Active WikiProject banners & put them inside.   ~ Tom.Reding (talk ⋅dgaf)  11:16, 26 August 2026 (UTC)