Template talk:Bug

This template is causing the host to go down. I tried putting this template several times in my user page and it keeps having the host go down. Is it due to the coding? --ToonLucas22 (talk) 18:35, 17 December 2014 (UTC)

Most likely not the template, as it works fine for me, and your page is no where near the page limits. Try editing the page without the template, and if it still throws an error try editing a section (or a different section if you already were editing a section) –KnightMiner ^(t·c) 19:12, 17 December 2014 (UTC)

I have this idea. BDJP007301 and all interested parties, I'd like your input on this if you can. It seems to me that this wiki is meant to document the game, rather than document the bug tracker. And currently for the lists of bug fixes, it references the bug tracker, which is mostly accurate in documenting when a thing is fixed, but on the whole, inaccurate. I would say untrustworthy. Not the fault of anybody, just the way it's set up.

I just discovered for instance that the Lava being destroyed by TNT bug wasn't fixed in 1.8, but earlier, in a 1.7 snapshot. And only because on the tracker nobody checked for that period of time. Again, nobody's fault, and on the tracker, the purpose was served.

Anyhow: can we have a boolean verified field in {{bug}}, that if it's true, it means that somebody here has verified that the bug was in fact fixed in that particular version. And going with that, some page, maybe a category, that gathers all the unverified instances of the {{bug}} template, where the field is false or absent, for further investigation.

Anyway those are my ideas - thoughts?

– Sealbudsman (Aaron) 👁 Image
^t/_c 22:38, 18 April 2015 (UTC)

Well, assuming that category is added, it would certainly be a lot of work to verify all the bugs from tracker that are listed on the wiki. The code would be a bit complicated to not add the category on non-version articles using the category, causing it to be a bit inefficient for a template to make common links, so I would suggest a different way to mark pages with bugs needing verification.

