Hearthstone Wiki talk:Admin noticeboard/Archive01

Archives

• Noticeboard
  • Current page
  • Archive 1
  • Archive 2
  • Archive 3
  • Archive 4
  • Archive 5
• Discussion
  • Current page
  • Archive 1
  • Archive 2

Style guide

--> moved from Hearthstone Wiki talk:Admin noticeboard

While there are many pieces of the site's infrastructure that could do with being developed, one notably missing element is the Manual of Style or style guide. There are redlinks to it in Help:Contents but apparently no actual guide. Such a guide is of course instrumental in creating a consistent and good-looking site, and is well-worth bringing in as early as possible, so that a good style can be established. The basic principles of most wiki style guides I've seen are fairly similar (including Wikipedia and Wowpedia) but are often contrary to what people expect in terms of things like sentence case vs title case. In any case I'd highly recommend importing/establishing one, even if it's very simple to start with, to get a good basis down for the site's emerging style. In the meanwhile shall we assume something similar to these wikis? -- Taohinton (talk) 00:28, 15 September 2013 (UTC)

Style guides are a content issue at their heart, and thus I consider this a community issue, not an administrative one.

Also, we're transitioning most of our help material over to the Gamepedia Help Wiki now that we have so many wikis, so the current help pages are not here to stay. This has been delayed pending some internal discussion about how to handle the transition; it's likely the pages will be transcluded onto this wiki. But the current pages will be changed in the near future.

That said, I strongly disagree with characterizing them as instrumental. In fact, I consider them barely helpful for two reasons:

1. Well-written and structured articles are style guides by example, and are in essence, the style guide I believe most editors look for. I believe few editors even bother looking for one in Help or Project namespaces.
2. A lot of our game wikis are on the smaller side, community-wise, and this means editors and admins tend to come and go. Games change over time, and article styles and structures tend to change with them, but any formal style guides are commonly forgotten in these updates as new editors and admins are rarely even aware of them. So a good editor would still need to find a current well-written and structured article to confirm the style guide even if he checks it, or worse, he'll fail to do that and write articles in an older style. Complete worst-case: he begins reverting all articles to an outdated style.

In essence, we did have a style guide by example when we started the editing contest that ended at the beginning of the month, and inconsistencies still cropped up. I don't believe any amount of further preparation would have prevented that; the need to clean up is just an inevitable consequence of any rush to populate a wiki's content. As there have already been attempts by community members that haven't garnered much discussion, I believe the next step is for a motivated editor to jump in and begin standardizing articles. Action sometimes has a tendency to motivate discussions that talk page messages fail to do, or there really just aren't enough editors here concerned with it. The only way to find out now is for someone to be bold. OOeyes (talk) 22:56, 16 September 2013 (UTC)

I understand what you're saying, and of course editors jumping in and being bold is pretty much the only way anything ever happens on a wiki. Nonetheless, as with anything, a little discussion and consensus doesn't hurt. A good style guide serves to help bring new editors up to speed and works to end and prevent edit wars and needless arguments over details. I don't think sites like Wikipedia have made a mistake by having a style guide, and I don't think a single page establishing a few basic standards would be a bad thing. However, I get your point. This is currently a very small wiki/editor-base and very little in the way of a standard has yet been developed.

