User talk:Monchoman45/Archive 7

Hello
http://images.wikia.com/zammy/images/d/d7/Monchoman45.png 18:25, December 4, 2012 (UTC)
 * Legit --  Random Time  23:19, December 4, 2012 (UTC)
 * Slander

Hey moncjo I don't really know how to use thes but I was nt the one that made you ban me. My computer is really vulnerable, and my Facebook has already been hacked. Feel free not to believe me but it wasn't me that wrote that message or whatever it --Sowhatsyournameagain? (talk) 18:12, December 22, 2012 (UTC)was that caused you to ban me. In fact, I'm using my iPad right now.

Chat hacks, chatmod icon
Hi, I've seen that the chat hacks place a chat mod icon next to the username of the chat mods of that chat. But they don't seem to appear on my Wiki's chat (KnB Wiki), it's an empty file. Is there a way to upload the file? 18:38, December 4, 2012 (UTC)
 * That was fixed in this revision a month ago. It's possible your cache hasn't been updated since, I would clear it and see if the problem persists.

Chat Features for APW
Hey, I am the founder of Anything Pirates Wiki, and I was wondering if you could help me out with a couple things.

1.Get a chatmod icon, a gold coin with a black m on it, i can make the pic.

2. Put on chat hacks and etc.

3. Help me enabled the emoticons, the coding i got from the website is in the page, but it came up as links.

Thanks for your time! Please respond soon with an answer!

