Last modified: 2010-05-15 14:35:44 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 T2419, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 419 - Make it easier to add links to the sidebar (navbar)
Make it easier to add links to the sidebar (navbar)
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal enhancement with 5 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 690 (view as bug list)
Depends on:
Blocks: 1764
  Show dependency treegraph
 
Reported: 2004-09-08 00:23 UTC by Brion Vibber
Modified: 2010-05-15 14:35 UTC (History)
4 users (show)

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


Attachments
Patch for optional use of Mediawiki: messages (1.29 KB, patch)
2005-06-16 18:45 UTC, Dashiva
Details

Description Brion Vibber 2004-09-08 00:23:58 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".
Comment 1 JeLuF 2004-10-03 11:29:24 UTC
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!
Comment 2 Rowan Collins [IMSoP] 2004-10-11 19:53:18 UTC
*** Bug 690 has been marked as a duplicate of this bug. ***
Comment 3 kissall 2004-10-12 19:27:33 UTC
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".

Comment 4 Gabriel Wicke 2005-02-21 18:05:44 UTC
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.
Comment 5 Wikipedia:en:User:Paddu 2005-03-27 12:47:05 UTC
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).
Comment 6 Ævar Arnfjörð Bjarmason 2005-04-01 17:18:06 UTC
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?
Comment 7 Wikipedia:en:User:Paddu 2005-04-02 07:04:21 UTC
(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.
Comment 8 Ævar Arnfjörð Bjarmason 2005-05-15 18:10:05 UTC
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?
Comment 9 River Tarnell 2005-05-23 14:16:51 UTC
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). 
Comment 10 Ævar Arnfjörð Bjarmason 2005-05-23 14:50:30 UTC
(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.
Comment 11 Brion Vibber 2005-05-23 20:38:24 UTC
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.
Comment 12 River Tarnell 2005-05-23 21:06:32 UTC
(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? 
Comment 13 Brion Vibber 2005-05-23 22:08:56 UTC
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.
Comment 14 Ævar Arnfjörð Bjarmason 2005-05-24 17:19:29 UTC
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 **.
Comment 15 Anders Wegge Jakobsen 2005-05-24 17:25:47 UTC
Removing keywords as the enhancement is undergoing re-enginmeering
Comment 16 Ævar Arnfjörð Bjarmason 2005-05-24 20:07:32 UTC
Commited the changes to CVS, since it now supports multiple sidebars this also
solves bug 1764.

Marking this as FIXED.
Comment 17 Dashiva 2005-06-16 18:45:19 UTC
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.
Comment 18 Ævar Arnfjörð Bjarmason 2005-06-16 19:02:36 UTC
(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.
Comment 19 Dashiva 2005-06-16 20:23:46 UTC
(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.
Comment 20 Ævar Arnfjörð Bjarmason 2005-06-24 05:29:13 UTC
(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 &lt;Category:Games&gt;, 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.

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


Navigation
Links