I do feel though that there is the need for a place to discuss these things; not only because I prefer to discuss things and seek a consensus than to unilaterally overhaul the site to my personal tastes, but also because in my experience, no matter how many instances you might find of a certain word (eg, 'Mage') being capitalised/non-capitalised on a site, there will always be editors who come along and do the exact opposite, often for quite understandable reasons. At some point it becomes beneficial to be able to say that such a thing is our working standard. My thoughts are that such a style guide would serve as a focal point for this discussion, and also as a work-in-progress reflection of what has been arrived at so far. Also, there are points which it would serve to standardise one way or the other, but which I personally have no particular preference as to. Do note also the difference between a style guide and a boilerplate; boilerplates do tend to get out of date (though in truth there's little need for them to), while style guides ("use sentence case in section and article titles") can usually be relied upon to last a fairly long time. I'm not suggesting a boilerplate, although again discussion along the lines of what comprises a page (as has already been tentatively started on the main community discussion page) is in my opinion well worthwhile.

Anyway, regarding jumping in, I did. I'm not sure how much time, energy and motivation I'll get spare to put into the site, but I'm very happy to be part of forming it :) -- Taohinton (talk) 00:09, 19 September 2013 (UTC)

Ah, I did think you were referring more to a boilerplate, given the focus on standardizing articles and the fact this wiki is mostly card pages. Some wikis do use the term style guide that way, which makes such confusion easier. We can try the type of style guide you suggest. At the moment, I think placing it in the Project namespace might be best as the Help namespace is going to get something of an overhaul when we finish up our plan for shifting to the help wiki, so it's not clear currenly how to fit a style guide in there. Alternatively, if we keep it simple enough, it could just be added to the Community portal. OOeyes (talk) 00:28, 19 September 2013 (UTC)

Card data problems

There is a simple error that is affecting a number of card pages on the site. The problem basically seems to be that there are multiple cards with the same name; the way that the site's card data is updated and imported means that this cannot be changed manually, or at least when I try, someone ends up saving over it with updated (incorrect) data shortly afterwards anyway. Since I have no idea of the technical processes for all the card data stuff, I'm posting this here.

Examples include Mirror Image - which shows the infobox data for the minion and not the spell itself - Illidan Stormrage and Lorewalker Cho - which show the hero versions encountered during the initial 'missions', rather than the playable cards - and Lord Jaraxxus - which shows the hero he becomes when played, rather than the card itself. All of these errors mean the corresponding summoning cost, rarity, etc, is not listed, and the hearthpwn link is wrong. It's not too hard to create separate pages where needed - such as Mirror Image and Mirror Image - but none of this functions without the correct data being sent there. As it stands, such pages are misleading, confusing and/or simply failing to provide basic card info. Any ideas? -- Taohinton (talk) 21:26, 19 October 2013 (UTC)

I've already set things up wiki side to allow for card IDs to be added to the data page names, but the importer hasn't been updated to take advantage of this yet. But because of this very problem, moving the data pages automatically is probably not a viable option, and moving them manually is probably too time-consuming to even consider, so it'll probably be necessary to clear them out and reimport. That requires more coordination between different teams, but I'll see about arranging some time between the different teams to get this done ASAP.

This fixes it only on the data page side, but I've added features to Template:Card infobox to sort out the issue on the regular card page side. The documentation there explains a couple of options for how to pull the desired card data onto a page. OOeyes (talk) 22:33, 19 October 2013 (UTC)

The above also seems to go for all the buffs - categorised as 'Enchantments' - granted by spells and minions. I'm not sure we want to bother actually having a separate page for each individual buff; we could, but since we'll be explaining all the relevant info on the related/buff-creating card's page anyway, it seems simpler to leave that to the database sites. Either way, these cards are also in need of sorting. -- Taohinton (talk) 21:58, 29 October 2013 (UTC)

Creating content pages for the cards is optional. I don't there's any harm in having the data pages, though, in case the community changes its mind on this later. I made some changes for now so that enchantments go in a separate card and won't be pulled up by the current templates, at least once everything catches up. This will no doubt result in the infoboxes disappearing on some pages where the enchantment data is in place rather than the regular card data, but I'll work on arranging the importer update and reimport to solve that. I apologize for the delay on it so far; I was temporarily sidelined by some medical trouble. OOeyes (talk) 04:08, 30 October 2013 (UTC)

I agree, having the data pages is fine. Sorry to hear about your medical trouble. -- Taohinton (talk) 22:52, 6 November 2013 (UTC)

Any update on this? We're into December now, and it would be great to have this fixed before open beta. -- Taohinton (talk) 13:01, 3 December 2013 (UTC)

I haven't heard back yet. I'll talk to my boss today and see if he can get this arranged soon. OOeyes (talk) 14:35, 3 December 2013 (UTC)

It's looking like we're going to be able to get to this tomorrow. I'll let you know if anything comes up. OOeyes (talk) 01:03, 12 December 2013 (UTC)

Apologies. This is going to take a little more work than anticipated. OOeyes (talk) 05:03, 13 December 2013 (UTC)

These issues should have been resolved. Can you confirm? - Smokie (talk) 02:05, 17 January 2014 (UTC)

Well, the card data seems to be successfully split (as far as I've seen) so that should be a yes. We are however still missing more than 200 card images; I assume these will be uploaded some time soon?

A related issue is the infoboxes. I still can't get |datapage to work for {{Card infobox}}, and while we can specify using name, type, rarity, etc, this is a messier solution which is open to possible problems in the future if other cards/enchantments get added with the same name, which also kinda misses some of the point of adding individual numbers. -- Taohinton (talk) 16:42, 18 January 2014 (UTC)

|datapage seems to be working fine. Are you using the full name, i.e. Data:Cards/Barrel(376)? OOeyes (talk) 15:19, 19 January 2014 (UTC)

Also, the dev team is aware of the missing image issue. I've been told it affected Hearthpwn as well. They're working on it. OOeyes (talk) 16:24, 19 January 2014 (UTC)

Heh, thanks - I could have sworn I already tried that, but I guess I must have made a typo or something ;) Out of interest, was there a reason you chose to specify card type rather than just use |datapage, on Spellbender and Spellbender? -- Taohinton (talk) 19:34, 19 January 2014 (UTC)

Only because it was quicker than looking up each data page. We're probably not too likely to have cards of the same name be the same type, but yes, using datapage would ultimately be a more defensive choice. OOeyes (talk) 21:22, 19 January 2014 (UTC)

Some (but not all) cards that are marked with |devonly=true or |current=false are still showing up in lists, such as on Minion and Spell. -- Taohinton (talk) 21:09, 20 January 2014 (UTC)

Resaving the data page for these cards and using the refresh option in the menu on Minion and Spell is clearing them from the lists, which indicates that the cache is just being slow to update for some of these. I'm testing another approach to this on some other wikis that should reduce this problem quite a bit. If it works without any major problems, I'll adapt the templates here when I can. Otherwise, I might also be able to set up a bot to occasionally resave the data pages to help with this. OOeyes (talk) 23:25, 21 January 2014 (UTC)

Any update on the still missing card images? I've just had to post a notice on Sylvanas' page since the out of date image still shows her old mana cost. HearthPwn seems to have all the updated images now. -- Taohinton (talk) 08:09, 7 March 2014 (UTC)

On a related note, we could also do with having the correct data (and images) for Nat Pagle and Tinkmaster Overspark uploaded, following the patch. -- Taohinton (talk) 21:34, 12 March 2014 (UTC)

Removed cards

Cards which have been removed from the game are still being included in card lists, and obviously shouldn't be - for example Priest still features cards like Fade, Mental Collapse and Greater Heal in its lists. I'm guessing this just needs a little adjustment at the card data end, to tag the card(s) to no longer be included in regular lists. -- Taohinton (talk) 13:31, 28 October 2013 (UTC)

I've added new parameters to {{Card infobox}} to handle removed and also the unusual special-purpose cards in the database. Due to caching issues, resaving the data pages after adding these parameters to the content pages will often be necessary. OOeyes (talk) 04:11, 30 October 2013 (UTC)

Most of the pages I've marked as such are still showing up in lists, but since a couple have now removed themselves, hopefully the others will follow suit in time. Re-saving the data pages hasn't worked to make it happen straight-away, but I suppose might be part of the process. The infoboxes on those dev-only and non-current pages which have (now) correctly removed themselves (Server Crash and Greater Heal) have also disappeared; hopefully this is only temporary, since we still want that info on-page even if the card has been removed, etc. -- Taohinton (talk) 22:52, 6 November 2013 (UTC)

For marking the credits and tutorial hero cards, we don't have an exactly matching tag, but devonly seems more appropriate, in that the card is not and never was available to players to collect. I'll use that tag for those cards unless you want to add separate parameters. -- Taohinton (talk) 12:45, 7 November 2013 (UTC)

I'm not sure it's worth being that specific in the infoboxes/data; that information could be covered in the page text since these are exceptional cards anyway. The primary concern is just to get them out of the regular card lists. OOeyes (talk) 14:35, 3 December 2013 (UTC)

Agreed; I just wanted to check I wasn't going to be messing things up for future sorting. -- Taohinton (talk) 16:41, 3 December 2013 (UTC)

Cards missing from lists

Ice Block, for example, is missing from the Secret page. As discussed previously, with how data is imported I don't think there is a way to add it manually.--Aerand1R (talk) 11:12, 18 December 2013 (UTC)

Ice Block has been affected by the name collision issue with the current import process; the enchantment data overwrote the proper card data. The appropriate dev team is aware of the issue, but I don't know yet when they plan to adapt the importer. Until then, all versions should be in the page history of the appropriate data page. I've fixed this one temporarily by undoing the last edit to Data:Cards/Ice_Block. OOeyes (talk) 20:02, 18 December 2013 (UTC)

Visual changes to the site

I understand many of these changes are designed to make the site match hearthpwn.com, and therefore I expect they won't be up for debate. However, I have to say I'm not very fond of the colour changes for the site. The warmth and tone has been removed, making a drabber and somewhat sun-bleached version of the site, surmounted with a slightly strange reddish-grey(black?). I don't mean to criticise anyone's choice of colour scheme - only to provide my feedback on how it feels to me.

For comparison, try switching between a page on the official forums and our own front page. Our pages are now almost white, met with the odd greyish-black header sections, as opposed to the official site's warm earthen tones. For me, it's taken away much of the warmth that used to be in the site's appearance.

Also, while I get the desire to brand the Curse sites with the same brush, in the process we've sacrificed much of our similarity to the appearance of both the official site and the game itself, which is a bit of a trade-off. The game features the earthen red and sand colours throughout, as can be seen here, here and in battlefield shots such as those on Hearthstone. We had something pretty close to this, but have exchanged it for a very different look.

While colour-matching isn't the be all and end all to wiki design, continuity with the feel and colours of the game is a fairly good idea, which is probably why Wikia is so specifically matched to them. I also think there's some value to warmth and aesthetics, both of which I feel have suffered. -- Taohinton (talk) 23:47, 14 January 2014 (UTC)

Hey there! These are definitely some thoughtful suggestions. I'll be sure they get passed along to the wiki manager in charge of the style here on Hearthstone Wiki. CrsBenjamin (talk) 16:12, 15 January 2014 (UTC)

I agree that it needs to be improved upon, and making it feel a bit warmer is definitely not a bad idea. The primary goal I had in mind when giving the wiki a bit of a facelift was to make some quality of life improvements. The first thing that had to go was the textured background. Textured backgrounds certainly have their place in webdesign, but it just didn't feel like the right fit for the wiki. I'm not basing this off personal opinions either; Before I began editing the styles, I asked several people from different backgrounds how they felt about the look of the wiki. The background was the most common problem that people had. Once the background was removed, the text-shadows and drop-shadows no longer had a reason to exist. They were there because content was harder to see on the textured background.

Why the switch from red to brown/black though? I didn't really give that much thought to be honest, it just seemed to fit nice together. Looking at it again though, warming it up a bit doesn't look to bad! What do you think of it?

I think the next logical transition is to get some of these colors figured out, so we can get some consistency flowing. I'm not happy about the difference between the boxes on tournament pages and card pages - I just ran out of time yesterday to do anything about it. Fluxflashor (talk) 16:58, 15 January 2014 (UTC)

Sorry I haven't gotten back to you on this - I've been a bit busy and somehow this ended up bottom of the list of things to deal with! I think the change is a definite improvement - the site feels a lot more friendly and inviting now. However, in considering what good colours would be, I have to say the original colours for the site were very good, with a redder header colour and the right sand colour for the background. In truth, my preference would be to restore those colours - they're good, welcoming and consistent with the game and official site; I don't know who came up with the scheme but it's my favourite so far out of all the Hearthstone sites and wikis I've seen. What do you think? -- Taohinton (talk) 17:48, 20 January 2014 (UTC)

I wasn't a very big fan of the old wiki style since the very beginning, so I may just be a little bit biased in this department, but I validated it with outside opinions. The official Hearthstone site has a great overall feel to it, but it also has one thing that we didn't: a very stylized interface. On the wiki, the deep reds were simply contained within a border, and outside of that there was this parchment background which made text look terrible. The text-shadow css property was overused on the wiki (almost every piece of text had text-shadow!) and I feel that overall, readability of the wiki has improved quite a bit since removing it.

What are your thoughts on something like this? It's slightly warmer, but still works with the current background color. Or for fun this. Same color, but I added some borders which are much like the in-game ones. The second one doesn't work that well.

We do need to find something that works though so that I can go through an make sure everything can fit the same design. Few areas on the wiki atm that need some attention (infoboxes, tables).

The focus of a wiki is content, and the design should only enhance it, not ruin it. -- Fluxflashor : (Talk) 14:37, 21 January 2014 (UTC)

Just to be clear, I was only referring to the colours for the headers and background - all the changes to the text-shadow, tables, etc, are fine by me!

That new colour for the headers is great :) I'm not sure about the borders; I think it probably looks better in the first one.

