Fandom Developers Wiki
Register
Advertisement

This is the talk page for discussing improvements to the AjaxRC/Archive 1 page.

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. --Pcj (TC) 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: "Special:WikiActivity,"Special:Watchlist". Hope that helps. Cheers, grunny:~$ 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.    ǝsʞpɐןǝ  (talk page)  11:03, 6/08/2011

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:~$ 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    ǝsʞpɐןǝ  (talk page)  11:17, 31/08/2011

Well, no one has replied this u.u, but if somepony wants change the throbber (like me) this was the problem... --ShutterBat (talk) 05:13, January 5, 2014 (UTC)

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? FB100Ztalkcontribs 21:07, January 1, 2012 (UTC)

Interesting point. Perhaps, at a minimum, code pages should be semi-protected? Thanks! — SpikeToronto 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. FB100Ztalkcontribs 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! — SpikeToronto 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. FB100Ztalkcontribs 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:~$ 16:36, January 3, 2012 (UTC)
Thanks Grunny! — SpikeToronto 09:43, January 4, 2012 (UTC)
Thanks heaps :) Maybe we could create a user group that allows editing of code files. FB100Ztalkcontribs 00:50, January 5, 2012 (UTC)
Brilliant idea! And Grunny is just the man to do it. :) — SpikeToronto 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. — SpikeToronto 01:00, January 8, 2012 (UTC)
A brilliant idea, sir. Why didn't I think of that? FB100Ztalkcontribs 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 --Noemon *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 var ajaxPages = ["Special:RecentChanges","Special:WikiActivity"]; 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:~$ 14:07, March 11, 2012 (UTC)

Conflicting with Other Scripts

Hello. This script seems to conflict with:

// Convert "Anonymous" in Comments to IP address
// from User:Monchoman45
 
function AnonIP() {
	var list = document.getElementsByTagName('a');
	for(var i in list) {
		if(list[i].href && list[i].href.indexOf('Special:Contributions/') && list[i].innerHTML == 'A Wikia contributor') {
			list[i].innerHTML = list[i].href.substring(list[i].href.lastIndexOf('/') + 1, list[i].href.length);
		}
	}
}
addOnloadHook(AnonIP);

It changes the IP back to "A Wikia contributor" after the first refresh, any idea why? Thanks! {{SUBST:Signatures/Nikolaitttt}} 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.    ǝsʞpɐןǝ  (talk page)  12:28, 6/05/2012

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. leviathan_89 22:29, May 14, 2012 (UTC)

I wouldn't use it for blogs or message walls Leviathan. It clears the comment boxes!    ǝsʞpɐןǝ  (talk page)  15:49, 15/05/2012

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? leviathan_89 13:41, June 14, 2012 (UTC)

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

Apparently a fix for this can be found here. leviathan_89 23:05, July 5, 2012 (UTC)
Hi, this has been fixed now. Let me knw if there are any more problems. Cheers, grunny:~$ 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:~$ 23:10, August 10, 2012 (UTC)
AjaxRClay-outexample1

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

Image version example:
AjaxRClay-outA

Image version with text example:
AjaxRClay-outB

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?

//preloadAJAXRL:
			if ( window.wgVersion !== '1.16.5' && mw.config.get( 'wgNamespaceNumber' ) === -1 && mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Recentchanges' ) {
				mw.special.recentchanges.init();
			}

