Last modified: 2011-03-13 18:05:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12666, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10666 - Create system message MediaWiki:Sysop.js
Create system message MediaWiki:Sysop.js
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2007-07-23 11:47 UTC by Chad H.
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Chad H. 2007-07-23 11:47:04 UTC
Sometimes, various projects will have scripts that are designed for sysops only, and they carry no functionality for regular users. Being able to separate these from Common.js and thus reduce loading times for non-sysops would be a good benefit.

Easiest method requires adding a new method to Skin.php/SkinTemplate.php called getSysopJs(), and the patch for RawPage.php would be as follows:

Index: RawPage.php
--- RawPage.php	(revision 24329)
+++ RawPage.php	(working copy)
@@ -153,6 +153,7 @@
 				return $sk->getUserStylesheet();
 			} else if($this->mGen == 'js') {
 				return $sk->getUserJs();
+				return $sk->getSysopJs();
 		} else {
 			return $this->getArticleText();
Comment 1 Chad H. 2007-07-23 12:28:33 UTC
Please let me know if I'm completely off-base here, because I'm just starting to work with the MediaWiki software, and I'm trying to get used to how everything works. With the diff above and this diff for Skin.php, I think we can make a sysop-only JS. Thanks for the feedback.

Index: Skin.php
--- Skin.php	(revision 24329)
+++ Skin.php	(working copy)
@@ -440,6 +440,32 @@
+	 * This returns MediaWiki:Sysop.js, designed to only be returned for users
+	 * with the +sysop bit. Keeps filesize down for most users, but allows sysops
+	 * to have their own custom JS.
+	 *
+	 * @return string Raw JavaScript to be returned
+	 */
+	public function getSysopJs() {
+		wfProfileIn( __METHOD__ );
+		global $wgUser;
+		if (in_array( 'sysop', $wgUser->getEffectiveGroups()))
+		{
+			global $wgStylePath;
+			$s = "/* generated javascript */\n";
+			$s .= "var skin = '" . Xml::escapeJsString( $this->getSkinName() ) . "';\n";
+			$s .= "var stylepath = '" . Xml::escapeJsString( $wgStylePath ) . "';";
+			$s .= "\n\n/* MediaWiki:Sysop.js */\n";
+			$sysopJs = wfMsgForContent('sysop.js');
+			if ( !wfEmptyMsg ( 'sysop.js', $sysopJs ) ) {
+				$s .= $sysopJs;
+			}
+			wfProfileOut( __METHOD__ );
+			return $s;
+		}
+	}
+	/**
 	 * Return html code that include User stylesheets
 	function getUserStyles() {
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-23 18:20:38 UTC
Why don't you just do if("sysop" in wgUserGroups) { document.write( '<script src="/wiki/MediaWiki:Sysop.js?action=raw"></script>' ) } or whatever?  I don't see any need for this at all.
Comment 3 Chad H. 2007-07-23 18:31:38 UTC
The idea had been thrown around before, but I figured a server-level solution would be ideal.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-23 19:25:07 UTC
I don't see why.  It assumes that the wiki has a lot of sysop-specific JS, otherwise it's going to be *slower* than just sticking it in Common.js: there will be an extra HTTP request.  This is not useful for most wikis, which overwhelmingly don't have sysop-specific JS if they have any site-specific JS at all, and in fact I would argue it's not useful for any wikis at all, since the extra time taken from a document.write is negligible given that most sysops will be visiting frequently and therefore keep the JS in their browser cache.  I would suggest WONTFIX, unneeded feature that can equally be solved by users on the frontend in the rare case they want it.
Comment 5 Chad H. 2007-07-24 00:11:44 UTC
I suppose you're right. I'll go ahead and WONTFIX it myself.
Comment 6 Rob Church 2007-07-24 02:55:00 UTC
In future, submit patches as attachments with the right properties set; it makes reviewing easier.

Note You need to log in before you can comment on or make changes to this bug.