I would still say that warming up the background colour a little would be good; I of course agree that readability should be the prime concern, but I wouldn't have thought that a slightly less bleached background colour would cause problems with that. I understand if that's not the consensus opinion though. As a side note, I feel the colour works well on Hearthpwn, with the mostly black/grey/near-white theme; just that it works less well with the wiki's warmer, mostly blue/brown-red/purple theme. -- Taohinton (talk) 00:51, 22 January 2014 (UTC)

Card template

The changes to the card data system have rendered ineffective my simple {{Card}} template, which displays a card image and allows the reader to click to link to the relevant page. The template took the name (eg. Fireball) and linked to the related page (Fireball) and image (Fireball.png). While the page link still works, the image link doesn't - it finds the old non-numbered file, and not the new numbered one. This means that any changes to card data will not be reflected in the images produced by the template. A current example of this is Pyroblast, which is still showing as costing 8 mana on Mage.

We could fix the problem by manually adding numbers to every use of the template, but this is very cumbersome and would continue to be time-consuming in the future, with editors having to look-up individual card numbers any time they wanted to add a card image to a page. Ideally we need to find a way to have the template link to a certain file/number automatically, or via some kind of redirect. Is there a way to set File: requests to redirect to other files? Otherwise, is there a way we can extract linked filenames from page links, such as happens with tooltips?

