Hearthstone Wiki

Hearthstone Wiki is currently under major revamp. All articles that have card lists or queries may not function properly for now. Please check back later!

READ MORE

Hearthstone Wiki
Advertisement
Hearthstone Wiki

Admin noticeboard archive[]

This is an archive of old issues reported to the admins. Please add any new issues to the new admin noticeboard.


Redirect equality issue[]

This is a problem where Semantic MediaWiki treats redirects as defining pages as equal. A specific example of the problem is that trying to assign Armor-related or Health-related to Property:Has tags results in the property storing Attribute (the page they redirect to), so any attempt to query for "Armor-related" or "Health-related" returns all pages with "Attribute", resulting in unintentional equality.

We are trying to disable this equality feature, but are running into some technical difficulties. We're continuing to work on the problem. oOeyes User-OOeyes-Sig.png 17:46, 17 December 2014 (UTC)

Card sizing issue[]

All HearthPwn cards were recently regenerated due to sizing issues, resulting in a smaller card size with greater margins to allow more room for certain card elements. A request is in with the HearthPwn team to reimport all card images with gold cards imported as non-animated static PNGs. I do not currently have an ETA for this. oOeyes User-OOeyes-Sig.png 17:46, 17 December 2014 (UTC)

Archiving the previous discussion reminded me: it would be good to get golden images for all cards, including those uncollectible cards which we never had golden images of in the first place, eg Mechanical Dragonling. Hearthpwn already has golden images up for all these cards, so it shouldn't be any extra trouble. -- Taohinton (talk) 21:27, 17 December 2014 (UTC)
Update: the image import is in progress now. We think it will take six hours to complete, but that's a rough estimate. oOeyes User-OOeyes-Sig.png 18:28, 19 December 2014 (UTC)
Looks like it's all wrapped up now. Apologies for the duplicate data pages; I asked for just the images to be imported, so that was a surprise to me as well. oOeyes User-OOeyes-Sig.png 03:21, 20 December 2014 (UTC)
Probably should have posted it here instead, but I've replied on my talk page. -- Taohinton (talk) 04:48, 20 December 2014 (UTC)
It seems like quite a large proportion of the images have not been updated. You can see the difference visually on pages like Priest#Priest spells; the old ones are bigger. Looks like at least 100 cards that still need updating. -- Taohinton (talk) 16:11, 21 December 2014 (UTC)
It seems the importer was accidentally left set up to skip the first 100 cards, probably to resume after a previous aborted import. This has been corrected, and a new import is complete. oOeyes User-OOeyes-Sig.png 21:39, 22 December 2014 (UTC)
Thanks. A quick check over the visual displays on the class pages suggests the process is now complete. -- Taohinton (talk) 21:47, 24 December 2014 (UTC)

Vandalism and RevisionDelete[]

The recent vandalism to Faerie Dragon is a particularly good example; we get a good measure of spam and vandalism on the site, and while it's not too hard to revert those edits, it still leaves a horrible mess in the edit history. Going through the history looking for actual edits to the page can become a tiresome task, and it doesn't seem right when half a page's history is just random IPs trashing the page. As I understand it if I were given the right permission I would be able to mostly hide vandalism edits from the edit history, thus making the true history a lot clearer and saving a lot of space. Could this be arranged? I would have no plans to use it for anything other than vandalism and spam, when reversion results in absolutely zero change to the page. -- Taohinton (talk) 00:28, 13 January 2015 (UTC)

The deleterevision right is misnamed. It does not remove entries from the history. It just lets you conceal one or more of these from unprivileged users: the username, the edit summary, or the text of the revision. Basically, you just end up with something that looks more or less like this: username removed. It really only comes in useful for pornography or some kind of copyright or NDA violation where we need to go the extra mile to remove all public visibility. I believe a lack of features to clean up histories is entirely intentional by the MediaWiki developers because they don't feel its usefulness outweighs its potential abuse against wiki philosophy. oOeyes User-OOeyes-Sig.png 01:52, 13 January 2015 (UTC)
Ah ok, fair enough. I remember encountering it on Wowpedia ages ago; couldn't remember exactly how the half-hiding worked, I thought it might place the edits in a show/hide region a bit like downvoted comments. I agree there's no value in the above functionality; guess we'll just have to put up with some rather pock-marked edit histories. -- Taohinton (talk) 02:46, 13 January 2015 (UTC)

