MediaWikiDoc:Code
In SkinTemplate.php, function outputPage seems to be building a massive hierarchical array ($tpl) of all the various components needed to display a wiki page, which is then converted to HTML (etc.) by the code in the applicable (skin name).php file.
Significant lines for generating the navigation links would appear to be these:
$tpl->set( 'navigation_urls', $this->buildNavigationUrls() ); $tpl->set( 'nav_urls', $this->buildNavUrls() );
Both of these return arrays which are added to the $tpl array. Function buildNavigationUrls() uses $wgNavigationLinks as a source for its list of links. Function buildNavUrls(), however, has a hard-coded list; it's not clear what the relationship is between those two.
$wgNavigationLinks is defined in DefaultSettings.php, and presumably can be redefined in LocalSettings.php:
$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' ), );
Each of the strings (except "text" and "href") refers to a value which is settable via the wiki, e.g. the value of "mainpage" can be set by editing the contents of MediaWiki:mainpage.
Unfortunately, it looks like this has to be done separately for each skin (I guess the thinking is that a given skin might want to give each box special treatment, though it would be nice if there were a way to set up default handling for all boxes). Looking just at MonoBook.php, this code produces the box normally labeled "navigation":
<h5><?php $this->msg('navigation') ?></h5> <div class="pBody"> <ul> <?php foreach($this->data['navigation_urls'] as $navlink) { ?> <li id="<?php echo htmlspecialchars($navlink['id']) ?>"><a href="<?php echo htmlspecialchars($navlink['href']) ?>"><?php echo htmlspecialchars($navlink['text']) ?></a></li><?php } ?> </ul> </div>
Immediately after that, I added the following:
<!-- 2005-06-16 Woozle customizations --> <h5><?php $this->msg('backlinks') ?></h5> <div class="pBody"> <ul> <?php foreach($this->data['backlink_urls'] as $navlink) { ?> <li id="<?php echo htmlspecialchars($navlink['id']) ?>"><a href="<?php echo htmlspecialchars($navlink['href']) ?>"><?php echo htmlspecialchars($navlink['text']) ?></a></li><?php } ?> </ul> </div> <!-- end custom code -->
Reloading the page after this change produced no immediate results, but some time later a cache must have expired and some error messages appeared under the "navigation" box. After that, I defined MediaWiki:backlinks to contain "vbz links", and a box labeled "vbz links" faithfully appeared (with an error message in it).
Currently working on adding the links to be displayed in that box. Basically, I need to define the lists of "backlinks" and "backlink_urls".
How A Page is Built
(From Woozle 21:59, 15 Jun 2005 (EDT).)
- Everything obviously starts with index.php
- For the purpose of displaying a page (not saving changes or doing anything else), this calls $wgArticle->view(), in Article.php (line 699)
- $wgArticle->view() appears to be able to provide a few other formats besides the regular view (including difference engine and displaying redirections as subtitles), but I'm ignoring that for now
- $wgOut seems to be the object which accumulates text to be output. It is created in Setup.php:
- $wgOut = new OutputPage();
- OutputPage() is defined in OutputPage.php
- After being created, $wgOut accumulates output via various class methods:
- $wgOut->addWikiText(...)
- $wgOut->addHTML(...)
- $wgOut->addPrimaryWikiText() # Display content and save to parser cache
- $wgOut->addWikiText() # Display content, don't attempt to save to parser cache
- $wgOut->setPageTitle()
- $wgOut->transformBuffer(); # Put link titles into the link cache
- $wgOut->addMetaTags(); # Add link titles as META keywords
- ...and then it does these two lines:
- $this->viewUpdates(); (found at line 1926 -- doesn't do much)
- wfProfileOut( $fname );
- It's not clear whether the navbar has already been pulled in by the time we hit viewUpdates -- possibly transformBuffer does it? The comment makes it sound like that, but the name "transformBuffer" in that case is not very descriptive. The code in there should probably be examined.