MediaWiki talk:Common.js/Archive 1

Cleanup
I would prefer not to use the notiplus script at all. In fact, I would prefer to remove everything that is currently in MediaWiki:Common.js… It is either tools (AjaxRC, NotabilityMove) that users should be adding to their own personal JavaScript and that we shouldn't make everyone load and run, or things that affect only logged-in users and that we should not add to the site wide JavaScript either. A rule of thumb is that anything that does not make sense for anonymous readers who are not logged in should not be in MediaWiki:Common.js, MediaWiki:Wikia.js, or MediaWiki:ImportJS.

I don't think we need those JavaScript extensions at all. Some of them are poorly written JavaScript and have bugs; for example, AjaxRC resets expanded changes on Special:RecentChanges every time it updates the list, which as some might have found can be an annoyance not worth the auto-updating functionality. We already have blog posts and the forums to notify editors about things, and it is easy enough to determine who is an administrator or a content moderator that there's no need to put it in everyone's face. Even coloring links to user pages of administrators causes problems that it shouldn't on profile pages, categories, and maintenance reports.

What MediaWiki:Common.js and MediaWiki:Common.css are actually meant for is code that is necessary for our templates and articles to work properly for readers, for example styling the tickets and ROBUX templates, as well as infoboxes and navboxes. Customizations should not be in the site wide JavaScript and CSS, so if there is no objection in the coming days I would like to remove them and create a project page with instructions to enable personal JavaScript and add AjaxRC, NotabilityMove, and SignatureCheck to personal CSS and JavaScript pages. Users who want tools like AjaxRC and SignatureCheck will probably want them on all wikis, not just this one, so it makes more sense for them to add the tools to their global CSS and JavaScript pages which apply on all Wikia sites and not just the ROBLOX Wikia, and at the same time it won't make page loading slower for editors who do not want them or for readers who are not logged in. --Mark Otaris (talk) 02:59, October 18, 2016 (UTC)


 * Concerning most of the stuff I added (primarily AjaxRC, and especially YoutubeModal)– I have no qualms about them being removed. I agree that the amount of JS we are using should be lessened (despite that I have been helping to facilitate some recent additions (by fixing the configurations)). However, I do not believe that the JavaScript or CSS should be limited only to the whims of the casual reader to our wiki; it should also serve to aid all editors in our tasks ...not to say that wiki-wide JS determines what is good for all editors or that every editor would like what is added.


 * To remedy some of the performance concerns, may I suggest removing ImportJS (or limiting ImportJS to your suggested rule of thumb) and instead check the user's user groups before importing or configuring any JS in Common.js/Wikia.js? It's not as effective as straight up removal, but it should dwell any major issues regarding page loading for anonymous users (unless, does it actually take a while to retrieve a user's user group's..?).


 * If that does not seem like a plausible solution, I'd still like to explain my reasoning/viewpoints for some additions.
 * AjaxRC – tbh, this was more for me as I had found it quite useful. Just felt like others would benefit as well.
 * YouTubeModal – This was more of a way to keep users engaged on the wiki instead of redirecting them elsewhere.
 * SignatureCheck – I feel this is actually a necessary evil– and one I would've tried adding earlier, had I not forgotten. As long as we use talk pages, there will always be unsigned, unsourced comments where someone else will have to dig through a talk page's revisions to find the comment's original author and add unsigned. Granted, until a couple months ago, I had been the only one adding { {unsigned}} and talk pages here are typically left vacant. Anyways, this reminds me of another conversation to be had... on another talk page to be typed out on another night.
 * UserTags – This was primarily so that "content moderator" may be removed from Thundermaker300's profile and my profile (a simple "Admin" credential is more than enough), and provide a link for user group info (e.g. clicking on a Rollback tag will link to its appropriate section in the user rights help page). It also serves as a replacement for c:dev:ProfileTags which I added to manually give Thundermaker300 and Redhuanhakim03 content moderation tags (back when content moderation was an "unmarked" user group) and explicitly mark User:Wikia as a bot since... well, have you seen its message wall? Anywho, I suppose the ultimate remedy for that (other than to wait for Wikia/Fandom to fix it themselves) is to clean up some user rights. ¯\_(ツ)_/¯ Although, I do appreciate the consideration for the future (again, not to speak for Thundermaker300's stance concerning the additional user groups).
 * Admin username highlights (for Message Wall links) – This was a revision to Common.css that I made to fix a prior revision's attempt to add admin name highlights on message wall links. I hold no opinion for this addition.
 * MessageWallUserTags – I am not a proponent of having this feature implemented with JavaScript. If it is to remain implemented (in some form), I find it more appropriate in the CSS (like I did with Aezuica's message wall tag). I again hold no opinion of this feature being implemented for the administration itself. I do, however, think that both discussion moderators and any future content moderator would benefit from these tags on the forums.
 * Notiplus – I am not fond of this script. It's pretty nifty, but the information conveyed there could just as easily be placed in MediaWiki:Community-corner (or perhaps a news user blog). Not only that, but notifications may be "emulated" with plain CSS (and maybe a lil' jQuery, if you want to be able to close it). Thundermaker (if you are reading this)– I think it's a neat idea too, but as it really only should be used for the occasional, temporary one-off notice, it may as well just be implemented in a less complex way. imho. Then again, I've never seen this in action, so I wouldn't really know of any potential benefit to this wiki.


 * That took a lot longer than I was thinking it would to type. Hopefully this is coherent, because it's now a bit late and my mind's a bit weary at this late hour to amend it further. Or to add anymore to it. Anywho, um, yeah. Will add more tomorrow, if needed and/or procrastination deems in necessary. I think I finished tho?? (originally published on 05:38, October 18, 2016 (UTC))


 * **addendum**: sooo.... I did forget to address some things. Apologies as my reasoning here will mostly just be a literal stream of consciousness: In short– I think instructing others to implement features in their own personal JS may, by and large, be fruitless. It's better to outright provide tools to editors instead of simply saying "look at the dev wiki. a few of the thousands of things there will be relevant to you on this wiki.". Mostly, I think I was assuming that these useful productive tools would end up not being used as enabling personal JS is a relatively complex process (navigating preferences, then adding lines of code,, etc.), considering a large portion of editors aren't even prone to using wikicode. Not that it's a strong argument, but there's definitely no harm in at least educating editors about the possibility of using personal JS & CSS. –  JoTS  on yer wall. (talk) 05:57, October 18, 2016 (UTC)


 * I thought notiplus would be useful because then we wouldn't have to make threads and blog posts for everything, and it would be easier than making CSS for every notification. Thundermaker300, (Talk) 10:56, October 18, 2016 (UTC)


 * Okay, I need to reassess my suggestion to remove everything… You will be happy to know that user group CSS and JavaScript is a thing. Here's my proposal:


 * Remove YouTubeModal. It isn't very useful and we have very few videos on this wiki. All videos should either be directly uploaded to the wiki (not linked to the YouTube video), if they are part of the content of the article, or linked to with a regular external link, if they are mentioned in the article.
 * Move NotabilityMove to MediaWiki:Group-sysop.js.
 * Move AjaxRC to MediaWiki:Group-autoconfirmed.js. It's buggy, but it can be disabled with a checkbox and the argument that people are unlikely to use it if they have to add it to their global.js themselves is correct.
 * Move SignatureCheck to MediaWiki:Group-autoconfirmed.js.
 * Remove UserTags.
 * Remove MessageWallUserTags and reimplement it in MediaWiki:Common.css or MediaWiki:Wikia.css (depending on whether it works with the monobook skin) with the  pseudo-selector and the   CSS property, for discussions moderators, content moderators, and administrators.
 * Remove Notiplus, rationale being that MediaWiki:Community-corner does essentially the same thing and that blog posts and forum threads can be used for the same purpose.
 * Remove coloring of links to user pages and message walls, rationale being that it colors links it shouldn't and that the recent changes patrol makes it obsolete as far as the recent changes page is concerned.


 * This will leave MediaWiki:Common.js and MediaWiki:ImportJS empty. There are also a few things in MediaWiki:Common.css that should be moved to MediaWiki:Group-autoconfirmed.css. --Mark Otaris (talk) 21:10, October 18, 2016 (UTC)


 * wat. User group JS & CSS is a thing??? That surely does resolve some concerns. I am pleased with this solution. Also, yes please do (if you haven't already) remove YouTubeModal– that was one of my "especially" lesser concerns. –  JoTS  on yer wall. (talk) 22:06, October 18, 2016 (UTC)