Talk:AjaxRC/Archive 1

Options
Tried it myself, but could "Automatically refresh" and "Enable auto-refreshing page loads" be changeable too? Tried it myself, didn't work :P. Mark ( talk ) 15:13, June 22, 2010 (UTC)
 * Added the function.  Manyman  (Talk)  21:56, June 23, 2010 (UTC)
 * And fixed, should now allow options as laid out here. Grunny  ( talk ) 02:12, June 24, 2010 (UTC)
 * Once again, thanks a lot :)! Does it also work with AjaxRC/i18n.code.js? Mark  ( talk ) 16:26, June 24, 2010 (UTC)
 * Don't use i18n.code.js, it's really old code. -- 21:07, June 24, 2010 (UTC)
 * Added to i18n.code.js until this one supports all languages. Grunny  ( talk ) 23:33, June 24, 2010 (UTC)
 * And now have added support for all languages for this one, so you can use this one now, Tedjuh :). Grunny  ( talk ) 23:40, June 24, 2010 (UTC)
 * Yay :). Mark  ( talk ) 17:28, June 25, 2010 (UTC)

Broken
Hello,

there was an update on Wikia today. Now this Script doesn't work anymore. There must be a problem with the loadPageData function, but I'm not able to fix it. So if there is anyone who is able to fix it, please do so.

Also the ajaxRefresh and the incator can't be changed. So may be this can be changed also.

Greetings, TOBBE 14:42, April 27, 2011 (UTC)
 * I think I see what needs updating, but I'm not gonna touch it if I dont have to. I'll ping some JS gurus to take a look when they get on line later. --Uberfuzzy 20:14, April 27, 2011 (UTC)
 * It should be working again now. Cheers, Grunny  ( talk ) 06:54, April 28, 2011 (UTC)
 * That's all well and good, but most people don't use the import. Most instances I see are copy and pasted. The JSON error isn't just with this script, either - most Ajax-related things are turning up bad queries, or unintended JSON strings. The "customize" button for MyTools is returning bad JSON. In fact, I've had entire pages try to load as JSON - this is something that needs to ultimately be fixed on the Wikia end. ~ Monchoman45 ( Talk  |  Contribs  |  Central ) 14:51, April 4, 2011 (UTC)
 * Wikia's fixed the problem on their end, but now there's another problem - the new version of the script won't change the page. It'll refresh, but the page doesn't change, regardless of whether or not a new edit has been made. In testing, I found that the old version works fine. Revert? ~ Monchoman45 ( Talk  |  Contribs  |  Central ) 21:05, April 4, 2011 (UTC)
 * Done. Grunny  ( talk ) 00:08, April 29, 2011 (UTC)

Unable to import
Hello! I'm trying to import the script to w:c:masseffect.answers:MediaWiki:Common.js, but it doesn't seem to work. Upon publishing the page, nothing is added below the import script (importScriptPage('AjaxRC/code.js', 'dev');), and Can you please clarify how it's supposed to work? Or does it require specific wiki extension, or something? Mitranim 06:42, July 23, 2011 (UTC)

Please nevermind. It found that it indeed works, if I import it without setting any additional variables. It doesn't add any additional code to the page, but the auto-refresh box appears on certain pages. I'll try and see what causes the import with additional options to fail. Mitranim 06:55, July 23, 2011 (UTC)


 * Hi. You have a typo in your ajaxPages variable which is causing everything after it to break. Here you need an extra " after the Wikiactivity: . Hope that helps. Cheers,  grunny  :&#126;$ 07:02, July 23, 2011 (UTC)


 * Huh... Silly me. >_< Thanks for the help, and for the quick answer! Mitranim 07:07, July 23, 2011 (UTC)

AdminDashboard
Can someone change the position of the refresh throbber when RC is viewed through AdminDashboard? It is appearing before the header, meaning elements are physically moving for it to appear.
 * That's because of CSS loaded on the dashboard that floats images within that header to the left. I have removed the float on the throbber so it won't do that anymore. Cheers, grunny  :&#126;$ 15:02, August 6, 2011 (UTC)

