All posts by Cqm

<p>Glad to see it's already known, but I'd just like to confirm the behaviour I'm seeing in oasis from mobile (Chrome on Android) - just the fandom logo on the far left of the global nav. It's particularly annoying when mercury doesn't support a number of namespaces. I almost thought search had been removed. </p>

<p>Like the above, I'm interested in the specifics of this. Monobook is obviously old compared to Vector and hasn't received any updates since mw1.19. Nonetheless, I'm confused how something that presents information in a different layout is in violation of the new law when many of the features of monobook are present in Oasis in one form or another. </p>

<p>There's a bit of a bug when I view it in mobile (android chrome). The filter list loads in one column, then shrinks to 3 rows and a fair chunk of the options get cut off as there doesn't seem to be a way to scroll sideways on the list. </p>

<p>It appears you can indeed do that although it's not labelled as a sort (the only way you can tell it's a drop-down is because of the 8x4 px chevron) and "newest threads" is a little counter-intuitive as a label for me. Perhaps it's just my preference, but I had to pause for a few seconds to process what option I should pick. Maybe a " first" on the end and a "sort by" label would help that. </p>

<p>Ater giving this new format a chance for a couple of weeks, I'm not convinced it's an improvement. Where previously you could: </p>

1. Find a chronological listing of technical updates.
2. Search for terms within an update.
3. Have a single discussion about an update.

<p>You no longer can. </p><p>Forum boards are ordered by the last post rather than the date they were posted, making it hard to see an overview of recent updates. The thread namespace is pretty much unsearchable due to one of the many questionable side-effects of its implementation. I searched for DPL in Board, Board Thread and Wall thread and got nothing back (despite it literally being in the title of a recent post) but found relevant results of the same search of User blog and User blog comment. And due to the frequency of updates now, having a conversation about an update or bug is fragmented across twice as many threads. While it was always recommended to send an email in about an issue, it was nice to ask if someone else had a similar issue or have a discussion about a change. With the fragmentation, that appears to have vanished. </p><p>The only redeeming feature is that you get notifications about new updates (which was a bug in blogs that was never fixed) and replies to comments. </p><p>Exactly how was a move to a feature being phased out in the near future due to the many, many issues it always had from its conception deemed to be an improvement? </p>

<p>I had a quick glance through enwiki's block log and they seem to be blocking individual IPv6 addresses. However, I'm not sure how range blocks look as they're pretty rare for IPv4. </p>

<p>@Saftzie so it would be better to block an IPv6 vandal with /64 by default? Thus 2602:306:BDDE:1350:D20:16C:61E7:83AE should become 2602:306:BDDE:1350::/64 automatically in an ideal world. </p>

<p>@Fandyllic You can indeed request the RTE be disabled, although staff usually require some kind of discussion before hand. </p>

<div class="quote"><i> <p>SlyCooperFan1 wrote: You do realize you're completely off the mark here? Yes, the base version of the software we're using is MediaWiki 1.19, but at this point, so much has been backported from MediaWiki 1.25 or even created independently of MediaWiki itself that there isn't any need to upgrade. It doesn't matter if the MediaWiki project maintains 1.19 or not anymore, because Fandom maintains it for us. It has nothing to do with any of this. </p> </i></div>
<p>There isn't that much that gets backported because it's so tightly integrated into everything else. Security patches get backported, which are generally small, limited in scope and really worth having, but not much else. Backporting in any quantity has the same problems as upgrading - Wikia made too many modifications to make upgrading easy. Sure, there are some features that are similar, but there are others that Wikia doesn't really maintain and have fallen behind. </p><p>The V1 API is very, very different to the MediaWiki API (I'm not even sure if it's updated anymore). It provides access to Wikia specific things like avatars, but it a long way short of what the current MediaWiki API supports. </p>

<div class="quote"><i> <p>Ciencia Al Poder wrote: ... enabled discussions on our wiki without even notifying us ... </p> </i></div>
<p>I just went through all 33 admins and counted 21 posts to discussions between them. Who is moderating/managing this? Enabling something when there is no obvious desire by the community to engage serves no purpose. You might as well have created a new subreddit. </p> <hr><p>@TwoTailedFox: Truth be told, I don't find your arguments on w:c:yugioh:Forum:New Portable-style Infoboxes overly compelling with regards to the syntax. To claim they make creating infoboxes easier is obviously going to be subjective based on personal preference and what you're used to. This is forgetting that infoboxes are not pages that receive a notable number of edits each week - you make them once, then fix or add to them as your needs change which are infrequent events. Perhaps you find PI more maintainable, which is the quality that really matters in terms of syntax, but I'd rather have a more flexible base when I have problems I need to fix. </p><p>Looking over the reddit thread you linked to from that forum, I'm not really surprised that the experience on mobile is so poor when they don't use an infobox class. Not being able to style things on mobile is a pain point, but you do get some things for free if you use appropriate classes. Changing to PI is clearly a huge improvement based on what you had, but I wonder what you might have got from some subtle class changes. </p>

