Here is a small MediaWiki hack I did for use in our
company intranet. This is useful for intranets
where:
* Perforce is used for revision control.
* You want to directly reference Perforce files
from the Wiki without having to point to a
specific client.
It allows you to directly reference files (via
P4web) using Wiki syntax like this:
P4://depot/the/file
[[P4://depot/the/file some_name]]
I've attached a diff of Parser.php (1.3.8).
JA
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
I hacked Parser.php to support standard unix
dotdot syntax to reference pages up the subpage
hierarchy. This is probably most useful for
intranet usage (I'm assuming subpages are used
more heavily in intranets).
With this hack, you can create links like this:
[[../../somePage]]
And MediaWiki will do the right thing.
My implementation is not good. This was my first
foray into PHP and I found debugging to be a
nightmare so I quit as soon as I got a working
solution. :-(
Anyway, there are a few limitations on the syntax
this implementation accepts, as noted in the code.
It might be useful for this feature to be added to
the standard MediaWiki distribution (with an
improved implementation).
I've attached a diff from Parser.php (1.3.8).
Thanks,
JA
__________________________________
Do you Yahoo!?
All your favorites on one personal page � Try My Yahoo!
http://my.yahoo.com
> On Nov 29, 2004, at 10:53 AM, John Andrews wrote:
> > The help for search says this regarding secondary
> search:
> >
> > Oddly, sometimes no context is shown.
>
> What is "secondary search"?
>From the MediaWiki handbook:
http://meta.wikimedia.org/wiki/Help%3ASearching
Secondary search
After finding the pages, these pages are searched
again to have the results show in red in the context
lines; this search uses a more relaxed criterion:
search terms occurring in the wikitext, even as part
of a word, are shown in red.
Oddly, sometimes no context is shown.
>
> > We (Christian Zankel) seem to have fixed this by
> applying the
> > following diff to
> mediawiki-1.3.8/includes/SearchEngine.php:
>
> Looks like this change recently done in 1.4:
>
http://cvs.sourceforge.net/viewcvs.py/wikipedia/phase3/includes/
>
> SpecialSearch.php?r1=1.6&r2=1.7
Great, so the fix has already been applied.
> This changes the meaning of the contextlines setting
> from the number of
> lines at the beginning of the page to check, to the
> total number of
> matching lines to show. Is this correct?
Correct.
Thanks,
JA
>
> -- brion vibber (brion @ pobox.com)
>
He,
the file languages/LanguageDe.php is ok.
I just changed the following:
$wgLocalInterwiki = $wgSitename;
$wgLanguageCode = "de";
$wgUseLatin1 = false;
$wgProxyKey =
"862891371be901f74c33f4738ee96fa1db5b1555e58c54b1868a4d531adb87";
Here there are the details of my PHP config:
PHP 4 http://server9.hostpoint.ch/~testhost/phpinfo.php
PHP 5 http://server9.hostpoint.ch/~testhost/php5/phpinfo.php
As further information, I can confirm you, taht when i run the same
Mediawiki on my local System on Mac 10.3.6, the problem doesen't
exists. As soon as I move Mediawiki to my Hostprovider, the problems
comes up. Even with the original downloaded MediaWiki folder.
I suppose that the problem is caused by my provider. Could it be?
Andrea
Howdy,
I've been experimenting with RewriteRules and LocalSettings.php
to get rid of the "index.php" in the URL, but I'm running into
unexpected problems.
The setup now seems to work using:
---- LocalSettings.php ----------------------------------
$wgScriptPath = "";
$wgScript = $wgScriptPath . "/index.php";
---------------------------------------------------------
"Seems", because there is a strange balance between Apache and
PHP keeping the "index.php" most of the time out of the URL. The
correct setup would be:
---- LocalSettings.php ----------------------------------
$wgScriptPath = "";
$wgScript = "";
---------------------------------------------------------
but this causes an infinite "Error 302 Moved Temporarily" loop
(Using Firefox, Apache 2.0.52, Squid 2.5 and Mediawiki 1.3.8) for
the URL in the script tag on each page:
<script src="?title=-&action=raw&gen=js&smaxage=0"
type="text/javascript"></script>
It looks like the empty $wgScript causes the mayhem in the
function getLocalURL() in Title.php (via Skin.php and SkinPHPTal.php).
The code looks sensible, though.
My RewriteRules look like this:
---- httpd.conf -----------------------------------------
RewriteEngine On
# Redirect old /wiki/ urls
RewriteRule ^/wiki/(.*)$ http://www.rapdict.org/$1 [R,L]
RewriteRule ^/index.php/(.*)$ http://www.rapdict.org/$1 [R,L]
# Don't rewrite requests for files in MediaWiki subdirectories,
# MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt
RewriteCond %{REQUEST_URI} !^/(stylesheets|images|skins)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt
# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*)$ /index.php/$1 [L,QSA]
---------------------------------------------------------
Does anyone know how to counter the infinite 302 loop for that script
URL?
Greetings,
Patrick
--
_______________________________________________________________
Patrick Atoon ___________________ mailto:patricka@rapdict.org
_____________________________________ http://www.rapdict.org/