function loadPageData() {
	var cC = window.wgVersion === '1.16.5' ? (window.skin === 'oasis' ? '#WikiaArticle' : '#bodyContent') : '#mw-content-text';

I suppose I can hack around this by explicitly invoking version 5602 (when it still worked) but I'd have to rewrite importScriptPage to support a version parameter in order to do that. Lunarity 04:21, August 11, 2012 (UTC)

The built-in importScriptURI function already supports this (note that importScriptURI has been superceded by mw.loader.load in MW 1.17. importScriptURI accepts full urls with parameters: mw:Manual:Parameters_to_index.php#Raw
Here is an example of how you would use it:
importScriptURI('http://dev.wikia.com/wiki/AjaxRC/code.js?oldid=5602&action=raw&ctype=text/javascript');

Mathmagician (message wall)

I actually started rewriting importScriptPage as soon as I posted this (when it occurred to me):
"use strict";
window.importScriptPage = function (aPage, aServer, aVersion) {
	"use strict";
	var url = wgScript + "?title="
		+ encodeURIComponent(aPage.replace(/ /g, "_")).replace(/%2F/gi, "/").replace(/%3A/gi, ":")
		+ "&action=raw&ctype=text/javascript";
	if (aServer) {
		if ((/^[A-Za-z\.+-]+:\/\//).test(aServer)) { // Full URL
			url = aServer + url;
		} else {
			url = "http://" + aServer + ".wikia.com" + url;
		}
	}
	if (typeof(aVersion) === 'number') url += '&oldid=' + aVersion;
	return importScriptURI(url);
};

window.AjaxRCRefreshText = 'Automatically refresh every 60secs';
importScriptPage('AjaxRC/code.js', 'dev', 5602 /*MW1.16 was broken after this*/);
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? Template:UltimateSupreme/Sig 05:48, August 20, 2012 (UTC)

Doesn't show up

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

// Auto-refresh button config options
ajaxPages = ["Special:RecentChanges","Special:Watchlist","Special:Log","Special:Contributions","Blog:Recent posts","Blog:News","Blog:Featured blog posts","Blog:Popular blog posts"];

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.] 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 02:41 UTC, Thursday, 11 April 2013
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 WikiActivity.init() — makes it look too easy :). Hopefully Grunny pushes that fix soon. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 04:31 UTC, Thursday, 11 April 2013
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) 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 16:28 UTC, Sunday, 21 April 2013

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. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 16:18 UTC, Sunday, 21 April 2013

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") 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 02:44 UTC, Thursday, 23 May 2013
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 — 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.]
20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 13:27 UTC, Friday, 24 May 2013
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.

/****** CSS fix for collapsing grouped recent changes ******/
/*** Special:Preferences > "Use advanced recent changes" ***/

/* show and hide table rows */
body.mw-special-Recentchanges table.mw-enhanced-rc tr {
	display: table-row !important;
	opacity: 1 !important;
}
body.mw-special-Recentchanges table.mw-enhanced-rc.mw-collapsed tr {
	display: none !important;
}
body.mw-special-Recentchanges table.mw-enhanced-rc.mw-collapsed tr:first-child {
	display: table-row !important;
}

/* display the correct arrow */
body.mw-special-Recentchanges table.mw-enhanced-rc .mw-rc-openarrow {
	display: none !important;
}
body.mw-special-Recentchanges table.mw-enhanced-rc .mw-rc-closearrow {
	display: inline !important;
}
body.mw-special-Recentchanges table.mw-enhanced-rc.mw-collapsed .mw-rc-openarrow {
	display: inline !important;
}
body.mw-special-Recentchanges table.mw-enhanced-rc.mw-collapsed .mw-rc-closearrow {
	display: none !important;
}

20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 03:36 UTC, Saturday, 25 May 2013

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)
Changes made. Do you want me to reply to Portal:Code_Review/AjaxRC or make a new post? -452 02:55, May 26, 2013 (UTC)
@Kangaroo: To clarify, I'm on board with 452's suggestion of moving ajCallAgain to the bottom of the callback. As far as changes to AjaxRC, I believe that's the only thing that needs to / should be done here, as seen in http://dev.wikia.com/?diff=12300.
I do not think either of us were (or to speak for myself, I was not) suggesting to include a fix for the grouped recent changes bug in AjaxRC itself, because 1) this is a very minor issue and 2) the purpose of AjaxRC isn't really to fix Wikia's bugs.
The reason I posted the CSS above was not for inclusion in AjaxRC, but as one possible solution for people reading this page who want to fix the bug on their own, in the event that Wikia doesn't fix it anytime soon (if ever). 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 17:36 UTC, Sunday, 26 May 2013
@Math that makes more sense. I was more concerned with the ajaxCallAgain bug in general, but the css kinda threw me off :P. Thanks for clarifying, and I agree that AjaxRC shouldn't be fixing Wikia's RC bugs (this depends though, on how much the bug in question affects AjaxRC IMO). @452 just create a new one, like AjaxRC 1.

Memory leak

There appears to be a memory leak caused by using this script.
I'm using google chrome, which has a handy task manager which tells you the memory usage of each tab. When I open RecentChanges and leave it sit open, the memory usage goes higher and higher, resulting in a lot of lag if the tab is left open all day or overnight.
I haven't really looked into it yet, so I don't know whether it's a problem with the script not deleting unused variables, or whether javascript just has poor memory management. -452 02:19, June 1, 2013 (UTC)