21:21, December 4, 2012 (UTC)


 * I'm not familiar with the standard way of accomplishing that. You can ask an admin at the Call of Duty wiki, they've changed their mod icons and also can help with number 2 (which you'll probably need for this anyway).
 * You'll want to copy the code from MediaWiki:Chat-welcome-message to the page with the same name on your wiki. You don't have to copy their actual welcome message, just the stuff after the . Then copy everything from MediaWiki:Chat.js/load.js to the same page on your wiki. With that, you can put chat stuff in MediaWiki:Chat.js and it'll load for everyone. I suggest copying CoD wiki's options.js. You can either put that directly into MediaWiki:Chat.js, or put it in MediaWiki:Chat.js/options.js and just put   in MediaWiki:Chat.js. That'll let you use chat hacks, and a bunch of other things you might want.
 * The code you got was HTML. MediaWiki:Emoticons doesn't work that way, it just needs the url of the image (for example, for the first one on the page, you want just  instead of  ). If you replace all of those, they should work normally.

Coding
Hello, I am an Administrator from the Fairy Tail Wiki and I was wondering if you could possibly lend me some assistance? Is there any sort of CSS or JS coding that I could use to hide the "Discussion about XXX" section that appears at the bottom of articles when you enable the new forum feature. My wiki is considering using the feature, but we don't want to if we have to have those at the bottom of the page.


 * CSS . Do note, however, that using that wiki-wide could be a ToU violation. As far as I know hiding read more is not (or at least it wasn't the last time staff said anything about it, which was a very long time ago), and this is essentially the same thing, but for forums. So basically, if you're allowed to, that's how you would do it, but I have no idea whether or not you're allowed to.


 * Thanks so much!!! For now, for the sake of getting what I want, I'll just assume it isn't a ToU violation. >_>


 * To clarify, staff have said this code is not permitted to be used wiki wide. See 1 and 2.

Parse Error in ChatHacks.js
I just tried your ChatHacks for the first time. Except I haven't. There's a parse error that prevents the code from loading:

"Error: JavaScript parse error: Parse error: Unexpected token; token 3 expected in file 'User:Monchoman45/ChatHacks.js' on line 320"

(copypasted from Firebug)

My guess is it's because you use "default" as a property name. That's a reserved word.

Besides: Do you really have to use eval? --


 * *sigh* I think I've found the source of the problem: ChatHacks.js doesn't load because NoScript doesn't permit attaching scripts from an external window. I created a new FF profile without NoScript and could load ChatHacks.js without problems. --


 * This appears to work for me (even with NoScript enabled):


 * Unfortunately I have no theory why this works while everything else failed :( --


 * May I ask two questions about your code?


 * Why do you test for objects in the while-loop of Preparse. window.commands doesn't contain any objects. So where are they? Where do they come from?


 * As far as I understand your code, it consists of not one but two scripts. The first and shorter one opens the chat window and then loads the larger one that contains the actual chat-hacks. So why are these two scripts in the same file? And why does the loader part of your script load the entire global.js and the entire wikia.js instead of ChatHacks.js only? --


 * Objects serve as subdirectories. It's a better way to manage a set of related commands, without having to use a single function that is essentially a switch. There aren't any natively, but if someone wanted to expand it to include, say, commands for managing a log, they could do that.
 * I could split it into two files, but there's not really any point. It wouldn't necessarily break anything, but I wouldn't gain anything either.
 * Importing personal code pages allows people to use other scripts as well. If it didn't import /global.js or /wikia.js, people wouldn't be able to use Joey's multi PMs script.


 * Loading a large script of which 95% aren't needed on pages other than Special:Chat is wasteful. I'd split the script if I were you.


 * Loading the entire global.js and wikia.js on Special:Chat is also wasteful. If I were to write everything from scratch I'd offer a way for other scripts to subscribe instead. But I see your point about Joey's PM script. Changing anything about this is probably not an option anymore.


 * Do I understand you correctly, that you don't currently use these subdirectory objects in the while loop of Prepare? Does anybody? If not, you could simplify the whole thing substantially.


 * How about declaring all those aliases from the window.commmands object separately:


 * Then you could reduce Preparse quite dramatically:


 * And those odd "default" prorties and eval would be gone... :P


 * Loading a large script of which 95% aren't needed on pages other than Special:Chat is wasteful.
 * Consider that the parsing time for the 95% that isn't used is a millisecond or two, and that the bandwidth used accounts for a fraction of a percent of your internet usage. If the code pages were split, over several decades, each person using them could potentially save a penny on their electric bill and possibly enough time to blink. The same concept applies to minify (and is why I don't like it); people think it's a great way to speed up their websites and save people bandwidth. The truth is that the speed difference is insignificant and your browser cache is several orders of magnitude more influential on your bandwidth consumption. Coupled with a server side cache, minify can save a considerable amount of money for large websites with many thousands of unique views; when you have to handle several million requests every day, your fractions of a penny add up very quickly. This actually applies to virtually everything regarding large websites, down to something as basic as putting a cost on a single processor cycle. On the scale of your laptop, however, the time it would take you to figure out whether or not it's worth it would likely put you in a hole that an optimized solution would not be able to climb out of in several of your lifetimes.
 * Loading the entire global.js and wikia.js on Special:Chat is also wasteful. If I were to write everything from scratch I'd offer a way for other scripts to subscribe instead.
 * Setting aside the above, this is true. However, this boils down to a human factors issue - the vast majority of people on Wikia know nothing about code. Most probably can't tell the difference between CSS, JS, and HTML, or know what any of them stand for. Simplicity is everything, the more things there are to consider, the harder it is for people who know nothing to pick it up. Not to mention that introducing a larger load order complexity is always, always, always a bad idea.
 * Do I understand you correctly, that you don't currently use these subdirectory objects in the while loop of Prepare? Does anybody?
 * There are no subdirectories by default, no, and to my knowledge no one implements any extension to chat hacks. Part of the point of chat hacks was, however, to be extensible. Wikia's chat client is not very well designed to be friendly to code (I did propose a set of changes to help alleviate that problem, but Wikia doesn't take those kinds of suggestions), and by taking a few liberties (like overwriting functions), I could make it extensible myself for anyone who wanted to do something later. Unfortunately, writing scripts for Wikia is a bit of a niche market right now. As far as coding practice, however, extensibility is among the more important aspects of code, even more so in JS, and comes at a fairly low cost. Frequently you can even reap the benefits yourself later, I find that if I keep extensibility in mind when I write code, I'm more likely to produce a much better code structure, which makes it easier to make changes to later, even if you don't use the extensible interface you designed. (Torus is a much better example of that than chat hacks)


 * Those should answer the rest of your message - per your code, regex and jQuery are two things I purposefully avoid at every opportunity. In particular, regex quickly produces unreadable code and fails to scale up to more complex parsing jobs. jQuery encourages bad coding practices, is horrendously inefficient, and is never actually necessary. A great example is a basic class selector like . Consider the work that jQuery needs to do in order to correctly give you what you want - first it must parse   (probably with regex). Generally this takes very little time, however with the frequency that people use jQuery you could potentially be calling this parsing operation several thousand times per day, and not always on simple strings like  . Then it has to get every single element on the page - yes, every single one - and sift through them to get all the ones with the class  . That in itself requires jQuery to split every class name by spaces and iterate through the resulting array to see if   is there. Further consider that this is repeated if you do  . In reality, in 99% of the cases where you would normally do this, you could instead put an id on a parent element and use a selector like   to return the exact same list of elements. If you drop the jQuery and use , your code will be upwards of million times faster. Do note that this does not generally apply to Wikia, because these kinds of changes have to be made to the HTML you're working on - essentially, on Wikia's end. Thus, on Wikia (and unfortunately, most websites), you may be forced into using a class selector, or a complicated chain of specifically positioned elements. For HTML you write, however, you can avoid using class selectors completely, and bask in the glorious benefit. Classes were designed for CSS, jQuery got people used to using them for element identification - and that is a bad coding practice.
 * Chat hacks in general needs an update. I wrote it when I didn't know much about what I was doing (I might have thought I did, though). The use of, for example, was a terrible decision (and was also implemented wrong). If you can find   in Torus, you'll see it instead keeps a reference to the directory it is at and performs all operations relatively instead of absolutely. So far I haven't had any stupid problems with it - and that's really all I can ask for, so I consider it a success. One day when I have the time, I'll rewrite chat hacks from the bottom up, and it won't be so bad anymore.

Judging by the length of your reply, I seem to have implied that I doubt your coding skills :) I certainly don't. You're a much more well-respected coder in these parts than I am and surely with good reason. Compared to you, I'm still a MediaWiki/Wikia noob :)

