[Mediawiki-l] Multiple wikis sharing single database and same database prefix

[JJArmistead at comcast.net]

Platonides wrote:

>Jim Hu wrote:
>> We discovered this when we had a split wiki with private and public  
>> parts.  And then we ran a Nutch search engine against our own wiki  
>> and saw all these hits that weren't supposed to be there.
>> 
>> The watermark idea sounds like it might be interesting.  You wouldn't  
>> have to map the IPs...so what if the public users see the fact that  
>> it's a public wiki?
>> Or, maybe you could just set up your private users to use a different  
>> skin that displays the warning.

>No need to use a different skin (though doable), simply use an external 
>item, like an image. E.g if you display '/image/editNS0.png', 
>private.domain.com/image/editNS0.png will be a horrible warning, while
>public.domain.com/image/editNS0.png a smily face saying, "you're welcome 
>to edit".

OK, so here's what I eventually did (based on MediaWiki 1.8.2):

In Monobook's main.css under

span.subpages {
 display: block;
}

I added the following:

#bodyContent textarea {
        background-image: url(secure.png);
}

That way, the watermark only appears in TEXTAREA elements.  For MediaWiki, this is the article editing box.  Normal viewing of the articles does not give any watermark.  Editing / creating a new article does - perfect !! In fact, I couldn't find the right CSS element to try and get it appearing for the regular article pages.  The TEXTAREA only solution is actually much nicer.

Next, the priority of Interwiki links versus Namespace links in articles.  The Namespace wins out, which makes sense.  Thus even though my two wikis share a common interwiki MySQL table, if the namespace exists (which is the case on the "Private" wiki) then it correctly looks at that.  For the Public wiki, the interwiki link points the user to the Private wiki (which they can only access if Apache thinks their IP address is OK via access/deny rules).  Another win !

So, what about Special:RecentChanges and RSS/Atom feeds ?

A small hack to includes/SpecialRecentChanges.php, function  function wfSpecialRecentchanges( $par, $specialPage ) on the Public wiki fixed that, as follows:

Under the section

 # Namespace filtering
 $hidem .= is_null( $namespace ) ?  '' : ' AND rc_namespace' . ($invert ? '!=' : '=') . $namespace;

I added

        $hidem .= ' AND rc_namespace < 100';

A crude but effective way to block my Private custom namespaces from appearing.

And also for Image: pages where the Links section of the page reveals what other pages refer to the image.

In includes/ImagePage.php, function imageLinks(), I did the following:

Under 

  $sql = "SELECT page_namespace,page_title FROM $imagelinks,$page WHERE il_to=" .
    $dbr->addQuotes( $this->mTitle->getDBkey() ) . " AND il_from=page_id";

I added

                $sql.= ' AND page_namespace < 100';

Again, crude but effective.

Perhaps a $wgMaxDisplayedNamespace variable in LocalSettings.php would be cleaner than hard-coding the value 100

I checked the Search box functionality, and of course on the Public wiki, the namespaces do not go up to 100 and 101 which are my Private: and Private_Talk: namespace, so a user has no way of finding them or selecting to search those namespaces.

Perhaps someone wants to comment on this hack so far.  I know I have still got to attack includes/SpecialWhatlinkshere.php.

Maybe I overlooked some other Special: pages ?

It basically looks good so far.

The only "gotcha" I found was that if I create a Private: link using my Public wiki (e.g. as a "crossover" page), then it doesn't appear in Special:Whatlinkshere for that page.  Rebuilding all the links periodically via the maintenance/rebuildall.php script would fix that problem, but for the most part there would be very few that we need to create.

Likewise, any administrative operations need to be performed on the Private: wiki which can see the total set of all namespaces.  I'm prepared to make that sacrifice since there are probablty very few such pages that would need to be created.

Cheers

Jason