See my talk for details. We're not exactly sure of the problem, but my change did fix it on my end so I'm going to push it along with your fix. --Kangaroopowah (Talk) 02:39, June 1, 2013 (UTC)
Great, thanks! -452 02:48, June 1, 2013 (UTC)
Just after my last reply, I copied over "$temp.remove();", waited a little while for the cache to update, then left the tab open until now. That tab is now using over 500mb. All of it in "Javascript memory". I'll repeat the experiment with the MakeCollapsible part disabled. -452 13:03, June 1, 2013 (UTC)
@452: Oh cool, you're looking into it here too. Please do share your findings and hopefully we can track it down - memory leaks are nasty business. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 18:38 UTC, Saturday, 1 June 2013
I opened two Recentchanges tabs just after my last comment: Tab with makeCollapsible enabled: 434mb. Tab with makeCollapsible disabled: 44mb. So I definitely agree with you that makeCollapsible is part of the problem. Whatever makeCollapsible is adding is not being properly removed when the page is reloaded, I don't know if that's a problem with makeCollapsible itself claiming some memory when it is called, or if AjaxRC isn't freeing some memory when the refresh happens.
I googled it and found a post from last year about a similar makeCollapsible problem elsewhere, and another post about makeCollapsible using a lot of memory when used a bunch of times on the same page, but because this is a unique case of calling makeCollapsible over and over, no-one has really paid attention to how much memory it eats.
Here's the wikia source for makeCollapsible: https://github.com/Wikia/app/blob/dev/resources/jquery/jquery.makeCollapsible.js
Since the bug isn't really an issue without AjaxRC, it's probably unlikely to be fixed there, so it may be a matter of writing a function in AjaxRC to undo everything that makeCollapsible() does, that is to say, correctly unload/delete anything makeCollapsible has added, before refreshing the content and calling makeCollapsible again. Unfortunately, there isn't already a "makeUnCollapsible()". -452 19:18, June 1, 2013 (UTC)
After reading your comments on Kangaroopower's talk page, I did some more searching and found this stackoverflow: how to remove dom elements without memory leaks. If that's accurate, it explains why the problem exists. With this in mind, I'm going to do some more tests with blanking nodes before replacing them. -452 22:29, June 1, 2013 (UTC)
I had no luck testing, and have had no bright ideas about how to fix it, however, running this line in the console over and indicates that it's entirely a problem with makeCollapsible, since the nodecount increases every time it is run:

$( '.mw-collapsible' ).makeCollapsible();

var count=0; for (var i in jQuery.cache) count++;

console.log("nodes: "+count);