Changing the throbber
Can someone tell me why the code on the following js page isn't changing the throbber? The code is definitely loading. Common.js

Security problem
It's a bad idea to use importScriptPage("AjaxRC/code.js", "dev"). Can't anyone edit that page and run arbitrary JavaScript on all pages that use the code? FB100Z &bull; talk &bull; contribs 21:07, January 1, 2012 (UTC)


 * Interesting point. Perhaps, at a minimum, code pages should be semi-protected? Thanks! — Spike Toronto  02:13, January 2, 2012 (UTC)


 * All code pages should be fully protected. Otherwise, any logged-in user can mess with the JavaScript, creating a potential to cause damage to all wikis using the code. FB100Z &bull; talk &bull; contribs 02:16, January 2, 2012 (UTC)


 * That’s not in keeping with the wiki ethos, though. Of course, changes should be discussed on the relevant talkpages, but editing code pages should not be restricted to dev wiki admins only. Moreover, there is only one sysop on this wiki, who has not edited it in three years. Thus, all updates/fixes/etc. have been made by non-sysops (especially Grunny, Monchoman, etc.). Therefore, full protection would be unworkable. I cannot recall any such event as you hypothesize actually having happened. Also, most troublemakers would do so anonymously or with brand-new accounts set up for the purpose: Semi-protection would prevent that. Thanks! — Spike Toronto  02:31, January 2, 2012 (UTC)


 * I completely understand your point, but it's too dangerous to risk the well-being of everyone's browser and Wikia account (primary targets for these attacks) to keep with the wiki philosophy. However, there's a possible solution to this problem:
 * Fully protect all the current code pages, since they're being hardlinked from scripts in many other wikis and are strongly vulnerable to attack.
 * Create new freely editable code pages that aren't hardlinked from other wikis.
 * Every so often, an administrator checks the secondary pages, makes sure they're safe, and copies them to the primary ones.
 * This model could work, although it would be a lot of tedious work for our inactive administrator ;) In the meantime, I would advise all wikis to avoid importing directly from dev.wikia.com; copy-pasting the code into a local script in the MediaWiki: namespace would be much, much safer. FB100Z &bull; talk &bull; contribs 01:24, January 3, 2012 (UTC)


 * I've fully protected the AjaxRC code page since it is a highly-used import, and as I'm the only one who edits it regularly, I figure it can't hurt and requests for changes can still go through me. If you have specific (high-use and stable) code pages you would like protected, just ask :). It might be a better idea to protect high-use pages and give trusted users (trusted in that they can code and aren't going to go nuts) sysop rights as needed as well. Cheers, grunny  :&#126;$ 16:36, January 3, 2012 (UTC)


 * Thanks Grunny! — Spike Toronto  09:43, January 4, 2012 (UTC)


 * Thanks heaps :) Maybe we could create a user group that allows editing of code files. FB100Z &bull; talk &bull; contribs 00:50, January 5, 2012 (UTC)


 * Brilliant idea! And Grunny is just the man to do it. :) — Spike Toronto  23:10, January 5, 2012 (UTC)

(Reset Indent) That would be way too laborious for anyone who wants to post code here, what with going to an rfr, waiting for it to passed and whatnot. Instead why don't you use Pending Changes? Staff and Helpers do visit here quite frequently and they could mark an edit as fine. -- Kangaroopowah ( Talk ) 22:56, January 7, 2012 (UTC)


 * Not a bad idea either. Although I do not think that FB100Z was suggesting a new user group that would require something as onerous as an RfP. I think he was suggesting something somewhere between being an autoconfirmed user and an admin. Something like how one acquires rollback over at Wikipedia: one asks, and the person asked reviews your work, and decides yes or no. — Spike Toronto  01:00, January 8, 2012 (UTC)


 * A brilliant idea, sir. Why didn't I think of that? FB100Z &bull; talk &bull; contribs 20:27, January 8, 2012 (UTC)