Needless to say, this functionality is important for the site, allowing us to display cards outside of infoboxes. While the template is very handy, this problem would exist even without it, and affects any attempt to link to a card's image; that is, you need to look up the individual number for any card to link to its image. -- Taohinton (talk) 20:18, 18 January 2014 (UTC)

The images needed the card's id number for the same reason the data pages need it: the importer doesn't detect name collisions and will just upload over cards with the same name if it doesn't. I've updated {{Card}} to use roughly the same logic as {{Card infobox}} to find the correct images. It wasn't possible to preserve the way the second parameter worked in the template, though. Or, to be more accurate, I thought the change would make it more convenient, since all places that second parameter is used would have to be updated anyway.

This confines the problems above to those cards that share their names with others, where I'm afraid being more specific is unavoidable. OOeyes (talk) 16:14, 19 January 2014 (UTC)

That seems to have worked to link the right image, although none of the images seem to be clickable any more. Other than that, seems like a workable solution to a fiddly problem.

Incidentally, I notice a few data pages like Data:Cards/Deadly Poison(492) aren't being included in Category:Card data. Is this an error, or should I be searching in a different category for data pages? -- Taohinton (talk) 19:34, 19 January 2014 (UTC)

Okay, another problem. When we have pages such as Moonfire, use of the template will presumably still link to Moonfire, which in this case is for a completely different spell. Can you make the template ignore the parentheses from the first argument when calling the data? That should solve the problem. Otherwise, a link parameter would work, albeit less elegantly. -- Taohinton (talk) 19:44, 19 January 2014 (UTC)