Right now, there's 16 collapsible entries on my recentchanges, and it's adding 16 nodes every time it is run, both when allowing ajaxrc to refresh, and when just running it repeatedly from the console. -452 20:39, June 12, 2013 (UTC)
Cool, it sounds like you and I at least are on the same page about that. (I've been convinced it was a makeCollapsible problem since about a month ago.) Still would like to hear back from Kangaroopower/Grunny/Kirkburn. Seems to me like the easiest, no effort no brainer "fix" would be to just be to remove makeCollapsible from AjaxRC. Obviously we'd prefer to have collapsible elements, but in my opinion — in the short term — fixing the memory leak is more important than having fancy collapsing doodads that aren't absolutely necessary. But that's Grunny's call to make. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 03:14 UTC, Friday, 14 June 2013

──────────────────────────────────────────────────────────────────────────────────────────────────── Maybe the problem is not $.makeCollapsible as such but replaceWith. replaceWith doesn't destroy any elements and it doesn't remove data-objects and events either. It simply detaches all of it from the DOM and returns it. The code may not use the return value, but the elements are probably not removed from memory regardless, because the data-objects and events are still attached:

function loadPageData() {
    var $temp = $( '<div>' );
    $temp.load( location.href + " #mw-content-text", function () {
        var $newContent = $temp.children( '#mw-content-text' );
        if ( $newContent.length ) {
            $( '#mw-content-text' ).replaceWith( $newContent );
        }
        ajaxTimer = setTimeout( loadPageData, ajRefresh );
    } );
}

Empty however removes everything - including data and events - from memory:

function loadPageData() {
    var $temp = $( '<div>' );
    $temp.load( location.href + " #mw-content-text", function () {
        var $newContent = $temp.children( '#mw-content-text' );
        if ( $newContent.length ) {
            $( '#mw-content-text' )
            .empty().append( $newContent );
        }
        ajaxTimer = setTimeout( loadPageData, ajRefresh );
    } );
}

Just an idea. --  pecoes  06:09, June 14, 2013 (UTC) 

It's a good idea, I was experimenting with empty myself. But that's why I posted my example: even when used by itself, makeCollapsible creates X nodes every time it is called, where X is the number of collapsible elements on the page. (I tried your example, and the node count still increases by X every time AjaxRC runs, unfortunately.) -452 09:19, June 14, 2013 (UTC)
I don't understand. Whatever nodes $.makeCollapsible adds would be childnodes of
  1. mw-content-text, would they not? So why would empty not remove them? O_o
Is there a specific scenario where this memory leak occurs? Collapsible basic elements? Collapsible lists? Collapsible tables? Custom collapse tags? --  pecoes  09:30, June 14, 2013 (UTC) 
I don't understand it either, it's certainly a puzzler. My theory is that makeCollapsible() is declaring a global variable and keeping an array of nodes, so they're still referenced and not deleted by empty(). But as I've not actually looked into it, that's purely speculation.
Your solution is good, it fixes all problems except the basic makeCollapsible problem, which can be proved to be still occurring by counting the nodes as Mathmagician suggested.
I'm counting the nodes at the start and end of loadPageData, and immediately before and after calling makeCollapsible.
With your code, when there is no change to RecentChanges, there is no change to the node count, but immediately after makeCollapsible, there is an increase of X nodes - which exactly the same as when just running makeCollapsible from the console.
No specific scenario, just normal "grouped recent changes". -452 09:43, June 14, 2013 (UTC)
There's no need to speculate about what $.makeCollapsible does. The code is here. And I see no global variables... Hm. --  pecoes  10:03, June 14, 2013 (UTC) 
There are a bunch of closures, though. Maybe there's a circular reference somewhere... --  pecoes  10:59, June 14, 2013 (UTC) 
I just remembered what I read 2 weeks ago: There is a known problem with onclick handler not being dealt with correctly by empty(). makeCollapsible() definitely should add X number of onclick handlers when it is called, so apart from the fact that it's apparently not checking for existing handlers each time you call it, it may not even be a problem with makeCollapsible(), it's just that when you call empty(), they're not being removed properly. -452 15:17, June 14, 2013 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Here's a simple test you can run on any mediaWiki page from the console:

(function test (t) {
    $('#mw-content-text').empty();
    
    $('<div>test ' + t + '</div>')
    .appendTo('#mw-content-text')
    .makeCollapsible()
    .click(function () {
        var c = 0;
        for (var i in jQuery.cache) c++;
        console.log('jQuery.cache', c);
        test(t + 1);
    });
}(1));

It does not appear that $.makeCollapsible causes memory leaks. --  pecoes  17:18, June 14, 2013 (UTC) 

Good to know, at least we now know it must definitely be a problem with AjaxRC. -452 18:33, June 14, 2013 (UTC)
Well, it seems AJAX caching is the culprit:
function loadPageData() {
    $.ajaxSetup({ cache: false });
    var $temp = $( '<div>' );
    $temp.load( location.href + " #mw-content-text", function () {
        var $newContent = $temp.children( '#mw-content-text' );
        if ( $newContent.length ) {
            $( '#mw-content-text' )
            .empty().append( $newContent );
        }
        ajaxTimer = setTimeout( loadPageData, ajRefresh );
    } );
}


 pecoes  19:12, June 14, 2013 (UTC) 
But disabling AJAX caching ($.ajaxSetup({ cache: false });) also causes the collapsible elements to not work at all. No "collapse/expand" arrow is visible in RecentChanges for me when I tested the script with your new loadPageData() function. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 03:41 UTC, Saturday, 15 June 2013
Yup. That's correct. I was kind of hoping it was only the images that are failing to load, but turning off caching makes it indeed necessary to run $.makeCollapsible again. Which causes memory leaks. Which brings us full circle back to $.makeCollapsible. Again. *sigh*
Soooo... Is there something wrong with the test code for $.makeCollapsible I posted above? Or is this test somehow different from Special:RecentChanges? Does the custom toggle for the collapsible cause $.makeCollapsible to leak? --  pecoes  10:08, June 15, 2013 (UTC) 

──────────────────────────────────────────────────────────────────────────────────────────────────── There appears to be a circular reference in $.makeCollapsible. It's in hookCallback in line #55. $collapsible refers to the element that gets collapsed or expanded. The callback gets attached to the toggle-button and runs after the fadeOut/In. I would think the collapsible cannot be garbage-collected because this event-handler of one its child-elements holds a reference to it. And since the garbage collector stops at the collapsible it never reaches the child with the event-handler. Does that make sense? --  pecoes  10:44, June 15, 2013 (UTC) 

Line #55? Line #55 is a comment and I couldn't pinpoint hookCallback. Just to make sure we're talking about the same thing: source code on Github: makeCollapsible. Note: I haven't reviewed makeCollapsible's source code for any potential problems yet. I was kind of hoping the problem was with the interface between AjaxRC and makeCollapsible, rather than inside makeCollapsible itself... 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 15:38 UTC, Saturday, 15 June 2013
Pecoes is talking about this: git.wikimedia.org. -452 16:16, June 15, 2013 (UTC)
The version at git.wikimedia.org is clearly newer. Not just according to its date. It also replaces outdated stuff like .bind with current stuff like .on. But Math has a point – as usual. For our purposes it's the older version Wikia uses, that counts. Now we need to look for the bug in two versions. On top of everything else. Awesome. --  pecoes  16:54, June 15, 2013 (UTC) 
If this is indeed a makeCollapsible bug (have we definitively reached that conclusion?) that is no fault of AjaxRC, I feel like it should be treated as a separate issue at this point, and that we should follow up with Kirkburn and Grunny for clarification on what should happen next. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 17:19 UTC, Saturday, 15 June 2013

──────────────────────────────────────────────────────────────────────────────────────────────────── Here is some reproduce code. I kept it as simple as possible, but I also tried to mimick Special:RecentChanges as much as possible. That's why it turned out a bit lengthy. It's meant to be tested via the console and it only works properly on Special:RecentChanges - but that's mainly because the relevant bits of CSS don't get loaded on other pages.

(function test (t) {
    $('#mw-content-text').empty();
 
    $(
      '<table class="mw-collapsible mw-collapsed mw-enhanced-rc">\
        <tbody>\
          <tr>\
            <td>\
              <span class="mw-collapsible-toggle">\
                <span class="mw-rc-openarrow">\
                  <a href="#" title="Show details (requires JavaScript)">\
                    <img src="http://slot1.images.wikia.nocookie.net/__cb62189/common/skins/common/images/Arr_r.png" width="12" height="12" alt="+" title="Show details (requires JavaScript)">\
                  </a>\
                </span>\
                <span class="mw-rc-closearrow">\
                  <a href="#" title="Hide details">\
                    <img src="http://slot1.images.wikia.nocookie.net/__cb62189/common/skins/common/images/Arr_d.png" width="12" height="12" alt="-" title="Hide details">\
                  </a>\
                </span>\
              </span>\
            </td>\
            <td>\
              &nbsp;&nbsp;Test&nbsp;' + t + '&nbsp;&nbsp;</td>\
            <td>\
              <button>reload</button>\
            </td>\
          </tr>\
          <tr><td colspan="3">hidden line</td></tr>\
          <tr><td colspan="3">hidden line</td></tr>\
          <tr><td colspan="3">hidden line</td></tr>\
        </tbody>\
      </table>'
    )
    .appendTo('#mw-content-text')
    .makeCollapsible()
    .find('button')
    .click(function () {
        var c = 0, i;
        for (i in jQuery.cache) c++;
        console.log('Test', t, 'jQuery.cache', c);
        test(t + 1);
    });
}(1));

--  pecoes  21:55, June 15, 2013 (UTC) 

Hey guys, as a heads-up I'm on vacation right now so if you don't mind Math, can you maintain this script for a bit until I come back? The only favor I'd like to ask on top of that is to leave a message on my talk when you're going to push a new change to /code.js. I might not see it immediately, but it would be nice as reference. Thanks, --Kangaroopowah (Talk) 04:56, June 16, 2013 (UTC)
I'm with Math here. Since this does not seem to have anything to do with AjaxRC, there's not much more that needs to be discussed here. It may be wise to contact Grunny or Kirkburn as Math suggested. In any case I filed a bug report at wikimedia.org. --  pecoes  10:38, June 16, 2013 (UTC) 
I left a Special:Contact message for Grunny and Kirkburn. Hopefully we'll hear back from them sometime soon. 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 03:32 UTC, Tuesday, 18 June 2013
Note: I heard back from Kirkbirn: he mentioned that he would pass this one on to someone more technically inclined. Who that is or whether it happens anytime soon or not is anyone's guess... 20px_Rin_Tohsaka_Avatar.png Mathmagician ƒ(♫) 02:17 UTC, Wednesday, 26 June 2013
Kirkburn reported the bug in a ticket, and it's in my queue. A patch has been submitted by a volunteer to MediaWiki core to fix this already (before it even entered Wikia's bugtracker! :)). I'm waiting for a few more reviews to be made to the patch before backporting it to Wikia; I'll test their patch soon either way and commit it to our repo. Cheers, grunny:~$ 11:13, June 26, 2013 (UTC)
Just an update. I backported their fix to our MW version and committed it. It will be released in just under two weeks. :) Cheers, grunny:~$ 15:39, August 9, 2013 (UTC)