I'd like some explanation
Hi anyone who may be reading this. I want to ask a couple of things regarding the script and I'd appreciate a reply.

First of all, the cookie. It's needed in order for the script to remember whether the user has the auto refresh checked or not, am I understanding this correctly? If not what does it store?

Secondly something that is bugging me since yesterday. I want to add the Special:WikiActivity page in the pages that can be auto-refreshed but I also want to use the script locally instead of importing it, so I am not adding var ajaxPages = ["Special:WikiActivity"];, as the instructions suggest (as these instructions are for importing the script). What I have tested and failed instead is to add a second element to the default array of the script, like this if ( !window.ajaxPages ) { var ajaxPages = new Array("Special:RecentChanges","Special:WikiActivity"); } or like this if ( !window.ajaxPages ) { var ajaxPages = ["Special:RecentChanges","Special:WikiActivity"]; }.

As I said, this way is not working and I honestly cannot understand why? What am I overlooking? Regards -- Noemo n  * talk * 01:06, March 11, 2012 (UTC)


 * Hi, yep, that's right about the cookie, it just stores on or off for whether or not the auto-refresh is checked. Setting  should work fine. Can you link me to where it is not working, and also let me know what browser you are using? Cheers,  grunny  :&#126;$ 14:07, March 11, 2012 (UTC)

Conflicting with Other Scripts
Hello. This script seems to conflict with:

It changes the IP back to "A Wikia contributor" after the first refresh, any idea why? Thanks! 03:48, April 10, 2012 (UTC)
 * That's because by default, no scripts in the part of the page are run after the initial refresh. This can be easily remedied through ajaxcallagain. Basic doc for it is on AjaxRC but you can ask Moncho if you still need help as he wrote that part of this script. Best, -- Kangaroopowah  ( Talk ) 05:33, April 10, 2012 (UTC)

Enable Ajax refresh by defaut
Is there a way of making it so the refresh is enabled by default. I'm using it globally, and it seems pointless having to tick the box on every wiki I visit.

I also agree with Eladkse, I think it should be active by default and if someone doesn't want, he has to just untick the option. Another suggestion: can an option be created to active it on namespaces? I think's it's quite useful for forum or blog for example. 22:29, May 14, 2012 (UTC)


 * I wouldn't use it for blogs or message walls Leviathan. It clears the comment boxes!

Wiki-Activity Module
Can you also add the function to the Wiki-Activity Module at the right-column of the page please? Just let it be hidden in there -- Sam Wang (talk) 09:42, May 26, 2012 (UTC)

ShowHide conflict
If I add a collapsible table in Last Changes text-intro, the AjaxRC will expand it automatically. Is it a unavoidable conflict? 13:41, June 14, 2012 (UTC)

Now it apparently create a conflicts with MW Version 1.19, as you can see (everything is expanded). 16:01, July 5, 2012 (UTC)


 * Apparently a fix for this can be found here.  23:05, July 5, 2012 (UTC)


 * Hi, this has been fixed now. Let me knw if there are any more problems. Cheers, grunny  :&#126;$ 23:13, August 10, 2012 (UTC)

Code Lock
It seems that the code is locked and so can be improved or changed. Maybe we can add an V2 or try to contact the staff. It seems the old admins locked them when they created it. --Jens Ingels (talk) 18:57, August 10, 2012 (UTC)


 * Hi. This code is locked for a reason. It is used widely by many, many users so changes to it need to be checked before they are saved. As such, let me know if there is something specifically you want to change about the code and I can check your change and apply it if appropriate. Cheers, grunny  :&#126;$ 23:10, August 10, 2012 (UTC)

Well, some lay-out changes could make the script more practical to use. Something like this for example (photoshop examples):

Image version example:



Image version with text example:



Ofcource with use of a Throbber --Jens Ingels (talk) 00:07, August 11, 2012 (UTC)

