Page MenuHomePhabricator

Make it easier to add links to the sidebar (navbar)
Closed, ResolvedPublic

Description

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".


Version: unspecified
Severity: enhancement

Details

Reference
bz419

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 6:54 PM
bzimport set Reference to bz419.
bzimport added a subscriber: Unknown Object (MLST).

jeluf wrote:

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!

rowan.collins wrote:

*** Bug 690 has been marked as a duplicate of this bug. ***

kissall wrote:

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.

bugzillas+padREMOVETHISdu wrote:

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).

avarab wrote:

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?

bugzillas+padREMOVETHISdu wrote:

(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.

avarab wrote:

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?

river wrote:

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).

avarab wrote:

(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.

river wrote:

(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.

avarab wrote:

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 **.

wegge wrote:

Removing keywords as the enhancement is undergoing re-enginmeering

avarab wrote:

Commited the changes to CVS, since it now supports multiple sidebars this also
solves bug 1764.

Marking this as FIXED.

magnusrk+wiki wrote:

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.

Attached:

avarab wrote:

(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.

magnusrk+wiki wrote:

(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.

avarab wrote:

(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.