Maybe provide an option for the position. Agent Zuri ProfileMessage WallBlog 10:38, July 5, 2017 (UTC)
Multiple rail modules
Hey! Is it possible to adapt this script to make it able to add multiple rail modules? For instance, a template:RailModule and a template:RailModule2 or something. Also, the doc states that you can rename Template:RailModule to whatever you want but doesn't explain how, does it involve window.dev somehow? I think the doc should explain that, mostly for users that want to put the rail module in MediaWiki namespace instead.--VTechnobliteratorTC 17:00, June 6, 2016 (UTC)
I have made this quick draft. It uses the railModules variable in which you store the pages you'll be collecting the extra modules from.
Oh, perfect. I could likely use something very similar to this. Thanks!--VTechnobliteratorTC 12:57, June 7, 2016 (UTC)
Could you make your script look for a page like Template:RailModules (or even better: MediaWiki:Custom-Rail-Modules) as well which works like MediaWiki:ImportJS? Benefit: The user can add options separated by pipes. And you could add a class to them (e.g. for styling).
Is there a way to force this module to show up on the Main Page? I know I can just input the {{RailModule}} Template directly into the Main Page, but then it wouldn’t have the...uh, the border I guess, that surrounds Rail Modules. Is there a way to make the module show up on the main page with the border, or a way to emulate the border with a div or something? ~Ursuul 12:08, January 20, 2017 (UTC)
Yeah, it's me again. You could probably use <mainpage-rightcolumn-start /> + <mainpage-endcolumn /> and surround your content with something like <div id="mp-railModule" style="border:1px solid #000;"></div>. I do something like that on my test wiki's main page.
Alternatively, you could use float:right; to replicate a RailModule's righthand placement, like so:
Hey, do you happen to know how to make the “Create Blog Post” button on boxed Bloglists go away? I’m fine with it on the sitewide module, but on the MainPage module it just gets in the way. The lines are scrunched up a bit. The module itself is the same width as usual, but the Bloglist is wider for some reason inside the div than it is inside the RailModule. ~Ursuul 09:13, January 21, 2017 (UTC)
vs Main Page Module
I suppose you could do...
.WikiaBlogListingBox.wikia-button{display:none;}
Alternatively, you can use these styles below to duplicate the look of the actual rail module, as shown in the image.
If I use padding to replicate that on the main page, will that shrink the Bloglist down to the appropriate size? (also what element would I add the padding to? Like how?)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I tried them both individually & together. The first option doesn’t remove the line, the second one does. Both of ’em together looks even better without the random button, but now there’s a bit of a large space where the old button was. In addition, in the RailModule, the “See More” button is inside the box, whereas in the Div the “See More” button is outside the box & to the left instead of the right. What should I do to fix those? Should I set
I should also note that since you apparently cloned the actual rail module classes on the main page, changes to the CSS will affect both, which is likely what you're experiencing. To affect only the main page, prefix the main page-only rules with body.page-Diepio_Wikia. CoH☎ 11:56, January 21, 2017 (UTC)
Site-wide Rail
Didn’t quite work. See images. Response to Addendum: Ok, I’ll try it. Like this?
Beautiful. Literally almost perfect besides the upper space & the fact that the line came back.
Yes. That should affect only the main page. We will deal with the line and unused space once we get these bugs worked out. I should have realized you had used the rail module classes. My bad. CoH☎ 12:07, January 21, 2017 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Ok it’s in the Wikia.css. Here’s what it looks like now. ~Ursuul 12:11, January 21, 2017 (UTC)
Okay, much better. Now give me a second to sort out this border and spacing issue on both pages. CoH☎ 12:14, January 21, 2017 (UTC)
This is janked because of the shared classes, but this should work:
I would toss this at the bottom, below any of the other blog module rules. I have no idea how poorly all these workarounds are going to interact with each other.
Gotcha, I’ll move it to the bottom now. Meanwhile, do you want me to toss you sysops? Because the padding vanished when I added this. Look. ~Ursuul 12:29, January 21, 2017 (UTC)
Sysops me in five minutes. I have to step away from the computer for a few minutes. If you wish, perhaps you should revert or comment out all the changes. At this point, I just need to start again and ensure that nothing is interfering. CoH☎ 12:32, January 21, 2017 (UTC)
Why is there no warning that this could violate the ToU?
Removing stuff from the sidebar rail is definitely a ToU violation, but I don't think you're free to add anything you want (especially at the top). -- Fandyllic (talk · contr) 20 Jun 2017 2:20 PM Pacific
Because its not a ToU violation. There are other scripts that do the same thing (ex DiscordIntergrator) that add things to the rail, and they can be used sitewide. Also it adds to the bottom of the rail, not the top. --Sophie 23:01, June 20, 2017 (UTC)
Overlapping
The FANDOM recirculation module overlaps with this when scrolling down. leviathan_89 09:58, August 4, 2017 (UTC)
<noinclude> Tags
Attempting to transclude a documentation (& categorize the template) causes the documentation to be loaded in the right rail even when surrounded in <noinclude> tags. Is there a way to make the script ignore content between such tags, as normal templates do? UrsuulTalkCMDate4:31 AM Friday, August 18, 2017 (UTC)
Additional Modules
"(Allow multiple modules, make {{PAGENAME}} usable, switch to parsing with action=parse to make <choose> usable)"
This was said in one of the edit summaries, but I still do not understand how to add another module.—|| Grudgeholderr ||— 01:55, March 3, 2018 (UTC)
Proposal to add backwards-compatible per-module prepend configurability
The current implementation supports multiple modules (via window.ARMModules) and prepend configurability (via window.ARMPrepend) for the entire sequence of modules. I'd like to propose extending this script to permit per-module prepend configurability. A sample patch and small set of sanity tests follow.
// expectation: both modules are appendedwindow.ARMModules=['MediaWiki:Communitypage-tasks-header-welcome','MediaWiki:Communitypage-subheader-welcome'];// expectation: both modules are prependedwindow.ARMPrepend=true;window.ARMModules=['MediaWiki:Communitypage-tasks-header-welcome','MediaWiki:Communitypage-subheader-welcome'];// expectation: first module is prepended, second module is appendedwindow.ARMModules=[{page:'MediaWiki:Communitypage-tasks-header-welcome',prepend:true},'MediaWiki:Communitypage-subheader-welcome'];// expectation: first module is appended, second module is prependedwindow.ARMPrepend=true;window.ARMModules=[{page:'MediaWiki:Communitypage-tasks-header-welcome',prepend:false},'MediaWiki:Communitypage-subheader-welcome'];
puxlit (talk) 06:35, January 25, 2019 (UTC); edited 07:27, January 25, 2019 (UTC)
As of revision 112227, ARM tries to cache responses via smaxage/maxage. However, since the parse API module's cache mode is anon-public-user-private, and due to what appears to be an overzealous VCL rule, the net effect is that: (a) clients still have to make a request per page load; and (b) the only caching that occurs is at the edge for anon users. I'd like to propose using localStorage in a manner similar to I18n-js to cache module pages and thereby minimise the number of requests. Broad points against such a change (as voiced when the idea was floated in #javascript) include: (a) potential GDPR issues; and (b) potential localStorage bloat. Thoughts? puxlit (talk) 12:53, February 22, 2019 (UTC)
me personally is not a big fan of keeping unspecified amount of data in the persistent cache, especially if it has so strong limitations (right now, chrome allows to use 5mb). due to nature of ls and current site structure, all languages will have shared ls (one ls per origin), that means the script will store cache on per-language basis. the more languages has wiki, the more amount of ls will be used. 2nd problem is cache itself: it can't be stored for too long time (i do expect for 1 hour of max age). why: because of long-living cache, and virtually absent methods of cache invalidation, it will be... surprising for users that will change rail template and will wait for visible effect at reasonable amount of time. thus, the size and time issues leaves to us the only option (outside of db engine): session storage. ss will be cleared once tab\window is closed, so it solves both problems. at the same time, this solution itself is part of the problem: cache can't be stored for long time and can't be shared by different tabs, so the real benefit will be for refresh-like actions only. long story short: doesn't worth it, like for me.
ps long-living (ls) cache should be optional and turned off by default, in order to keep users awared about it; when short-living (ss) might be used by default. Fngplg (talk) 17:48, February 22, 2019 (UTC)
RE: localStorage bloat, I wouldn't expect the combined size of ARM-supplied rail module pages to exceed more than a few kilobytes for the majority of wikis, nor would I expect the average user to visit more than a handful of wikis on the same origin. RE: cache duration, currently maxAge ∈ [0, 86400] seconds, with five minutes as the default. For wikis where admins know their rail modules rarely change, setting maxAge to one day is a sensible decision, for which this proposed caching mechanism would save one request per page load where ARM would be active. RE: cache invalidation, I agree that browser-guaranteed purging mechanisms (like sessionStorage) would be ideal, though if ARM is running on load for most pages anyway, it would have ample opportunity to clean up after itself. RE: using sessionStorage, whilst it's not impossible to share KVs across tabs, it might well be more complexity than is warranted. I suppose IndexedDB is an option… puxlit (talk) 18:40, February 22, 2019 (UTC)
user that going through bunch of lang wikis is not so rare case: when one renaming page with interlang links on it, the one might want to go to all these langs in order to update links. there is might be solution: time-based cache as shared parent for lang-based one. smth like: armcache: {expire: time, langs: {lang1: cache1, lang2: cache2}} when expire reached, kill all {lang}. sure, it will force to update module data on all lang-specific wikis, but we agreed that will be relatively rare case. it will solve ls overloading issue, effectively keeping data for only 1-few recently visited langs Fngplg (talk) 19:03, February 22, 2019 (UTC)
Mmm I'm partial to this approach. puxlit (talk) 20:08, February 22, 2019 (UTC)
Alternatively, we could just use the Cache API and forgo caching for browsers that don't support it. puxlit (talk) 11:49, February 23, 2019 (UTC)
according to mdn, the only difference would be autopurging by browser, when cache is full. in trade for more complex code Fngplg (talk) 11:58, February 23, 2019 (UTC)
it seems like .cache version was reimplemented via localstorage. ls part will be much simplier, if u will not try to mimic .cache: just store ls.cache as .setItem(, {expires: date, data-lang:o}) where data-lang is data-en, data-ru etc, o is {template1: data, template2: data}, data is parsed data, that might be injected directly to the dom. then check ls.cache for .expires. note: it will not preserve data-fr and data-ru on en wiki, cuz u just don't need it. it just stores all caches for some period. Fngplg (talk) 09:29, February 24, 2019 (UTC)
I actually started with the localStorage implementation, then translated it to use the Cache API. I'm not a fan of using one expiry timestamp to invalidate the whole cache, as maxAge is configurable per-module, there's no compelling reason to flush the cache every time a user switches language wikis, iteration cost is likely to be small, and honestly the invalidation logic is not complex. puxlit (talk) 10:07, February 24, 2019 (UTC)
Changes implemented in Special:Diff/112227/113211. I'd originally planned to further document the changes prior to review, but somebody submitted the changes around 2019-04-09T16:55Z. This script was added to Kocka's GDPR audit in Special:Diff/117254. puxlit (talk) 05:27, May 30, 2019 (UTC)
Proposal to special-case handling of modules containing AjaxPolls
Recently, Zurgatnoted that rail modules containing AjaxPolls no longer appeared to work. The primary root cause appears to be a change on my part: to batch the request for multiple rail modules together, the HTML returned by the API now goes through a $.parseHTML(…), which has the effect of stripping out the script tags that AjaxPoll inserts.
Since the client-side JS does a single-shot init (and doesn't listen on something sensible like wikipage.content), preserving these script tags will still lead to a race, especially on pages with AjaxPolls.
To mitigate these effects, I'm proposing for ARM to: (i) identify rail modules containing AjaxPolls and disable client-side caching; and (ii) execute the following workaround.
mw.hook('wikipage.content').add(function($elem){var$polls=$elem.filter('section.railModule.rail-module').find('.ajax-poll>form');if(!$polls.exists()){return;}if(!window.AjaxPoll){// AjaxPoll has not yet loaded.// Loading `ext.wikia.ajaxpoll` only gets us the CSS, and not the JS; see <https://github.com/Wikia/app/blob/release-869.001/extensions/wikia/AjaxPoll/AjaxPoll.php#L29-L33>.// Instead, we'll use JSSnippets; see <https://github.com/Wikia/app/blob/release-869.001/extensions/wikia/AjaxPoll/AjaxPoll_body.php#L234-L242>.JSSnippetsStack.push({dependencies:['/extensions/wikia/AjaxPoll/css/AjaxPoll.scss','/extensions/wikia/AjaxPoll/js/AjaxPoll.js',],callback:function(){window.AjaxPoll.init();},id:'AjaxPoll.init',});}elseif(window.AjaxPoll.initialized){// AjaxPoll has already loaded, but we're not sure if _our_ polls have been wired up.// We'll manually wire ourselves up if we think it's necessary; see <https://github.com/Wikia/app/blob/release-869.001/extensions/wikia/AjaxPoll/js/AjaxPoll.js#L63-L82>.$polls.each(function(){varevents=$._data(this,'events');if(!events||!events.submit){$(this).submit(window.AjaxPoll.submit);}});}});
Per discussion, resolved by preserving script tags; no special-casing required.
YouTube Subscribe Button, Facebook Activity, Twitter Activity And RSS Feeds Not Supported In AddRailModule's Template
Hi,
In regards to this awesome template and extension feature, I've came across a few issues while using this feature on my own wiki.
YouTube Subscribe Buttons (added as a template into the template of RailModule), Twitter Activity (added as a template into the template of RailModule), Facebook Activity (added as a template into the template of RailModule) and RSS Feeds (added as a template into the template of RailModule) are not supported in the template of RailModule even if you purge the templates and purge the template of RailModule afterwards, wait 1 hour and then wait 24 hours, the issue still persists. Apart from that issue, the rest of the template and extension works and functions correctly from multiple various browsers with each browser being fully updated.
Followed installation instructions found at AddRailModule.
Configured and installed the extension and template as per the instructions.
Created various templates for the sidebar. Added templates into the template page on my own wiki at Template:RailModule.
Purged all template pages added to the RailModule template before saving and purging the RailModule template.
Checked the template out on various browsers (browsers updated before checking).
Why doesn't the template not support YouTube Subscribe Buttons, Facebook Activity, Twitter Activity and RSS Feeds? I've tried the codes without them being templates and tried them as templates, the issue still persists.
Any suggestions on how to fix this issue is most appreciated.
Warren Woodhouse | Blog | Talk | Videos | Quote: "It's a funny thing, ambition. It can take one to sublime heights or harrowing depths. And sometimes they are one and the same." - Quote By: Emily Kaldwin (Dishonored, video game) 14:21, November 2, 2019 (UTC)
Hey there, we've made changes to AddRailModule and YouTubeButton that, once approved, should address the issues you've been having. However, I strongly urge you to cut down on the inordinate amount of clutter you're putting in your rail. puxlit (talk) 13:52, November 4, 2019 (UTC)
Noinclude tags
Would it possible to exclude the content between noinclude tags from loading? Adding a documentation breaks the script, but having a template without one is not ideal. leviathan_89 12:55, October 24, 2020 (UTC)
It shouldn't be rendering content within <noinclude> tags. Where is that happening? -- Cube-shapedgarbage can 21:06, October 24, 2020 (UTC)
Apologies, I retried and indeed it's working. I think there was a separate error that broke the script when I tried the first time. leviathan_89 21:38, October 24, 2020 (UTC)
Show only to registered users
Would it possible to add an option to show the module only to registered users? leviathan_89 13:19, October 25, 2020 (UTC)
I have figured it out, but the configuration part is very badly written, as it doesn't tell you where you input these settings. I was confused for at least some minutes and was about to input it in my Wikia.css, till I figured out it was JavaScript.
Where should I put the code in the Configuration section?
I'm new to this and it hasn't been made clear where exactly I should put the blocks of code in the Configuration section. Could someone kindly inform me where?
LILProductions (talk) 20:52, 21 March 2021 (UTC)
The MediaWiki:Common.js page on your wiki. -- Cube-shapedgarbage can 20:58, 21 March 2021 (UTC)
Duplicate TOC icon in FandomDesktop
This script causes the addition of a second Table of Contents SVG icon in the article area on the FandomDesktop skin. --SlyCooperFan1 (talk) 04:06, 9 June 2021 (UTC)
As discussed on the Fandom server, this is a Fandom bug where they append an additional icon every time the wikipage.content hook fires. -- Cube-shapedgarbage can 23:39, 25 June 2021 (UTC)
Double-run prevention
Is there a reason why the script doesn't have a double-run prevention? A wiki has been mistakenly importing it twice (ImportJS and a gadget) and the module was indeed appended twice. I would go ahead and fix it but I want to make sure there is nothing I'm missing here. (Also there is another unsubmitted change there for some reason). Nam 18:23, 23 October 2021 (UTC)
Customization policy violation
Per the w:customization policy, "Additional elements and modules are allowed to be placed in the right rail, below the default elements." This feature violates this rule, as it adds rail widgets above the default elements. This feature should be altered to add modules below the default elements, while perhaps leaving an option to add them above, which would only function if used through user JS.
I don't have the know-how to do this, but I thought I should bring this up. Thanks for any help you can provide. Mr. Starfleet Command(talk • contribs) 22:29, 13 June 2024 (UTC)
By default (i.e. without setting the prepend option), modules are appended below the default elements and above the sticky bottom ads. (Note that Popular Pages lives in that sticky bottom ads container; from my perspective, it's an ad.) The customization policy doesn't explicitly allow prepending, but staff have let this slide on a case-by-case basis (e.g. with various Discord modules). For AddRailModule, Rappy (who was staff at the time) documented here that prepending one module was permissible. puxlit (talk) 12:38, 14 June 2024 (UTC)
OK, those are all good points, but allow me to give a counter-argument.
On a wiki that uses this feature without any configuration (so the default settings, no prepend), when I am signed-out, an ad is at the top of the rail, followed by a Discord chat widget (because this wiki uses DiscordChat, also without any configuration). Below this is the Recent Images module, next the module added by this feature, and then the Popular Pages module (or an ad, it switches back and forth without warning sometimes).
On that same wiki but when I am signed in (with my ads preference set to "show all ads"), an ad is at the top of the rail, followed by the Discord chat widget. Below this is the Recent Images module, next the module added by this feature, then the Page Tools module, and finally the Recent Wiki Activity module. (With my ads preference set to not show all ads, it's the same, just without the top ad.)
The customization policy requires "[a]dditional elements . . . to be placed . . . below the default elements." It also stipulates that additional elements "may not push down the placement of the advertisement module." Therefore, all right-rail features on the Dev Wiki that put anything above the absolute bottom – including this feature and the Discord ones – violate the CP.
Now, let's also look at Rappy's comment. It explicitly allows us to place a maximum of one module above the Recent Wiki Activity module (the bottom of the rail when logged in). However, this feature always adds a module above the bottom element – using the prepend option simply sticks it even higher. So, we should revise this feature to allow multiple widgets at the bottom but only one higher up.
Also, this means that using this script as it currently is (or using the prepend option after the changes I am suggesting are implemented) in conjunction with any of the Discord widgets would not be allowed, as it would place more than one widget above the bottom default element.
Sorry this got so long ;) Hope I was clear, and looking forward to hearing back from you so you can tell me your view on all this. Thanks, Mr. Starfleet Command(talk • contribs) 14:49, 14 June 2024 (UTC)
Rappy's dispensation was written at the end of 2019. Back then, modules like Recent Wiki Activity weren't placed in the sticky bottom ads container.
Now they are.
Currently, default elements that don't live in the sticky bottom ads container include the Recent Images module; these are the modules relative to which AddRailModule will insert before/after.
It is not AddRailModule's job to ensure the unwritten prepend limit is observed in conjunction with other scripts. The onus is on wiki admins to ensure their configuration is compliant enough not to raise Fandom Staff's ire.
And to be frank, Fandom Staff aren't pedantic about this. They mainly care that ads aren't displaced. This means inserting modules below top ads (which AddRailModule does when prepend is set) and above bottom ads (which AddRailModule does by not inserting modules into the sticky bottom ads container). puxlit (talk) 15:56, 14 June 2024 (UTC)
New right rail hook
Should this script be updated to make use of the relatively-newfandom.rightrail.loaded hook? I imagine this would make the script more reliable, or at least more elegant/streamlined. Mr. Starfleet Command(talk • contribs) 17:33, 8 October 2025 (UTC)