A related problem: I just set the Moonfire page to draw the correct data (added "|name=Moonfire|rarity=None"), and it seemed to work until I resaved the datapage, at which point it seems to have gotten a little upset. It seems to be appending the data from the article pages to the data that's already there, rather than selectively overriding it. -- Taohinton (talk) 20:02, 19 January 2014 (UTC)

Yeah, that's a quirk of the way the pages find each other. Using |datapage on the Moonfire article and then resaving the data page for Moonfire (Choose One) resolved it. It's because the default condition of looking for name=Moonfire could have selected either card.

Category:Card data is now only for cards in play, and I excluded enchantments from it as well as they were one of the biggest name collision issues. This is because the various list templates look in Card data. There are also Category:Non-relevant card data, Category:Old card data, and now Category:All card data which does contain all of them. {{Card}} and {{Card infobox}} now use this last category so that they should be able to select any card. OOeyes (talk) 21:41, 19 January 2014 (UTC)

Okay, great. Out of curiosity, is it a bug that Category:Card data states 1,164 pages, but only lists about 544? The other card categories seem to list the correct numbers. -- Taohinton (talk) 00:03, 20 January 2014 (UTC)

Might be a bug, or it might just need a while to update. I'm not sure either way, but it seems harmless at the moment. OOeyes (talk) 00:40, 20 January 2014 (UTC)

