Last modified: 2010-05-15 14:35:44 UTC
Right now adding site-specific links to the sidebar requires some digging in the skin code -- for each skin used. This is a frequently requested thing, and it should be possible to simply define an array in LocalSettings.php or put a list in a specially formatted message. This ought to cover most cases of "I want to add a link to my X page in the sidebar".
Changed in CVS HEAD: /** Navigation links for the user sidebar. * 'text' is the name of the MediaWiki message that contains the label of this link * 'href' is the name of the MediaWiki message that contains the link target of this link. * Link targets starting with http are considered remote links. Ones not starting with * http are considered as names of local wiki pages. */ $wgNavigationLinks = array ( array( 'text'=>'mainpage', 'href'=>'mainpage' ), array( 'text'=>'portal', 'href'=>'portal-url' ), array( 'text'=>'currentevents', 'href'=>'currentevents-url' ), array( 'text'=>'recentchanges', 'href'=>'recentchanges-url' ), array( 'text'=>'randompage', 'href'=>'randompage-url' ), array( 'text'=>'help', 'href'=>'helppage' ), array( 'text'=>'sitesupport', 'href'=>'sitesupport-url' ), ); Override this array to customize the sidebar. Keep in mind that both text and href are NAMES of MediaWiki messages that point to the text/location to be used!
*** Bug 690 has been marked as a duplicate of this bug. ***
We may have a better way to handle sidebar. Just treat it like a usual page in mediawiki, and thus users can edit it and keep revision information for it. Some examples are http://www.pmwiki.org and twiki.org. Both of them support sidebar editing. (In reply to comment #0) > Right now adding site-specific links to the sidebar requires some digging in the skin > code -- for each skin used. > This is a frequently requested thing, and it should be possible to simply define an > array in LocalSettings.php or put a list in a specially formatted message. This ought > to cover most cases of "I want to add a link to my X page in the sidebar".
I have implemented this at wikidev.net, it does nil security checks though (just inserts the plain html from [[MediaWiki:Navihtml]] if that's non-empty). Didn't check this in because of security implications for wikimedia sites.
Another possibility is to have user-specific sidebars in (e.g.) [[User:<username>/sidebar.html]] just like user-specific overrides to the skin in [[User:<username>/<style>.js]] and [[User:<username>/<style>.css]]. That way security problems don't arise (I assume only the concerned user is allowed to edit the style files, or else that'd be a security problem in itself that is live on MediaWiki sites).
How about just a normal MediaWiki message like: * [[Main Page]] * [[{{ns:4}}:Community portal|Community portal]] [...] Is there any specific reason why it isn't like that already?
(In reply to comment #6) > How about just a normal MediaWiki message like: > > * [[Main Page]] > * [[{{ns:4}}:Community portal|Community portal]] > [...] > > Is there any specific reason why it isn't like that already? oh, yes. Implement MediaWiki:Sidebar as wiki-code instead of plain HTML. But I'd think per-user sidebar customization rocks.
I took at shot at it the other day, I made a MediaWiki called "Navbar" that contained: * [[{{int:mainpage}}]] * [[{{int:portal-url}}|{{int:portal}}]] * [[{{int:currentevents-url}}|{{int:currentevents}}]] * [[{{int:recentchanges-url}}|{{int:recentchanges}}]] * [[{{int:randompage-url}}|{{int:randompage}}]] * [[{{int:helppage}}|{{int:help}}]] * [[{{int:sitesupport-url}}|{{int:sitesupport}}]] And then changed the appropriate code to output after having run it throught the parser, the only problem that I can see with that approach is that it won't have <li id="n-foo"> like the current output so styling of individual list items will not be possible, other than that it works fine, and thanks to the {{int: syntax it will automatically change like the rest of the interface when the user switches languages. So, how does doing it like that sound?
i think that syntax is too complex for what it does. is there a reason to allow arbitrary wikitext in the sidebar instead of using a simpler list format? something like: mainpage portal portal-url search search-url where the first word is the message name of the title, and the second is the message for the url, or defaults to the same as the title. (it could even have another column for the CSS class, to allow the id="" of the current elements - i can't think of a reason that would be immediately useful, but you might want to move a particular item elsewhere, perhaps).
(In reply to comment #9) > i think that syntax is too complex for what it does. Well true a custom format could be made, but we've been actively moving away from HTML in MediaWiki: messages now to wikitext and having a one-size-fits-all in these messages is simpler. Anyway, I've commited the change to CVS now, marking this as FIXED, please reopen it if you don't feel this explanation is satisfactory or you still think another format should be used.
Can you do a before-and-after benchmark comparison? Since this is going to be rendered on every page view, it's worth confirming that it doesn't unduly slow things down. In the past at least, using any {{...}} variable construct in a message incurred an initialization penalty, so I went to some effort to avoid them in messages shown in the default skin.
(In reply to comment #11) > Can you do a before-and-after benchmark comparison? > > Since this is going to be rendered on every page view, it's worth confirming that it > doesn't unduly slow things down. In the past at least, using any {{...}} variable > construct in a message incurred an initialization penalty, so I went to some effort to > avoid them in messages shown in the default skin. but doesn't that happen anyway, since the menu is composed of messages which need to be loaded first?
Since those messages were not wikitext and didn't contain any {{...}} variable interpolations, the variable interpolation initialization wouldn't happen. There've been changes to how this works so it may or may not still be a problem, but adding wikitext parsing on every page may cause some overhead and should be checked.
Turns out that it sucks performance-wise and breaks the access keys, reopening the bug. I'm going to redesign it using the following format: * navigation ** mainpage|mainpage ** portal-url|portal ** currentevents-url|currentevents ** recentchanges-url|recentchanges ** randompage-url|randompage ** helppage|help ** sitesupport-url|sitesupport This'll have the nice side-effect that people can add their own custom boxes by just adding another top level box with * and then put items in it with **.
Removing keywords as the enhancement is undergoing re-enginmeering
Commited the changes to CVS, since it now supports multiple sidebars this also solves bug 1764. Marking this as FIXED.
Created attachment 612 [details] Patch for optional use of Mediawiki: messages I was going to post this on Bug 2424, but it probably belongs here. The new sidebar also should be kept KISS. The change is a big improvement, but it's still using Mediawiki: messages for all the content. This makes editing the sidebar much harder than it should be. Especially when adding new sections, as neither the url nor the text will be set, meaning two new Mediawiki: messages have to be created for every entry. The attached patch makes a minor syntax change. Lines started with **# are substituted as the current function does. On lines with only **, the text and url are taken as literal text and literal pagename. The choice of **# was to avoid associations to a two-tiered structure with ***, but can of course be changed. If there is more favor for substitution being default, the roles can be switched so ** substitutes and **# doesn't. The patch also adds whitespace trimming around the | so "page | page-url" doesn't cause nasty errors. Took me a while to figure out what was going wrong.
(In reply to comment #17) > Created an attachment (id=612) [edit] > Patch for optional use of Mediawiki: messages > > I was going to post this on Bug 2424, but it probably belongs here. The new > sidebar also should be kept KISS. The change is a big improvement, but it's The reason it's designed the way it is is to KITT (Keep it translateable, stupid), your patch would only work on a wiki where noone wished to use an interface language other than the default one, and therefor I don't belive it should be supported.
(In reply to comment #18) > The reason it's designed the way it is is to KITT (Keep it translateable, > stupid), your patch would only work on a wiki where noone wished to use an > interface language other than the default one, and therefor I don't belive it > should be supported. This is not for use with interface links, it's for adding regular page links to additional sidebar blocks. I fully understand the need for MW to be international, but this is an issue with local installations. Is it realistic to expect that for every link added to the sidebar, the admin is to hunt down the translation in 80+ languages and add these manually to the language files? Even if he did, what good would it do? A typical wiki has one language. All the articles, article names, links, etc are in that language. A "Blacksmith" link in the sidebar might read "Grovsmed" instead, but the page and page title would still be English. All you get is a user who doesn't understand why the sensible link he clicked leads to gibberish. The suggestion is allow separatation between interface links (which should be translated) and simple page links (which it doesn't make any sense to translate). It's like including [[Blacksmith]] on the page, it's untranslated because it's just a link.
(In reply to comment #17) > Created an attachment (id=612) [edit] > Patch for optional use of Mediawiki: messages > > The attached patch makes a minor syntax change. Lines started with **# are > substituted as the current function does. On lines with only **, the text and > url are taken as literal text and literal pagename. The choice of **# was to > avoid associations to a two-tiered structure with ***, but can of course be > changed. If there is more favor for substitution being default, the roles can > be switched so ** substitutes and **# doesn't. Why not just use ** all the time and use the literal value when the MediaWiki: message in question doesn't exist, for example: ** Category:Games|Games would look up Category:Games with wfMsgForContent( 'Category:Games' ), now we'll presume that MediaWiki:Category:Games doesn't exist so the wfMsgForContent function will return <Category:Games>, the sidebar generator could test that and put in the literal value. However that would mean that you couldn't have literal values with the same names as messages that do exist.