Testing new "add section" link[]

From the top of this page. -Jerodast (talk) 18:27, 20 January 2015 (UTC)

Yay it worked. (/thread) -Jerodast (talk) 18:27, 20 January 2015 (UTC)

Tooltip card image quality[]

There's a noticeable fuzziness to the card image tooltips. I seem to remember noticing it a few months ago, but it's possible it's older than that. Basically the image is a lot 'fuzzier' and poorer quality than the actual card image, either the originals or the infobox versions. This isn't due to being too stretched (originals are bigger) or any other valid reason I can ascertain. If there's any way we could sharpen it up a bit, that would be great. -- Taohinton (talk) 01:53, 8 February 2015 (UTC)

We did recently change the image tools on the servers. It's possible the resizing is being handled differently now, affecting image quality. When I find a block of time for it (probably within the next couple of days), I'll try changing it so the original size is sent to the browser so it gets resized on the client side. The original sizes are almost certainly going to get downloaded one way or another into the browser cache anyway, so that would be probably more efficient. Hopefully, that will address the quality issues. oOeyes User-OOeyes-Sig.png 22:59, 10 February 2015 (UTC)
Okay, correcting myself. I rearranged some tasks so I could take care of this today. Any resizing should now be done by the browser. I don't know whether this will be an improvement or not. If it isn't, I guess I'll just have it display at regular size, even if it ends up getting cut off outside the viewport. oOeyes User-OOeyes-Sig.png 04:50, 11 February 2015 (UTC)
I'm not seeing any tooltips at all now. I tried this in both the Chrome browser I normally use and a first time visit via IE. - jerodast (talk) 18:11, 14 February 2015 (UTC)
Odd, stray semicolon sneaked in there. No idea how that got past testing since it should have broke the script completely, but it should be fixed now as soon as the JS cache updates. oOeyes User-OOeyes-Sig.png 19:26, 14 February 2015 (UTC)
I have only a guess as to what happened, but it's pretty clear I wasn't actually testing what I thought I was testing that day. Derp derp. At any rate, correct code should now be in place now. oOeyes User-OOeyes-Sig.png 20:47, 14 February 2015 (UTC)
No worries, looks great now! Thanks! - jerodast (talk) 21:33, 14 February 2015 (UTC)
Whatever you did worked; looking nice and sharp again now. Good job :) -- Taohinton (talk) 04:30, 16 February 2015 (UTC)
Since about the same time as these adjustments were being made, all tables seem to have lost the entire show/hide feature; as a result, all tables are auto-open and cannot be closed/hidden. An unintended side-effect? -- Taohinton (talk) 00:49, 17 February 2015 (UTC)
x_x ... should start working again shortly. This has not been my week. oOeyes User-OOeyes-Sig.png 21:35, 17 February 2015 (UTC)
It might just be me, but the tooltips haven't been working on my end for a few days now. Since last time this happened it turned out to be site-wide, thought I'd poke you to check if they've been knocked out of line again. -- Taohinton (talk) 01:57, 22 March 2015 (UTC)
No, something seems to have knocked them out, and I'm not sure what it is. The timing is awkward, though, because I'm in the middle of rewriting the tooltips as an extension to avoid certain inefficiencies with the script-only approach. I've decided for the present time to just focus on the replacement rather than try to fix something that's due to be replaced before long. oOeyes User-OOeyes-Sig.png 05:16, 22 March 2015 (UTC)
Looks like a configuration was sneaked in that changed some of the variables the script needed. Simple fix one I stumbled on the problem, so the script can keep working for the meantime. oOeyes User-OOeyes-Sig.png 06:19, 22 March 2015 (UTC)

Boss Armor[]