Running on first load

Line 66 is loadPageData();, is there any reason not to use ajaxTimer = setTimeout( loadPageData, ajRefresh ); there instead so that the page isn't immediately refreshed? -452 13:30, June 16, 2013 (UTC)

ajaxCallAgain and namespace checks

I've added a little more documentation regarding ajaxCallAgain. Would I be correct in thinking ajaxCallAgain is checked with every iteration, meaning it can be added to at any point? This would be opposed to the other variables that are checked once as the script loads and not at any point after. It would appear that the functions being added to the array need to have their variables defined within that function instead of in an outer function, for example:

(function (window, console) {
    var trueArray = [true, true, true];

    function testFunction() {
        var falseArray = [false, false, false];
        console.log(trueArray, falseArray);
    }

    window.ajaxCallAgain = window.ajaxCallAgain || [];
    window.ajaxCallAgain.push(testFunction);
}(this, this.console));

causes errors (as I would expect). There's not very much documentation on it anyway, although it's probably a bit beyond the average person who's importing the script to their wiki.

I've also removed the namespace checks for wgCanonicalSpecialPageName === 'WikiActivity' and wgCanonicalSpecialPageName === 'RecentChanges'. wgCanonicalSpecialPageName returns a boolean (false) if it's not in the Special namespace and a string if it is. Either way, it appears perfectly safe to remove the wgNameSpace checks for those 2 conditionals. cqm 20:49, 27 Jul 2013 (UTC)