Broken in 1.16
The script is currently broken in MW1.16 (and the page is locked). Not all Wikis have been converted yet so could you please add a conditional to handle both until the upgrade is completed? I suppose I can hack around this by explicitly invoking version [ 5602] (when it still worked) but I'd have to rewrite  to support a version parameter in order to do that. Lunarity 04:21, August 11, 2012 (UTC)


 * The built-in  function already supports this (note that   has been superceded by   in MW 1.17.   accepts full urls with parameters: mw:Manual:Parameters_to_index.php


 * Here is an example of how you would use it:

— Mathmagician (message wall)


 * I actually started rewriting  as soon as I posted this (when it occurred to me):


 * It's more flexible this way since I can easily apply the same fix to any other script with a similar problem, it's also backward compatible and fixes a couple of bugs in Wikia's version. I suppose I can improve it by polyfilling mw.loader and using that instead but I'm pretty sure other stuff is going to break after the upgrade anyway so I'll do it then. Lunarity 06:01, August 11, 2012 (UTC)

Problems to Namespace
This script is somehow interfering with the Namespace choosing. It disables the drop down list completely. Can this be fixed? 05:48, August 20, 2012 (UTC)

Doesn't show up
It doesn't seem to show up in, but shows up in. Here's the code:

— SW8573 (Message Wall) 09:58, August 29, 2012 (UTC)


 * "Special:WikiActivity" isn't in the list of pages you posted. It will only show up on pages that are in the list. Lunarity 10:42, August 29, 2012 (UTC)


 * Oh whoops. Silly me. I thought I put it there...must have overlooked it. Thanks — SW8573 (Message Wall) 12:38, August 31, 2012 (UTC)

Mainspace namespace
I'm not sure if this is a known bug given how long this has been happening, but the script doesn't work properly with the AjaxRC when filtering only the Mainspace namespace as it keeps showing everything. I tried with a different account without the AjaxRC script, and the filter works as intended. ··· d·day! 20:14, September 12, 2012 (UTC)

Problem with "see more recent activity".
When I click on "see more recent activity" with the AutoRefresh activated, It doesn't show more Recent activity and I'm sended to the top of the page. Any solution?

EN6


 * I know exactly what you're talking about, it's that link at the bottom of Special:WikiActivity. It has a dynamically-added onclick handler that's supposed to reveal more content, but when AjaxRC refreshes the page the entire page content (including the link) is replaced and the onclick handler is lost. No clue how to fix the problem, but that's what it is. [If someone reading this happens to know where in Wikia's github codebase the implementation and/or documentation for the Special:WikiActivity page is, please post the link here. I wasn't able to find it.]


 * AjaxRC/beta.js should fix this, but Grunny still hasn't pushed it to /code.js. -- Kangaroopowah  ( Talk ) 03:09, April 11, 2013 (UTC)


 * Tested and confirmed that AjaxRC/beta.js fixes this bug. I wouldn't have guessed all you had to do is call  &mdash; makes it look too easy :). Hopefully Grunny pushes that fix soon.


 * The credit for that fix goes to Lunarity. :) -- Kangaroopowah  ( Talk ) 01:55, April 13, 2013 (UTC)