With the Grim Guzzler hero starting with Armor in his Heroic mode encounter, I wanted to add Armor to the card infobox - just for use with bosses. I was going to have a go myself, but I'm a bit concerned that adding a new property to the card data might be a bit more involved than just copying and pasting what's written in the template. The desired layout to {{Card infobox/layout}} should be something like: {{#if: {{{armor|}}}| {{#if: {{{heroicarmor|}}}| ! '''Armor:''' {{!}} {{{armor}}} {{armor}} (Normal)<br>{{{heroicarmor}}} {{armor}} (Heroic) | ! '''Armor:''' {{!}} {{{armor}}} {{armor}} (Normal) }} | {{#if: {{{heroicarmor|}}}| ! '''Armor:''' {{!}} {{{heroicarmor}}} {{armor}} (Heroic) }} }} -- Taohinton (talk) 17:31, 7 March 2015 (UTC)

Since this week has unfortunately gotten away from me, I've just taken the quick steps of implementing |armor= and |heroicarmor= as simple parameters that {{Card infobox}} just passes on to {{Card infobox/layout}}, and then added your code under the health row. Strictly speaking, they don't really need to be added to the actual data until or unless we need to either use them to select cards, such as with the custom tables, or are actually going to show them in the tables. If we do want anything like that, I imagine I can find a block of time in the next week to add it. oOeyes User-OOeyes-Sig.png 02:23, 8 March 2015 (UTC)
Thanks; that should be fine. Unfortunately, it seems my coding wasn't up to scratch, since neither |armor nor |heroicarmor are showing up in infoboxes. Can you spot the error? -- Taohinton (talk) 22:38, 10 March 2015 (UTC)
Seems to be working in my testing. Can you provide an example where it isn't? oOeyes User-OOeyes-Sig.png 00:07, 11 March 2015 (UTC)
Grim Guzzler. I've given Coren both normal and Heroic Armor, just to test (he only has Heroic in-game), but neither is showing. -- Taohinton (talk) 18:02, 15 March 2015 (UTC)
Oh, I didn't put support for it on {{Card data}}, only on {{Card infobox}} itself like the |devonly and such parameters. But since I have mostly caught up on other projects for the time being, I'll go ahead and give those a full implementation. oOeyes User-OOeyes-Sig.png 18:39, 15 March 2015 (UTC)

New Problem[]

A bunch of Secrets are now missing from the http://hearthstone.gamepedia.com/Secret page. A guess there's something going on with how the lists are stored? Maybe Nax related? — Preceding unsigned comment added by 75.180.38.42 (talkcontribs)

Not sure what triggered it, but it looks like it's just a caching issue. I'll run a bot over the card pages and lists to force the wiki cache to update, which should sort it out within a few hours or so. oOeyes User-OOeyes-Sig.png 16:40, 8 March 2015 (UTC)
It would be great to find a more substantial solution to the caching problems. They happen quite regularly, and due to the way tables and {{Cards}} work, they cause cards to disappear without a trace. This means you can't trust a list is accurate, as even if you're 100% sure it was properly created, cards may be temporarily hidden from it. This also leads to wasted edits from people trying to fix the problem by hand, and obviously makes the wiki a bit less reliable. Is there any way to prevent the issues from happening, or a more convenient way to fix them when they do? -- Taohinton (talk) 04:22, 20 March 2015 (UTC)
We're pretty much stuck waiting for the MediaWiki and SMW developers to improve their software, sadly, or pretty much trying to revamp the entire setup. It might be possible to do it with DPL (but I'm not sure it'd work with data pages), which does not use its own tables and so doesn't have these problems, but the drawback is that it's less efficient. I can't guarantee it wouldn't cause timeouts on larger card lists and such due to the way it pulls information. We might just be trading one big problem for another.
Another option is to maintain the list pages manually. A middle ground to that is where I could give you a template where you identify the data page names and it could make table rows from them, but removed/new cards would still have to be added manually. And that puts us back to being dependent on data pages where right now, {{Card infobox}} can currently handle everything. oOeyes User-OOeyes-Sig.png 05:11, 20 March 2015 (UTC)
Poor OOeyes! Busy March.
Would it be possible to use a bot to maintain the list pages "manually", aka maintain a static list that doesn't depend on the buggy caching? Essentially the bot would check the results of the query (weekly? daily? on command?), update any current cards, and add cards that weren't already in the list. It would not remove cards, so if the query comes back empty because of a bad cache we'd still at least have the same list as before instead of having everything disappear like it sometimes does now. We'd have to manually delete cards when appropriate but that seems like a rare enough occurrence to be fine. I guess you could look at it as essentially an extra layer of caching. I apologize for knowing nothing about wikibots and therefore only being able to offer a broad strokes algorithm which may or may not be feasible... - jerodast (talk) 17:13, 31 March 2015 (UTC)
Just to chime in in response to the previous comment, we definitely don't want to be maintaining lists manually. The volume of work required, plus the substantial margin for human error, would be a big step backward. We definitely need to be moving toward more automated processes, especially as the number of cards in the game grows, and not away from them. Adding properties to pages either via the data pages or {{Card infobox}} is far preferable.
So, if we're not going to be seeing any major improvements any time soon, one remaining question would be whether there is any way that an admin like myself could poke the gears when I notice cards missing? As it is it's usually a matter of waiting a few days to see if it's sorted itself out, then contacting you if it hasn't; which adds up to a lot of downtime, with faulty listings. If there's an automated process I can kick into action when necessary, that would help a lot to minimise the impact of the glitches. -- Taohinton (talk) 21:37, 31 March 2015 (UTC)
There's no special permissions required. It's just a matter of having an appropriate bot. I use the core version of pywikibot myself, just running its touch script over Category:All card data and the Category:Queries card data. It's a command line tool, though, and requires installing python, but I don't know of any more user-friendly tools that will actually do the right job. Autowikibrowser, for example, is easier to use, but for whatever reason, it will not automatically do the simple resaves that this needs. In automatic mode, it insists on skipping over any page where it doesn't make a change. oOeyes User-OOeyes-Sig.png 22:47, 31 March 2015 (UTC)
And when it is just a few, resaving just those few card pages that are missing in the lists, then resaving the pages with the lists where it's missing (or using the refresh link admins should see in the hover menu) should do the trick. oOeyes User-OOeyes-Sig.png 23:03, 31 March 2015 (UTC)

Image sizes[]

Images above a certain size (into the MB) seem to fail to display properly on wiki pages, although they display fine on the image pages themselves. I ran into this a while ago, but recent additions have highlighted it again. An example would be Mark of the Horsemen#Gallery. Assuming this isn't an issue exclusive to my browser, etc, is this due to an error of some kind or is it a more permanent limitation? Previously my solution has simply been to reduce the image quality before uploading, which seems to resolve the problem. If it is exclusive to my setup, obviously this may still be relevant for other similar users. -- Taohinton (talk) 01:18, 27 March 2015 (UTC)

A quick check isn't revealing any problems I can see. Could you post a screenshot and identify what browser you're using to help narrow down any particular issue? oOeyes User-OOeyes-Sig.png 04:52, 27 March 2015 (UTC)
Sure. Here's a screenshot - that's what I see on the page. Clicking the image link leads to the file page which displays fine, but the images never display on the pages themselves. It's the same for several images on the wiki, all above 4MB or so in size. All other images display fine. I use Safari, 7.1.4. I noticed this happening many months ago, so it's not new. -- Taohinton (talk) 01:05, 28 March 2015 (UTC)
I'm seeing this too. Looking at the browser source code I believe it's because the img tag uses a srcset attribute with no value for the 2x pixel ratio case. (I wasn't familiar with srcset, looking it up it's supposed to select the most fitting version of the image for your resolution/display.) Search the code for ",[two spaces]2x"; there should be an image source URL in those spaces. I will investigate further. - jerodast (talk) 17:35, 31 March 2015 (UTC)
Never mind, I guess I can't investigate further. I was thinking there was a template or something but it's just down to the way the software translates File elements to HTML. Good luck! - jerodast (talk) 17:47, 31 March 2015 (UTC)
There's a fix coming in an update tomorrow that I think might solve this issue, but I'm not entirely sure the issue being addressed is the cause of this problem. Please let me know if this issue is still a problem after a couple of days so that I will know one way or the other. oOeyes User-OOeyes-Sig.png 18:26, 31 March 2015 (UTC)

Stacking infoboxes[]

It seems Blackrock Mountain will bring a few multi-boss fights. I'm thinking about how to handle this, and one of the best options at present would be to have the infoboxes for each boss on the main encounter page. Alternatives all seem to involve bypassing the infoboxes in favour of a table or such, which wouldn't look or feel as good, wouldn't show any Armor, and perhaps more importantly would mean a substantial deviation from the standard layout on a fair number of the encounter pages. I'd certainly like to try the infobox approach first.

The main issue is that I'd like to have two (or more) infoboxes stack vertically; not side-by-side. Can this be done, without massively disrupting the text on the page? I also wanted to check that doing this wouldn't mess anything up data-wise, with multiple card data linking to the same page -- Taohinton (talk) 07:59, 31 March 2015 (UTC)

Unfortunately, the data would be a problem. Getting data for multiple cards on the same page requires using subobjects, but subobjects can't be put into categories, which would require most if not all queries to have to be rewritten. They are also harder to debug and require more kludges for certain tasks, such as with the properties like Has tags that can have a list of values for each card. It's doable, but it's not my favorite to work with.
Another approach we could use, though it is also somewhat kludgy, would be to have the data set on subpages of the main encounter page. With a relatively small amount of work (compared to the first option, anyway), we could have the tables and other templates still link to the main encounter page, and then the infoboxes could be transcluded onto the main encounter page by treating them like templates. Visually, stacking them is relatively trivial. oOeyes User-OOeyes-Sig.png 18:51, 31 March 2015 (UTC)
The latter approach sounds doable then? The key thing we need is a single page with multiple infoboxes, obviously each pulling its own data. We don't currently have any tables/sorting of bosses themselves since they're all |devonly (although it might be nice to change that one day). In terms of tooltips, I think ideally we'd have the main page show the tooltips/portraits for all infoboxes (or at least one), but it's not absolutely vital.
If you could demonstrate or explain the form required, I'd be happy to play around with it and see how it works for the pages in question. -- Taohinton (talk) 21:26, 31 March 2015 (UTC)
To play with it from a purely visual perspective, one approach that should work would just be to put {{Card infobox/layout}} calls inside a floating div something like this:
<div class="float: right; clear: right;">
{{Card infobox/layout
  | (info here)...
}}
{{Card infobox/layout
  | (info here)...
}}
</div>

To make it work with the data will take some adjustments: a new property defining what page to link to and sadly some kludgy stuff to make sure the properties only get set on the subpages. Say for a fight with two bosses, it probably end up looking something like this:
  • On a page called "Encounter/Boss name 1", you'd just have "{{Card infobox|datapage=Boss name 1|setdata=<includeonly>no</includeonly>|targetpage={{BASEPAGENAME}} }}".
  • On a page called "Encounter/Boss name 2", you'd just have "{{Card infobox|datapage=Boss name 2|setdata=<includeonly>no</includeonly>|targetpage={{BASEPAGENAME}} }}".
  • On the actual page called "Encounter", it'd start with "{{/Boss name 1}}{{/Boss name 2}}". (If clear: right gets added to the infobox, the div wouldn't be needed.) oOeyes User-OOeyes-Sig.png 23:22, 31 March 2015 (UTC)
OK, well let me know when the 'kludgy stuff' is set up, and I'll make the changes to the non-kludgy stuff :P -- Taohinton (talk) 00:35, 2 April 2015 (UTC)
Re: this issue, I should mention that the first multi-boss fight will be released on Thursday, so we need to have a solution set-up before then. -- Taohinton (talk) 18:24, 4 April 2015 (UTC)
The kludges are in place on the infobox, so it's possible to begin setting up the encounter pages as described above. There will also need to be some updates to tables and possibly some other templates before any pages set up this way will link correctly, but I need to let a bot job complete before I can do any of that, so I'll take care of that later tonight. The infoboxes should also be set up to stack now, but the CSS cache is being slow to update today as well, so that isn't working quite yet, but should soon. oOeyes User-OOeyes-Sig.png 22:39, 8 April 2015 (UTC)
With the bot done with the actual card pages, I updated the templates that use the data now, though I suppose {{card}} is probably the only one that really needed it. I'll get the bot going on the pages using those templates, just in case. This isn't anything that anyone needs to wait on editing for, though. oOeyes User-OOeyes-Sig.png 07:50, 9 April 2015 (UTC)
Thanks - I've implemented this with Ragnaros the Firelord (boss) and it seems to be working fine. To my knowledge, that's the last bit of tech work that needs doing for now, bringing us up to speed with BRM. -- Taohinton (talk) 20:12, 9 April 2015 (UTC)

Data import[]

I'm not quite ready yet to tackle the debate over a full-on data import, but if it's possible to get it done fairly soon, it would be very helpful to have a limited import done of the card data and images for the remaining boss cards. I've been doing all this work manually for the last 60+ hero powers, bosses, cards... and it's a hell of a lot of labour. I'd still have to do at least half the work, but an import would save me a lot of hours.

It would only be for about 60 cards; the Blackrock Mountain boss cards, not including hero powers or bosses themselves. I've already done all the normal cards and bosses and hero powers. If any excess data did get imported though, it probably wouldn't be a problem to delete/undo it, so if it's easier they could just import all the uncollectible BRM cards and I can sort out the rest.

My main concern (and why I didn't just ask for this right away, and save myself a lot of work) is the timetable for this happening. It shouldn't be too complex an import, but with the adventure coming out in 2 days' time, it would need to happen fairly soon. If it takes longer than that, I'll probably just have to do the work by hand.

A less urgent but related import is for the golden card images for all the new cards. -- Taohinton (talk) 07:59, 31 March 2015 (UTC)

Golden card images are also needed for the three modified cards: Ysera, Arcane Missiles and Avenging Wrath. I can't download these manually since the originals are animated. -- Taohinton (talk) 22:10, 1 April 2015 (UTC)

I've been told we can do the boss import. I'll make sure to request the gold card import too. But I'm afraid I don't have any ETA on this currently; they aren't sure when they'll be available to get this rolling. oOeyes User-OOeyes-Sig.png 21:03, 2 April 2015 (UTC)
Hmm, okay. Would you care to speculate on whether it will be days or weeks? Sounds like I'll have to do the next wing or two by hand, but the last two wings have the most cards of all. I already went gone ahead with the other cards for the first wing, but I'm trying to make a compromise between getting rid of the rest of the redlinks and completing the wiki, and not burning myself out doing too many more 12 hour editing shifts. -- Taohinton (talk) 21:27, 2 April 2015 (UTC)
They've decided to do a little schedule reorganizing, so they've actually just kicked this off now. It's easier for them to just import all images, so that's what they're doing. As for card data, only new card information should be going up, but if any data pages were added manually, we'll probably end up with some duplicates to clean up since the page names won't be the same. I'll be ready to run a bot resave tonight if it should be needed. oOeyes User-OOeyes-Sig.png 22:04, 2 April 2015 (UTC)
Okay, thanks. It would be great to have a detailed conversation with someone at some point to sort out what can and can't be done re: organising future data imports. Ideally I'd like to build an update process for the wiki (and its related imports) which is as smooth, automated and problem-free as possible, since the current model requires a lot of nitty gritty fiddling and very specific familiarity to avoid miscellaneous errors and content getting lost.
Until that can be arranged, I'm trying to devise a system that minimises the amount of disruption and unnecessary deletion/re-imports to the wiki, given the current import behaviour. Please hold off on any bot work/duplicate deletion for the time being, since I'm in the process of going through the imports to assess the situation. -- Taohinton (talk) 17:54, 3 April 2015 (UTC)
I finished the corrections late last night, and everything should now be ship-shape. It would still be great to talk to someone about the future at some point. -- Taohinton (talk) 18:23, 4 April 2015 (UTC)
I'm going to suggest we try this: create a page Project:Data imports that has a list of what you're looking for (such as perhaps no enchantments) that I can show to relevant people, and then we can modify it according to what's possible and practical until we get to an agreement. Getting regular imports in motion again is going to require coordinating with several people, and I think to get it done correctly with less of these cleanup issues, we're going to need to have the specifics laid out in a simple list without clutter. oOeyes User-OOeyes-Sig.png 18:57, 4 April 2015 (UTC)
Sure. Right now I'm starting to get pretty busy with IRL stuff, and we probably won't need another big import until the next expansion comes along (a few months), so I might not get onto it right away. I will be happy to do so when I get the chance though. -- Taohinton (talk) 20:19, 9 April 2015 (UTC)

Tooltip craziness[]

Another non-critical problem. It gets much worse than this sometimes ;) Multiple and often super-sized tooltips, stuck in static positions on the page, although I can move them to some degree (often several at once). It seems to happen quite regularly, so far just on Blackrock Mountain - I think - and seems to get worse over time. Reloading clears it. -- Taohinton (talk) 23:07, 31 March 2015 (UTC)

Vandalism report[]

User:Zaros21 has had a busy day. In all likelihood his entire contribution history should be reversed. - jerodast (talk) 20:38, 1 April 2015 (UTC)

Hey Jerodast. Just came on to find this, smh. I've reverted the edits, deleted the images and blocked him for a good while. Thanks for the report.
For future reference, this page doesn't actually notify me in any way when it's edited, so the message from you didn't reach me - I found the vandal myself later on. So, if you come across any persistent problematic behaviour in the future, just leave a message on my talk page (which will result in an email for me) and I'll take care of it right away. -- Taohinton (talk) 21:10, 1 April 2015 (UTC)
Ah okay. I thought perhaps the admins had this page on their permanent watchlist. Is there no centralized place to report urgent things to the "first available admin"? - jerodast (talk) 22:52, 1 April 2015 (UTC)
Well, it should be this page, but I'm an admin and it doesn't notify me in any way. I suppose I could take everything else off my watchlist, and set it for email notifications - but I quite like using my watchlist as a watchlist! Unless there's some background shenanigans I haven't been linked into? *pokes OOEyes* -- Taohinton (talk) 00:35, 2 April 2015 (UTC)
Haha, I forgot not everyone has e-mail notifications on for their watchlists. I do but I'm sure I have but a fraction of the pages on there that you guys do! It does seem like there should be some Big Red Button for vandalism reports but hopefully Zaros was just inspired by a fit of April Fool's energy and this will not be common :) - jerodast (talk) 00:41, 2 April 2015 (UTC)
No, I'm afraid this page has no special voodoo or mechanics behind it. I just use my watchlists and look for updates to all the admin noticeboards I have to keep an eye on. oOeyes User-OOeyes-Sig.png 02:02, 2 April 2015 (UTC)