You haven't replied regarding linking to alternate pages, so I'm not sure if the edit to the Card template was intended to fix that, or you're getting back to it later. At any rate, it's working in this format: {{Card|Moonfire (Choose One)|datapage=Data:Cards/Moonfire(111)}} but this still requires looking up individual numbers every time you want to link the card, which is workable but a bit tedious. -- Taohinton (talk) 00:12, 20 January 2014 (UTC)

If you're using |datapage, the name is going to get ignored, so {{Card|datapage=Data:Cards/Moonfire(111)}} is the same as {{Card|Moonfire (Choose One)|datapage=Data:Cards/Moonfire(111)}}. {{Cards|Moonfire (Choose One)}} is meaningless because that isn't looking at page names, just the literal card name. I've gone ahead and added a |page parameter, but this has a tradeoff of being more likely to suffer from caching issues.

The problem comes with the order things happen in. When the content page is made for a data page, it stores the name of the data page in a property. As the page is naturally saved at that time, it updates immediately. The data pages find their content page by looking for their name in that property, and then they store the content page name in their own property. That part can only happen when the wiki regenerates the data page, either when the cached version internally expires or when it gets resaved, so it won't happen immediately. OOeyes (talk) 00:40, 20 January 2014 (UTC)

Thanks for the explanation. The new parameter works nicely when the data page has the content page stored, and manually resaving the data page is actually less tedious for me than having to find and cite the number every time I want to link the card, so while not perfect it's definitely a better fix. -- Taohinton (talk) 02:02, 20 January 2014 (UTC)

One hopefully final thing before I get to work fixing all the uses of the template. Is there much of a likelihood we'll be needing to use |datapage for anything that doesn't start with "Data:Cards/" ? If it's an extra functionality we need, that's fine, but if not, it would be convenient to have it simply add that automatically. The question goes for Card and Infobox Card, too. -- Taohinton (talk) 12:18, 20 January 2014 (UTC)

I'd like to keep using the full page name in case we need to mock up data for future testing at some point. For example, say we get new cards in the future that have a new value. I'd rather not have to use Data:Cards/ for any testing. That said, I could add a separate parameter to take full page names and have datapage shortcut the way you're asking. Does that sound okay? OOeyes (talk) 19:35, 21 January 2014 (UTC)

Adding the parameter/having |datapage shortcut would be great, if that's alright with you. It seems like a smart thing to shortcut since as it stands it's standard for every card, and will end up getting used quite a lot. -- Taohinton (talk) 00:51, 22 January 2014 (UTC)

Okay, this is done. |datapage now requires only the subpage name and won't work with full page names. So datapage=Barrel(376) is now correct. |testdatapage is now the one to use for full page names. OOeyes (talk) 02:09, 23 January 2014 (UTC)

Great stuff. Coming in very handy as I work my way through the quadruplicates and red links. -- Taohinton (talk) 18:21, 24 January 2014 (UTC)

|page seems to be pulling the data linked to the page, but also all other non-attached page data of the same name. For example, |page=Mark of Nature draws all 3 spells and 2 enchantments, despite the page itself linking only to the main spell. Is this an error, or working as intended? If it could be made to pull only the data from the page itself, it would be a very neat solution to the card specification issue, since the datapage linked to the content page is always the one desired unless otherwise specified. This would allow us to essentially set a default card data, removing the need to specify each time {{Card}} is used. -- Taohinton (talk) 13:57, 2 February 2014 (UTC)

It was working as originally designed, but the data pages automatically assigning a content page name by card name is no longer such a nice feature with the new naming scheme. I've made some changes so that data pages will only internally register a content page as using them if one and only one content page is using {{Card infobox}} to pull its data. This should resolve the issue with the page parameter. It also means if two content pages are pulling the same data via {{Card infobox}}, page won't work for that card anymore. I've also set up a couple categories in Category:Wiki maintenance to help track down such issues, and {{Card data}} is also more helpful now on identifying such issues on the data pages themselves. Naturally and unforunately, this is vulnerable to caching issues. OOeyes (talk) 17:17, 5 February 2014 (UTC)