Instead, it might be a good idea to make a project, which would allow the same category system for incomplete pages, and make it easier for additional users to get involved. You can basically add a category to verified pages, and generate a list of incomplete pages from pages in Category:Computer versions that are not in that category (you could really just copy the code from MCW:Projects/Rewrite for Style/Blocks#Progress and change the category names, or I could set it up) –KnightMiner ^t/_c 23:38, 18 April 2015 (UTC)

It would be a ton of work, yeah, I do realize. Quite a bit, no lie. But i mean, at least it would be an accessible project for those who want to do it. And i like the idea of making a proper project.

Would we need to make the distinction between version and non-version articles? Editors can generally look at a category page and tell the difference, yeah?

I wouldn't (unless necessary) want to go the route of adding an 'Unverified Bugs' category to each page. I'm thinking along the lines of this hidden category in Wikipedia, where the Citation Needed template inserts the category with every incorrect usage of the template. In our case, {{bug}} (and i guess {{fixes}}? uh oh, this is getting complicated) would keep track of inserting the Unverified Bugs category to the page based on the 'verified' parameters. Would something like that work, if for the project we took the intersection of the Unverified Bugs category and the Computer Versions category?

– Sealbudsman (Aaron) 👁 Image
^t/_c 00:38, 19 April 2015 (UTC)

I think these would be the categories (everything is in the second category, only because Category:Unverified bugs doesn't yet exist):

Bugs not all verified

#dpl:uses=Template:Bug|category=Unverified Bugs|namespace=

Bugs all verified

#dpl:uses=Template:Bug|notcategory=Unverified Bugs|category=Computer versions|namespace=

(I'll delete this table after this thread is final)

I'll take a crack at making an auto-inserted 'Unverified Bugs' category in {{bug}} and {{fixes}} later, or anyone can.

– Sealbudsman (Aaron) 👁 Image
^t/_c 17:59, 19 April 2015 (UTC)

Yeah, we could simply look at the results using DPL, though I still don't like the idea of adding the category to pages that don't fit the category. One option also might be adding the category if the parameter is set (and removing the parameter after verifying the bug), then sending a bot to set the parameter on all computer versions. That would also make it easier to generate a list of all unchecked bugs using DPL's "includematch" parameter, as finding a nonmatch is more complicated. –KnightMiner ^t/_c 21:09, 19 April 2015 (UTC)

That sends a bit more complicated to me.. More steps, using a bot. Maybe i need to better understand your objection to having the template handle the adding of the 'unverified' category ? – Sealbudsman (Aaron) 👁 Image
^t/_c 23:23, 19 April 2015 (UTC)

The main reason I was against adding the category here is the fact that it would require somewhat inefficient code for a common link template, as each call would have to speerately check the page type, or we would have to add a category to pages that do not belong in the category. Although, I just though of a somewhat efficient way to add the category. Setting a variable in the version nav is an easy way to figure out that it is a version page, as that template adds the version category. It still would be a good idea to add a project to coordinate the testing though.

The only remaining problem is assuming you finish all the bugs on some pages, such as 1.7.2, you still need to add the verified parameter 96 times, so a short name might be in order, such as {{{v}}}. It should be easy enough to add support in {{fixes}} as well.

Lastly, two question related to this: "would you test all the bugs on a page at one time, or test bugs one by one?" and "would you plan on the verification tags being removed after all bugs have been tested, or leave them for future versions?" –KnightMiner ^t/_c 00:52, 20 April 2015 (UTC)

I see. I think I wasn't thinking of having {{bug}} also be responsible for checking whether it's in a version page. I can see how that could be awkward if it didn't. So if you think a variable in the version nav is a clean way of telling that difference, that takes care of that...

A short name, agreed.

I believe each bug would need to be tested 1 by 1. The way I found the correct location of the lava vs TNT bug, I tested it in isolation. I think whatever paradigm is created ought to allow for unverified vs verified bugfixes on the same page. Some are going to be trickier than others, and if the project page keeps track of what pages are what, I don't believe there should be a necessity to do whole pages at a time.

I believe it would be better to leave the {{{v}}} tags in place, #1 so that the project page reflects their completion, #2 for any future viewer of the page. I think removing it, you lose the fact that it's verified. I'll give you a use case. Let's say we verified everything in 1.7.2, then removed the parameters. Then someone down the road closes a bug in the tracker, and it goes in 1.7.2. Now it appears that nothing in 1.7.2 is verified except that new one. Is it recorded somewhere else that all those bugs are verified?

I think the project we make would probably not be a strictly completable project, but more of an ongoing QA project. And so I think the tags would stay.

– Sealbudsman (Aaron) 👁 Image
^t/_c 01:55, 20 April 2015 (UTC)

I just edited the Magma Cube page to add titles and resolutions to bug tooltips. There is one bug where I've added a title but no resolution to the tooltip (MC-131426), because the bug isn't resolved yet, and I've noticed that for that tooltip, the title is not in quotation marks, but for the other tooltips the title is in quotation marks, even though none of the tooltips' code explicitly adds them. I'm not sure if we should use quotation marks or not, but to avoid confusion, we should either always use them or never use them. On the one hand, the quotation marks make it clear that it's a user generated title, but on the other hand, they can clash with other quotation marks (as they do with one of the bug tooltips on the Magma Cube page). I think I need a bit of help deciding whether to use quotation marks. Please give your thoughts. The template probably uses Lua, which I don't have much experience with, so there's probably not much I can do to fix the issue, but if nobody else does it after a few days, then I'll have a go and see what I can do. (I'll make sure to test the result thoroughly before publishing it, of course.) All the cool isms (talk) 13:06, 30 September 2023 (UTC)

I'm not totally sure either, but it may be better to not have the quotation marks, given that neither our version pages (e.g. Java Edition 1.14#Fixes) nor Minecraft.net version articles have them. –Sonicwave ^talk 18:15, 30 September 2023 (UTC)

I went ahead and removed the quotes. –Sonicwave ^talk 03:06, 2 October 2023 (UTC)

The template has been outdated for way too long now and it still uses the old specifications in the search result. Also it feels a bit excessive having only directors edit it. 245e (talk) 20:46, 9 September 2025 (UTC)

While we wait for Mojira to be usable again (which could take some time, considering that the migration was back in February and the situation has barely improved), I propose that this template links to https://mojira.dev, a Mojira mirror actually usable (https://github.com/misode/mojira.dev#mojiradev) instead of the official bug tracker. The mirror allows everyone to be able to see the tickets while still linking to the official websites for those who then want to (try to) interact with the ticket. - Zamburger (talk) 20:52, 28 October 2025 (UTC)

Seconded. mojira.dev is a far more pleasant experience, even given recent improvements to the main site (or not). I don't know why autoconfirmed users aren't allowed to edit this page, since other high-traffic templates aren't protected in this manner and there was no vandalism leading up to the protection, otherwise this would be a trivial change to make. - User-12316399 (talk) 12:01, 14 May 2026 (UTC)

Other high-traffic templates are all director protected, Markus did a sweep last year.  Nixinova  T ⁄ C  12:08, 14 May 2026 (UTC)

I'm inclined to agree, despite the unofficialness. The new bug tracker is a complete and utter unusable mess and has been for a year and a half.  Nixinova  T ⁄ C  12:08, 14 May 2026 (UTC)

User:Misode is a trusted enough face in the community, so the site should remain in safe hands. I wonder if we could integrate elements of the site somehow in a way that enhances pages, in much the same way as has been done for Chunkbase (browsable, scrollable embed in the Issues section of each page?) - User-12316399 (talk) 18:50, 14 May 2026 (UTC)

This template is used in many Legacy Console Edition version pages, but the resulting links are non-functional as the MCCE project was closed years ago. To make these links potentially more useful, I suggest adding an archive argument to replace the mojira:<bug ID> interlink with something like web.archive.org/web/0/bugs.mojang.com/browse/<bug ID>. A bot can then add archive=1 to all instances of this template linking to MCCE reports. Optionally, an archive-id argument can also be added to define a specific archive timestamp instead. --Capopanzo (talk | contribs) 01:31, 7 March 2026 (UTC)

Since it's project wide it's probably better to add it automatically for all MCCE links. I've added mojiraarchive: as an interwiki and added it for all MCCE links thru this template. Let me know if that needs to change / if more specific solutions are needed for some pages.  Nixinova  T ⁄ C  21:59, 14 March 2026 (UTC)

It looks like version page use the {{Fixes}} template, so Module:Fixes also needs to be updated to use the archive link for MCCE reports. --Capopanzo (talk | contribs) 23:56, 14 March 2026 (UTC)

Done there too.  Nixinova  T ⁄ C  00:46, 15 March 2026 (UTC)

Could you implement this for MCLG (Legends) bugs as well? Capopanzo (talk | contribs) 00:35, 11 April 2026 (UTC)

Done  Nixinova  T ⁄ C  02:40, 11 April 2026 (UTC)