Assorted issues[]

Perhaps due to recent adjustments, a couple of minor bugs have popped up:

  • The images produced by {{Cards}} are no longer clickable; they do not link to the related pages.
  • {{Card}} is no longer producing a {{clrl}} after the image. This can be added manually after calls but is obviously far less convenient.

One quick question regarding stacking infoboxes: is it necessary for all infoboxes to be on their own subpages, eg Ragnaros the Firelord (encounter), or is the setup for Lord Victor Nefarius (main page linked to data page, plus a subpage linked to data page) okay? If it's not okay, what problems does it cause? Since we're not using any tables, etc, for bosses at present, as long as it doesn't break the system it's probably more convenient, especially since it produces a tooltip. -- Taohinton (talk) 21:01, 12 April 2015 (UTC)

Yes, the main page having one of the infoboxes directly would work fine. I'll take a quick look at {{Card}} and see what happened. oOeyes User-OOeyes-Sig.png 22:58, 12 April 2015 (UTC)
Okay, I just somehow missed {{Cards}} in the update. I have the bot resaving the pages where it's used now. I've added {{clrl}} to {{Card}}. No idea when/if it got removed; hopefully it won't cause any undesirable side effects. oOeyes User-OOeyes-Sig.png 23:15, 12 April 2015 (UTC)
Thanks for the speedy fix. I'm not sure what happened to change the way {{Card}} outputs, but it seems it wasn't just the lack of a {{clrl}}, since that (obviously - I should thought it through a little more) produces a clear after every single call, making lists of individual cards stack vertically (not good). I should instead have said "no longer automatically putting any following text onto the next line." - I've therefore reverted the edit to {{Card}}. Something has definitely changed, resulting in things like this in every instance where it used to have an automatic line break/clear in there, but perhaps it was in some distant part of the wiki's workings rather than the template itself.
Ideally it would be great to have it back the way it was, but until then I can simply add {{clrl}} after each {{Card}} call/list of calls, which will at least fix the current problems.
Regarding updates: Both the image size bug and the multiple floating tooltips bug are still occurring for me. Also the latter is definitely not limited to Blackrock Mountain, but occurs site-wide. -- Taohinton (talk) 22:49, 14 April 2015 (UTC)
I'll look into the Card issue as soon as possible, as nothing immediately comes to mind that would have changed the behavior. I believe I have the tooltip issues fixed in the new extension, so those should get resolved when we can switch over. Waiting right now for dev to review it and set it up as an optional extension for us. oOeyes User-OOeyes-Sig.png 05:24, 15 April 2015 (UTC)
I've just noticed that the bug with {{Card}} only happens when it's followed immediately by a link - the [[ seems to act like a magnet. For example:
Steady Shot(229).png

linked text


Steady Shot(229).png

non-linked text

However, this is still a change, since it didn't use to behave this way. -- Taohinton (talk) 01:40, 19 April 2015 (UTC)

A quick look at the source shows that the second case is splitting them into two paragraphs, while the first case combines them into one. That tells me the MediaWiki parser itself is responsible rather than any browser or style issue, so it must be a side effect of a change between MediaWiki versions. I tried something to trick the parser into splitting both into two paragraphs, but it just made the problem worse. I don't have any other ideas that wouldn't have worse side effects, and we really can't get into modifying the parser on that level. I apologize for the inconvenience, but at least for the moment, I'm not seeing an easy workaround here. oOeyes User-OOeyes-Sig.png 21:28, 19 April 2015 (UTC)
Re: Multiple tooltip bug. I modified the script with a possible fix for this, as we encountered some kind of strange bug with the extension that didn't show up in any testing. Since I don't know yet when I'll be able to fix that, I decided to try to fix this issue in the script and put it back in place for now. oOeyes User-OOeyes-Sig.png 22:19, 4 May 2015 (UTC)


Tooltips for references[]

Copied from User_talk:Taohinton:

Can we get something like on http://what-if.xkcd.com/ where when you click a reference, instead of jumping to the end of the page, a textbox opens inline where you can read, select text and click links? This would be hugely beneficial for the Advanced rulebook rewrite - you could look at references inline without having to lose your place and disrupt the flow of reading. --Patashu (talk) 04:57, 6 May 2015 (UTC)

I agree this would be very handy if doable. Wikipedia has something similar, where rather than clicking you simply mouse over the reference to view it, eg here. -- Taohinton (talk) 16:02, 6 May 2015 (UTC)

I'll look into this more closely later, but MediaWiki is currently on a even-numbered release. As you may have heard, we skip those because those tend to have the newer experimental features that are usually more beta-quality. Odd-numbered releases tend to be where those new features get refined and fixed. But if Wikipedia has it, it's very likely Gamepedia will support it as well. If it's attached to or requires the current 1.24 release, we probably won't see it until 1.25, though. oOeyes User-OOeyes-Sig.png 21:18, 6 May 2015 (UTC)

Ice Block[]

For some reason Ice Block is not showing up in the table or {{Cards}} output on Immune. All other cards seem to function fine, and Ice Block does show up if the 'Secret' ability is specified instead of 'Immune', so it is in the system. -- Taohinton (talk) 23:47, 18 May 2015 (UTC)

Looks like it is now. Must have updated between now and then. oOeyes User-OOeyes-Sig.png 04:55, 25 May 2015 (UTC)

Multiple calls and Card infobox[]

An editor recently produced a Thai translation for Armor Plating. The problem is that by calling {{Card infobox}} it's effectively created a second copy of the same card, resulting in Armor Plating being listed twice in tables. Is there a way to call the template without having this effect? -- Taohinton (talk) 15:03, 24 May 2015 (UTC)

There's a |setdata parameter. Using |setdata=no should prevent this, and I've made the appropriate edit. oOeyes User-OOeyes-Sig.png 04:55, 25 May 2015 (UTC)

Card infobox error[]

If you check Flesheating Ghoul you'll see the quotes in the infobox display of the card text/flavor text have gotten messed up. There should be no quote at the start, but quotes surrounding 'Flesheating'. Since the data is precisely correct, presumably this is a {{Card infobox}} error. Normally the card text is bold, and the flavor text in italics; it seems like the quotes have interfered with that in woefully predictable wiki-fashion. Presumably other cards using quotes might also be affected. -- Taohinton (talk) 20:25, 3 June 2015 (UTC)

Changed it to use CSS rather than the wikicode for bold and italics, and that seems to have fixed it. oOeyes User-OOeyes-Sig.png 08:28, 5 June 2015 (UTC)

Footer bug[]

The bottom portion of some pages seems to have disappeared, covered prematurely by the Curse footer. For example, while editing some pages the 'save page' and 'show preview' buttons (and everything below them) are hidden entirely, making it impossible to edit without knowing the keyboard shortcuts. In some cases the bottom of the content page itself is hidden, in others the editing buttons or template/hidden category/parser information. This happens on some pages and not others, and appears to respond to editing in some cases. I haven't noticed this before today.

Screenshots: while editing, while reading (template is cut off) -- Taohinton (talk) 00:54, 5 June 2015 (UTC)

There was an unclosed <div> in the {{Heroes}} template. Presumably, MediaWiki tried to close it itself, but in the wrong place, which was closing the entire content section early, which led to weirdness in positioning nearly everything below it. oOeyes User-OOeyes-Sig.png 08:28, 5 June 2015 (UTC)
Thanks. I should have guessed, given its sudden arrival. -- Taohinton (talk) 22:51, 6 June 2015 (UTC)
Advertisement