Memory Leak - Firefox

Hello, I seem to be experiencing a similar issue regarding a memory leak when AjaxRC is used as mentioned on Talk:AjaxRC#Memory_leak (Same page, just a different section). I have ruled out other possibilities but after installing this the memory leak is revealed. While it seems the previous conversation said it was fixed, it was either undone at some point since then or a new leak has arisen via Firefox ver 27.0.1 Kalbintion (Talk) 03:34, March 4, 2014 (UTC)

That was a bug with jquery.makeCollapsible and was fixed. The module hasn't been touched since afaik. Do you have a link to where you're seeing the leak? cqm 04:01, 4 Mar 2014 (UTC)
Double checked, jquery.makeCollapsible.js hasn't been edited in 7 months. cqm 04:10, 4 Mar 2014 (UTC)
It is being used on the Hexxit Wiki. After it runs an hour or two, without intervention, the memory leak is much more noticeable. Disabling it and leaving it as if it were running, the memory leak becomes much more apparent as firefox hardly changes in RAM usage with it disabled. Kalbintion (Talk) 00:10, March 5, 2014 (UTC)
I had a talk with Grunny who seems to think it's possible this could be an issue with Firefox which apparently has a history of memory issues. I'd suggest trying out Chrome instead and seeing if the problems persist across browsers. cqm 21:08, 11 Mar 2014 (UTC)

Auto-updating modules

Is it possible for this script to auto-update individual elements such as the side-rail modules, like Chat, RecentActivity, etc, without refreshing the entire page? —RyaNayR (talkcontribs) 03:01, March 11, 2014 (UTC)

In it's current state, AjaxRC will not update anything outside the content area. One option is to make a separate script for updating specific sidebar modules, such as RecentChangesModule has. cqm 21:11, 11 Mar 2014 (UTC)

Not Working

I'm trying to add it to the YouTube Poop Wiki, but after a hundred tries it won't work. Please help, is there a certain place where the code is suppose to go? Milez (talk) 00:30, June 16, 2014 (UTC)

I don't see a hundred tries, I see one try which you reverted 4 minutes later. -452 (talk) 00:42, June 16, 2014 (UTC)
Sorry, I didn't check your username, and just assumed you were the last person to edit the page.
Regardless, you never actually left the code in place for more than a few minutes at a time. Re-add that line, and don't remove it. -452 (talk) 00:47, June 16, 2014 (UTC)
Now that you have added the script, it is working. However, you appear to have copy/pasted the script from somewhere other than here without attributing the source - you should probably add that. -452 (talk) 01:51, June 16, 2014 (UTC)