It doesn't seem to me that coding addons for Wikia is a niche though. From what I've seen in the few months that I've been here, I'd say there's a small but very prolific community of coders at dev. Which btw I think you should join! Building library functionality into your addon is all well and good, but if you don't document that functionality anywhere then you've only built it for yourself. Dev would be a perfect place to show how to extend ChatHacks. It wouldn't hurt to write up some end-user documentation either ;)

I somewhat agree on your critique of jQuery. When I started to script for MediaWiki/Wikia, I used jQuery for the first time. Now - a few months later - the sensation of the new has worn off a little and I see it more critical. It's perfectly reasonable to use document.getElementById if you want to do something really simple - like testing whether some element is on a page or not. It's also true that people tend to use jQuery selectors a bit carelessly. They really shouldn't contain much more than a single ID or class. Stuff like $('#WikiHeader > nav > ul > li:first') is really bad and should be replaced.

Your critique of regexes is a bit over the top though. The fact that you cannot build language-level parsers with (the current incarnation of) regular expressions doesn't mean they're unsuitable for simple stuff either. And readability is only a concern if you're not used to regular expressions.

I still think that splitting the script in two - and yes minifying it - would be beneficial. Simply because it can be done completely transparent for the end-users and would require no action on their part.

Seeing that there are so many users of ChatHacks.js out there, it's impossible to do something about the blanket including of everything in the wikia.js and the global.js. You might want to use the ResourceLoader though. That would save one file request. Reducing the amount of file requests is always beneficial. It's more beneficial than minifying, more beneficial than optimizing your selectors and more beneficial than any other kind of optimization. --


 * Judging by the length of your reply, I seem to have implied that I doubt your coding skills :)
 * Not at all - the science part of computer science just takes more words to explain.
 * I still think that splitting the script in two - and yes minifying it - would be beneficial. Simply because it can be done completely transparent for the end-users and would require no action on their part.
 * There's no reason. Splitting the script in two wouldn't change the number of file requests, and as already discussed, the length is insignificant. Minify is a server-side optimization only and has virtually no effect on the end user, other than making it more difficult to report an error in console. All change carries with it the potential for error, and with no benefit for anyone, this simply isn't worth it.
 * You might want to use the ResourceLoader though. That would save one file request. Reducing the amount of file requests is always beneficial.
 * This is true (most of the time). However, a large problem with resource loader is that if you combine many files and one of them throws an error, execution of other files can be skipped. I haven't had any JS on central for several months because of this. More to the point, saving one file load doesn't produce gains as big as you would expect - your browser cache and threading both take care of most of the overhead already.

About right sidebar
Well hi there. I've just hed googled a few discuion pages about hiding the right sidebar with your scripts, however, it seems that hiding it violates some blah-blah rights or something, well, i wouldnt wonder if i gonna my wikia deleted due to removing this ugly rail.

So... did the situation changed somehow or its still a taboo?


 * You can only remove it for yourself, using a personal file - you can't remove it for everyone on your wiki, that violates the ToU.