<p>Those aren't quite like for like comparisons - Two Tailed Fox is a bureaucrat on Yu-Gi-Oh Wiki. He is clearly biased towards PI, but that view does seem to be vaguely shared by the wider community there. Dinoguy1000 seems to be the only notable opposition, and I would agree with his points about the general lack of argument provided in the proposal (although that is the case for almost every PI thread I've seen). The note about preventing reversion of the conversion in the closure is an over-the-top approach to take in my view, but that may be how they do things there. Nonetheless, it would be a cause for concern if an admin or bureaucrat did the same on my home wiki. </p><p>As a philosophical point, Fandom claims that PI improves the infobox experience for mobile because they cannot style all possible variants of infoboxes generated using wikitext or Lua. Yet if they allowed some user-defined styling in mobile, they might find the problem vanishing. It seems an awful lot like a problem of their own design. </p>

<p>@Fandyllic I did notice we had over 100 infoboxes according to the category which might slow the conversion down dramatically, but I doubt any amount of influence would stop us being stuck with PI if it came down to the wire. </p>

<p>I'd suggest emailing staff via Special:Contact/general to see what help they can provide. Fastly is the caching layer used by Wikia, so they'll likely have a better idea of what's going wrong or a contact that will. </p>

<p>@above: For what it's worth, I spoke to staff and go no promise that this wouldn't happen to RuneScape Wiki (and thus MLP, COD, etc.). The option of not having PI didn't seem to be on the table, but perhaps that's a misinterpretation on my part. In general, I find most staff members to be reasonable people, so let us hope there can be a proper discussion with all options on the table should the event ever arise. </p><p>I have concerns about the suitability of PI in complex scenarios - simple use cases shouldn't have too many pitfalls during conversion other than CSS. For RS, the complex instances are also the richest in data, so doing it badly doesn't do the data service and could do more harm than good. </p><p>As a purely speculative point, I do wonder why edit warring over the conversion to PI is considered a ToU violation and why conversion itself is considered part of Fandom operations. My theory is that having everyone using PI enables Fandom to sell the data and work with third-parties who may want to utilise it. It could put a potential partner off when discovering that the top wikis, and thus the most desirable, do not make their data available. As ToU violations tend to come into play when it involves the Fandom brand and/or advertising, i.e. revenue from advertising, this is the most likely reason in my mind as to why there's been an expansion in the scope of ToU. As I mentioned, this is speculation and I may be proved wrong, but I wouldn't be surprised if it turned out to be correct. </p>

<p>As others have mentioned, there is no way to import scripts from wikis other than dev or the current one via ImportJS. Your options are to use MediaWiki:Common/Wikia.js, copy the script over to Dev, copy the script over to your wiki or make a script on your wiki that simply imports the script in question and then import that via ImportJS. </p><p>If you do decide to put it on Dev Wiki, I'd recommend documenting it and any configuration options it has. I agree that the current ReferencePopups script there has issues, and have rolled a vastly simpler version on my home wiki. You may find others using it and even helping you improve it as well. </p>

<p>It wasn't technically broken, it was just broken according to the parser mediawiki use. And because resource loader concatenates scripts together along with how js errors works, it resulted in a number of scripts breaking at the same time. </p>

<p>The issue seems to be in w:c:dev:MediaWiki:AjaxBatchDelete/code.2.js. I think it's caused by using \ as part of multi-line strings, but as far as I can see it only breaks on the Tower of God Wiki for reasons I don't understand. </p><p>I've fixed what I think the issue is and submitted it so it may fix itself in a couple of days when the review goes through. If not post here again and I'll take another look. </p> <hr><p>Edit: I poked Rappy who reviewed it for me in record time. The scripts appear to be working as far as I can see - are you able to confirm? </p>

<p>@Nanaki, @Dessamator: Ordinarily I wouldn't mind inline styles, but this is the first time in years there's been any concession after claiming it's bad for performance and even going to the lengths of writing a blog about it. Why the sudden change of heart now? </p><p>The could have supported a tool to apply custom styles to an infobox, but what doesn't seem to have been considered here is using the same styles on a dark desktop skin compared to the light mobile skin especially if the font colour isn't set but the background colour is or vice versa. I'm not sure if the game guide apps are still a thing, but last I looked they offered both light and dark themes. This looks more like we're taking the portability out of infoboxes again. </p>

<p>So in essence, PI now supports inline styling [on mobile]? Whatever happened to inline styling being bad? Assuming I've understood this correctly, this is also the only way to get styles into mobile as site CSS is still stripped away. </p>

<p>By far the simplest way to get uncached JS, is to use the debug URL parameter. By simply appending ?debug=1 to your URL it bypasses the cache so you know it works and then after 5-10 mins you generally don't need it any more as the cache has updated. </p><p>Example: http://community.wikia.com/wiki/Thread:1037705?debug=true </p>