Default to un-ticked?

Is there a setting we can set locally on our wikis that makes the box default to being un-ticked? Thanks! — SpikeToronto 17:22, June 16, 2014 (UTC)

Hey Spike! Technically, you could add
if (localStorage.getItem("AjaxRC-refresh) === null) {localStorage.setItem("AjaxRC-refresh", false);}
ABOVE the import, but there's no variable to set to true as of now. That's a good suggestion though- maybe in the next release. --Kangaroopowah (Talk) 02:09, June 18, 2014 (UTC)
If possible (in a future update), it would be nice if individual users could personalise this option, e.g. through their personal js pages . — SW8573 (Talk) 09:55, June 18, 2014 (UTC)
Thanks for your responses! Sorry for checking back so late. @’Roo: Would what you’ve written above work now, as is? Oddly, I find whether this is an issue or not seems to depend on which mobile browser I am using. So, I figure if I could default it to unticked where I admin, it’d be a great help. Thanks! — SpikeToronto 09:31, July 1, 2014 (UTC)

Auto-refreshing Namespaces

Auto-refreshing namespaces like auto refreshing Forum threads would be awesome - Chris Lowles 04:02, September 18, 2014 (UTC)

Was about to post a new topic, but just seen this. I'd like a way to be able to refresh all forum threads as well, with a wildcard or something. --SuperSajuuk Talk Page | Tabber Code | Channel 14:11, October 2, 2014 (UTC)

Freeze

Not sure how many people it's affecting but it seems there are a few users, myself included that get their recent wiki activity page frozen. It seems fine when logged off though and I believe the problem lies in this as I don't get this problem on wikis that don't use this code. -- {{SUBST:User:TimeShade/autosig}} 01:03, January 7, 2015 (UTC)

I am being affected by this as well. I had to get rid of this script. Note that it is not only the Wiki Activity that froze on me, but also the editor and threads. KILLIAN JONES ~ I hate you, flying jellyfish! 01:11, January 7, 2015 (UTC)

Not Working

Hi, I enabled this both on my global and on a wiki's js and it doesn't work. my global the wiki's js

-Legofan100

It works fine on http://poptropica.wikia.com/wiki/Special:RecentChanges -452 18:13, July 6, 2015 (UTC)
By "works fine", I mean I see the checkbox, so I have no reason to assume the rest wouldn't work, since you were nonspecific about what "doesn't work".
I do notice that there is an error in your site javascript, however, which may cause the actual refresh to fail. -452 18:16, July 6, 2015 (UTC)

Scripts Compatibilities

The documentation isn't very specific about how to add more scripts to be loaded when this script is loaded. How would one import another script when the page reloads? Would I have to create a function on all the scripts that are supposed to be loaded and then use ajaxCallAgain?
~Curiouscrab (talk) 21:36, August 6, 2015 (UTC)

How to disable this?

Unticking currently doesn't save properly and I'm getting fed up. I don't like this anyway. Would like to disable it via personal JS, but as it's running in a nameless function, I guess I'm screwed?--PedroM 19:11, October 6, 2016 (UTC)

I use this to ensure this version doesn't interfere with my improved version.
$(function(){
	localStorage.setItem('AjaxRC-refresh', false);
	$("#ajaxRefresh").remove();
	if (typeof ajaxTimer != "undefined") clearTimeout(ajaxTimer);
});
There are other ways to do it, but this works for me. -452 19:36, October 6, 2016 (UTC)
Thanks for this.--PedroM 04:08, October 7, 2016 (UTC)

Callback function

After encoutering some issues with the callback function, I discovered that as mfaizsyahmi pointed out in here, if you import multiple scripts, you will probably run in a "chicken and egg problem", basically AjaxRC needs to know which function to callback before the imports, but that function is not yet defined since is not yet imported. My guess is that the fix he used could be integrated directly in AjaxRC by replacing

				for (i = 0; i < ajCallAgain.length; i++) {
					// check item is a function before calling it to avoid errors
					if ($.isFunction(ajCallAgain[i])) {
						ajCallAgain[i]();
					} else {
						/*jshint debug:false */
						console.log('AjaxRC Error: Could not call non-function after reload.');
						/*jshint debug:true */
					}
				}

with

				for (i = 0; i < ajCallAgain.length; i++) {
					// check item is a function before calling it to avoid errors
					if (typeof ajCallAgain[i] == 'function') {
						ajCallAgain[i]();
					} else {
						/*jshint debug:false */
						console.log('AjaxRC Error: Could not call non-function after reload.');
						/*jshint debug:true */
					}
				}

since .isFunction() gives an error if the function is not defined. leviathan_89 18:07, October 15, 2016 (UTC)

I think you're misunderstanding the usage and implementation of ajCallAgain the same as mfaizsyahmi has previously. Consider the following:
window.foo = window.foo || [];

setInterval(function () {
	var foo = window.foo || [],
		i;

	for (i = 0; i < foo.length; i++) {
		if ($.isFunction(foo[i])) {
			foo[i]();
		}
	}
}, 15000);
The callback function re-loads window.foo and then loops through it, checking if each element is a function. What mfaizsyahmi was doing was appending the result of the function to the window.foo rather than the function reference.
I ran the above snippet in my console, then ran window.foo.push(function () { console.log('foo'); }); and waited until "foo" was output. I then ran window.foo.push(function () { console.log('bar'); }); and waited until "foo" and "bar" were output. This is essentially the 'workaround' that was stumbled upon.
An alternative to passing an anonymous function would be to do something like:
function bar() {
    console.log('bar');
}

window.foo = window.foo || [];
window.foo.push(bar);
With regards to the issue of highlightusers, you'd do window.ajCallAgain.push(highlightUsers); instead.
There's a real-life example over in runescape:MediaWiki:Wikia.js (look for siteNoticeDismiss), while the actual import is in runescape:MediaWiki:Common.js. Let me know if you want any more help :) cqm 09:06, 23 Oct 2016 (UTC)
As a quick follow up regarding your fix, $.isFunction uses the toString function which ends up with something like the following:
function foo() {}

Object.prototype.toString.call(foo);
// [object Function]
Object.prototype.toString.call(foo());
// [object Undefined]
Unless your function happens to return a function, it's never going to be considered as such. cqm 09:12, 23 Oct 2016 (UTC)
Sorry I just saw your answer, so if I understand correctly the callagain should be added in HighlightUsers's code rather then my own custom js, is that correct? Can you update that code then? I asked the author if he was still maintaining it but he said he was not and he'd be happy if someone could take over. leviathan_89 22:15, November 18, 2016 (UTC)
I've made some tentative changes, but I'm not familiar with the script. Are you able to test it somewhere to make sure it's working as expected? cqm 10:35, 19 Nov 2016 (UTC)
Seems to work, I've pushed the changes. leviathan_89 16:26, December 2, 2016 (UTC)

Add pages

Could Special:Watchlist, Special:WikiActivity, Special:Log, and Special:Contributions please be added as pages that the script loads on by default? --Sharkie 01:44, October 23, 2016 (UTC)

I don't see what you're gaining here. It's pretty simple to add the pages to your own configuration and it avoids any side-effects loading the script on those pages might have such as causing other scripts to malfunction. cqm 08:44, 23 Oct 2016 (UTC)

Does not work in MediaWiki:ImportJS / No funciona en MediaWiki:ImportJS

I do not know if I've done anything wrong but the script does not work in MediaWiki:ImportJS.


No sé si he hecho algo mal pero el script no funciona en MediaWiki:ImportJS.
--GiancarloBP (talk) 19:25, December 17, 2016 (UTC)


Ok, it actually works but only in Recent Changes. I added WikiActivity, awaiting approval.
--GiancarloBP (talk) 04:08, December 18, 2016 (UTC)

Refreshing After Clicking "See More Recent Activity"

Not sure if this is the same issue as an above discussion, but I would like to recommend a change, if possible, that would possibly reset the countdown to refresh after someone clicks on the "See More Recent Activity" link at the bottom of Special:WikiActivity. My biggest problem with this script is when it refreshes shortly after expanding the activity list (I've seen others on wikis confused by this behavior too). DEmersonJMFM 02:07, February 2, 2017 (UTC)

WikiActivity isn't something I use very often so I'm not sure what the expected behaviour should be here. It seems that when you click "See More Recent Activity", the list expands, but on the refresh it reverts back to the un-expanded version. Is this correct? cqm 11:50, 2 Feb 2017 (UTC)
Yes, the expanded version could be open for just a very brief window before it closes again. Not a pleasant experience looking at older activity. DEmersonJMFM 15:28, February 2, 2017 (UTC)
Advertisement