|page is working great now. In fact, I'd like to suggest it be made the default setting for {{Card}}. |page works as desired and intended for the vast majority of all {{Card}} usage - the only exceptions are for the homonymous Mark of Nature, Wrath, Nourish and Starfall Choose One spells, and all enchantments - everything else has a page of its own. The only pulls for the homonymous druid spells are on a couple of list pages like Uncollectible (just for completeness) - generally there's no need to link these. I don't think there's a single use of {{Card}} to pull an enchantment on the site, and I suspect it may be some time before there is. As it stands it should therefore be very rare that anyone needs to specify a card beyond what |page provides.

In the meanwhile, |page or the other parameters are required to be used quite often, and it's also less user-friendly for new editors. I think adding it as default would work for all existing usage, and save a lot of trouble in the future. The only issue I can see is technically, adjusting the template so that it reads the default argument as |page if there are no other parameters (other than |gold), and reads it as |name if there are - so that it's still possible to specify using the other parameters. If this is tricky, we could always switch the current functionality to a new template (eg. {{Card2}}) for those very rare occasions when we need a non-page card image, and simplify the current one. -- Taohinton (talk) 05:59, 10 February 2014 (UTC)

This shouldn't cause any problems that I can think of. Assuming nothing else comes up, I'll take care of it by the end of the day. OOeyes (talk) 16:55, 10 February 2014 (UTC)

This is done and seems to be working correctly. OOeyes (talk) 23:05, 10 February 2014 (UTC)

One card is having problems: Bite. See Druid#Druid spells for how it's behaving. It only seems to do this in combination with |page. As far as I've seen, it's the only card to do this, but it's possible there are others. -- Taohinton (talk) 01:31, 12 February 2014 (UTC)

Seems the data page for the enchantment didn't completely update for some reason. Despite displaying that it didn't have a content page, the actual property still had Bite listed, so it was still coming up in the queries. I've resaved the page and it has now updated fully. OOeyes (talk) 02:24, 12 February 2014 (UTC)

In addition to the above query, I'm wondering if there's a way to permanently mark card data as |chosenfrom without using a content page. I ask because the druid choose one option spells are all appearing in tables such as on druid, and the only way I know to fix this is to make individual pages for each one (ie 3 different pages named 'Wrath', 3 named 'Starfall', 3 named 'Nourish', etc) and specify |chosenfrom from there. Which is fine if necessary, just a bit pointless if there's a simpler way. -- Taohinton (talk) 23:15, 3 February 2014 (UTC)

The concept queries could be modified to only list cards that have a content page pulling data via {{Card infobox}}. That's the best and only real automatic approach available in this circumstance. And yes, data page caching issues would be present here. Resaving data pages might sometimes be necessary to make a card appear or disappear from the lists appropriately. And no, this approach would not be able to list the chosen cards in the infobox, so in some ways, the manual way might be superior. OOeyes (talk) 17:17, 5 February 2014 (UTC)

Just to note, I ended up having to do this anyway. Any card data page without a content page no longer gets a properly formatted link in the card lists, so they needed to be excluded either way. OOeyes (talk) 00:27, 6 February 2014 (UTC)

I'm wondering if it would be possible to have {{Card}} usages that fail to link to a page to be added to another category in Category:Wiki maintenance. As it stands, if you type something like {{Card|Pyrobiast}} you get a kind of line break, but otherwise no warning or sign that one of the cards has failed to appear. This would be helpful tracking down any remaining errors since all the adjustments, and would save time counting lists in the future. -- Taohinton (talk) 13:14, 16 February 2014 (UTC)

Done. Added a "card not found" image too. OOeyes (talk) 23:59, 17 February 2014 (UTC)

Wiki clone

http://wiki.hearthstonepro.net/ appears to be a (very, very slightly modified) copy of this wiki. Its pages and specific content seem to be 100% copied from us, including large swathes of my own writing.

As I understand the wiki's copyright, "any content from this site covered by CC-BY-NC-SA must be attributed to come from Hearthstone: Heroes of Warcraft Wiki if it is referenced from another site." This is most definitely lacking on that site. -- Taohinton (talk) 21:24, 29 January 2014 (UTC)

You are correct. Thanks for bringing this to our attention. We are on it. How did you find out about it? - 76.164.170.2 17:24, 30 January 2014 (UTC)

Just a follow-up, we contacted them and they have removed the offending content (i.e., the whole site) CrsBenjamin (talk) 23:21, 3 February 2014 (UTC)