Function Call Again
So I set the wikiSiteMeter function to be called again, and some errors started to happen with that function. Usually the sitemeter only appears once next to the Wikia Entertainment logo at the bottom left, but after each auto refresh a row of sitemeter started to appear.  Babar Suhail    20:20, April 18, 2013 (UTC)


 * (my note below also covers this, it's the same problem)

RevealAnonIP incompatible with latest update?
RevealAnonIP seems to have stopped working since the update to AjaxRC on April 18th. I've also had no luck with calling the function again via ajaxCallAgain. Any ideas?

~ Aelita 19:56, April 20, 2013 (UTC)


 * I recently imported RevealAnonIP to my wiki and it is working fine with the new AjaxRC update. I am also have problems with the function calling.  Babar Suhail    20:33, April 21, 2013 (UTC)


 * The current problem is that AjaxRC reads in ajaxCallAgain only when AjaxRC first runs. If another script runs after AjaxRC, anything added to ajaxCallAgain array after AjaxRC has already initialized is ignored. This is an unintended side effect of the most recent update to AjaxRC. It has been identified and fixed, but the fix is not live yet. I think Kangaroopower is making some other slight changes as well, but when he's ready Grunny can push the next update live which will fix this bug.


 * One thing you can do to help alleviate this bug in the meantime is, in your wiki's JS installation, make sure the AjaxRC import is at the bottom of your JS file so that it's the last thing that initializes.

ajCallAgain should be last event in AjaxComplete
Is there any particular reason why the ajCallAgain section is not last? -452 01:34, 23 May 2013‎ (UTC)


 * Apologies for not updating the talk page, but this bug has since been resolved and the fix is live. Or were you referring to something else? (please clarify what you mean by "ajCallAgain section")


 * There is currently a different problem with the same feature. Line 43-45 loops through ajCallAgain[].  Line 46-60 are applying other functions.  Any changes made in the ajCallAgain loop which are related to the subsequent functions are lost.
 * Specifically, there is a known problem with grouped recent changes which causes grouped Article comments and Message wall threads to be expanded by default. It hasn't been fixed in a year and I've been told that it's a low priority problem unlikely to be fixed any time soon, so I made a function "collapseExpandedGroups" to loop through ".mw-collapsible-toggle-expanded" and collapse them (on load, you can still toggle them afterwards).
 * Calling collapseExpandedGroups with ajaxCallAgain doesn't work because of the "$collapsibleElements.makeCollapsible;" on line 50, which is apparently the cause of the unfixed bug.
 * I've fixed it myself by just copying the script locally and moving the ajCallAgain section, but I figured it would be worth bringing up.  -452  03:08, May 23, 2013 (UTC)
 * So where did you fix it? -- Kangaroopowah  ( Talk ) 03:29, May 23, 2013 (UTC)
 * Locally on the wiki I use. -452 14:07, May 24, 2013 (UTC)


 * [Moved content under a new header, as this is a new issue]


 * @452 - Assuming Kangaroopower doesn't see any other problems with moving ajCallAgain to the bottom of the AjaxComplete callback, it sounds like a reasonable thing to do.


 * I believe it isn't necessary in the situation you described though.
 * In your ajaxCallAgain function, you could have called makeCollapsible yourself on those same elements, and then loop through them and collapse them afterwards. [Then, by the time AjaxRC's makeCollapsible call runs afterwards, the elements would have already been made collapsible and the code shouldn't run again.]
 * Or add class="mw-collapsed" to those elements before calling makeCollapsible. [Not sure if this would work if we moved ajCallAgain to the bottom of the AjaxComplete callback as you are proposing &mdash; that would cause AjaxRC's makeCollapsible to run before you've had a chance to add class="mw-collapsed" to the elements, and so I don't think they'd be in a collapsed state.]


 * I'm sorry that I've given you insufficient information about the nature of the bug.
 * Those elements are class="mw-collapsed", I'm not adding it, I'm just calling "click" on anything that is expanded. (As I said: loop through ".mw-collapsible-toggle-expanded" and collapse them)
 * I don't know the exact cause of the bug, Wikia have acknowledged that they should be collapsed and concur with my findings that toggle state of those elements in permanently reversed: "mw-collapsed" is removed when they are actually collapsed, and "mw-collapsed" re-added when they're expanded - the opposite of all other collapsible tables on RC.
 * -452 14:07, May 24, 2013 (UTC)

(reset indent) @452: Ah, I see. I think you gave me enough information, but I didn't take the time to actually reproduce the bug before replying. Now that I have, I see what you mean. Sorry about that.

On a related note, since I was playing around with it, here is a CSS fix I came up with for the issue, in case you or anyone else would have a use for it. One advantage (disadvantage?) to this is that it kills the fadeOut animation.


 * I personally am against a CSS solution because of the amount of space it'll take up. Unless there are any side effects to 452's fix, I suggest we push it. @452, submit your patch too AjaxRC/beta.js and then go to Portal:Code review so we can take a more in depth look at it and then we'll go from there. -- Kangaroopowah  ( Talk ) 02:42, May 26, 2013 (UTC)