Re: Re: How to remove the Search Button from the Re: How to remove the Search Button from the MediaWiki and have just the Go Button.

PHPTAL has been totally eradicated in 1.4. The file you need to modify
is /skins/MonoBook.php.

On Thu, 31 Mar 2005 11:31:48 -0700, Karthik Gopalakrishnan
<mailkars@...> wrote:
> Hi,
> 
> I'm using the Mediawiki 1.4rc1 . I couldn't find the
> templates/xhtml_slim.pt file.
> 
> There is no templates directory..
> 
> !!! Please Help !!!
> Karthik.G
> 
> >The main skeleton of pages is in templates/xhtml_slim.pt
> 
> >Beware when you play with it, it's not simple html. As you can see it is
>  >a little bit written to be interpreted by an engine (called phptal)
> 
> >Fxparlant
> >(François)
> 
> Karthik Gopalakrishnan wrote:
> > Hi,
> >
> > I'm relatively to new to mediawiki. I'm planning to run a wiki in my
> > local intranet using the wikipedia Database Dump. I know that full
> > text search functionalaity is disabled. I want to remove the "Search"
> > Button and just have the "Go" Button to search the articles. Which php

Re: Just the article wanted

You mean JUST the wikitax rendered?

On Thu, 31 Mar 2005 12:40:04 -0800, Jan Steinman <Jan@...> wrote:
> Okay, I've gotten pretty good at hacking away at MediaWiki, and could
> probably find a way to do this, but I'm looking for the BEST way!
> Especially the way that will require the least pain in future releases.
> 
> I want a totally "nude" article page, without discuss/edit/history/move
> and ALL the other links, and no background. This will be dropped into a
> table, which will contain a page header (which sets the background),
> its own links down the side, and a page footer.
> 
> I looked around at the skins, and thought, "I need to start with the
> simplest skin," but MySkin.php is essentially empty. Should I copy
> this, and start overriding methods that provide non-article content
> with NOPs? Or is there a better way to get just the article text?
> 
> Thanks in advance for all the hints and tips that I'm sure are coming!
> 
> 
> :::: I will not be as those who spend the day in complaining of
> headache, and the night in drinking the wine that gives it. -- Göthe
> :::: Jan Steinman <http://www.Bytesmiths.com/Van>
> 
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l@...
> http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
> 

Re: Just the article wanted

On 31 Mar 2005, at 17:40, Jamie Bliss wrote:

> You mean JUST the wikitax rendered?

Well, I have an existing gallery system that is very simple. It sets up 
some state. It includes a header. It outputs some stuff. It includes a 
footer. (Details at the URL at the end of this message.)

I'd like to have just the rendered wikitext come out in between the 
header and footer, with the ability to open the door and have the whole 
wiki working.

A session variable ($session('admin') != '') would then allow full wiki 
access, with WHATEVER look-n-feel. The important part is that the 
non-admin look-n-feel be supplied solely via the header/footer files.

Does that make more sense?

> On Thu, 31 Mar 2005 12:40:04 -0800, Jan Steinman <Jan@...> 
> wrote:
>> Okay, I've gotten pretty good at hacking away at MediaWiki, and could
>> probably find a way to do this, but I'm looking for the BEST way!
>> Especially the way that will require the least pain in future 
>> releases.
>>
>> I want a totally "nude" article page, without 
>> discuss/edit/history/move
>> and ALL the other links, and no background. This will be dropped into 
>> a

Re: How to remove the Search Button from the Re: How to remove the Search Button from the MediaWiki and have just the Go Button.

Hi Jamie,

Thanks for the correction, I'm still worriing about jumping to next 
version... waiting for 1.5 I guess.


François

Jamie Bliss wrote:
> PHPTAL has been totally eradicated in 1.4. The file you need to modify
> is /skins/MonoBook.php.
> 
> On Thu, 31 Mar 2005 11:31:48 -0700, Karthik Gopalakrishnan
> <mailkars@...> wrote:
> 
>>Hi,
>>
>>I'm using the Mediawiki 1.4rc1 . I couldn't find the
>>templates/xhtml_slim.pt file.
>>
>>There is no templates directory..
>>
>>!!! Please Help !!!
>>Karthik.G
>>
>>
>>>The main skeleton of pages is in templates/xhtml_slim.pt
>>
>>>Beware when you play with it, it's not simple html. As you can see it is
>>

RE: Stop new accounts?

Alistair Johnson wrote:
> in localsettings.php
> 
> # Limit creation of new user accounts to staff with admin access
> $wgWhitelistAccount = array ( "sysop" => 1, "developer" => 1);

Note that when you do this (in version 1.3.11 at least), existing users 
who are neither a sysop nor a developer are not permitted to set their 
own password; all they can do is have a new random password mailed to them.

I hacked my MediaWiki installation to distinguish between "anonymous" 
and "user" entries in the $wgWhitelistAccount array, which permits 
existing registered users to create new accounts and also change their 
own passwords.  This isn't ideal, but it was much easier than hacking 
the login page and was good enough for my installation.

I'll be happy to mail the patch to anyone who wants it, but for some 
reason I can't get Thunderbird to include it in this message body 
without line wrapping, and I believe this list will delete it as an 
attachment.

- Andrew
--

-- 
Podiabombastic: The tendency to shoot oneself in the foot.

Problem with rewrites

Greets:

I am trying to install a local copy of MediaWiki with the March 8th
database from the download server and I am having a problem with rewrites.

I'm following the instructions loated here:

http://meta.wikimedia.org/wiki/Rewrite_rules#Using_an_alias_in_httpd.conf

(I have my own server so changing settings is not an issue)

I've gone ahead and installed MediaWiki under a subdomain as suggested
within the rewrite page and made the change within the LocalSettings.php
file.  I have also gone ahead and edited local httpd.conf for the domain
to add the following:
        Alias /wiki
/home/username/domains/fillmewith.info/public_html/w/index.php

and did a restart afterwards.

The strange thing though is that links on the home page such as:

http://www.fillmewith.info/wiki/index.php/Mine

turn into:

http://www.fillmewith.info/wiki/Index.php/Mine

when clicked on. (Notice the capital I in index.php)  I'd imagine that
this is causing the Alias to be thrown off and not work.  I'm assuming

Re: Problem with rewrites

fillmewith@... wrote:
> The strange thing though is that links on the home page such as:
>
> http://www.fillmewith.info/wiki/index.php/Mine

You have $wgArticlePath set incorrectly: it should be "/wiki/$1", not
"/wiki/index.php/$1".

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l@...
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

dump/import data problems

I recently dumped (well, someone else dumped it) the data from a  
MediaWiki database stored in a MySQL v3.23.58 server and imported it  
into a v4.0.21 server.

I noticed on the new instance of the wiki, running on MySQL v4.0.21,  
that there were some pages where the text wasn't displaying properly  
and on Editing the page, the 'bad' data was replaced with a number of  
question marks. Without saving the Edit, I noticed that characters in  
the database were garbled (I temporarily do not have access to the  
original site so I can't verify the exact original data but it was  
served correctly there just before that server was taken off-line and  
the dump produced.) and that the "garbling" originated in the dump file  
(probably created in the dump process).

Is this a known issue and is there a way to prevent/correct it? I know  
that MySQL v4.0.x is recommended for MediaWiki but the reasons given  
seem to be related to performance.

I saw a note in the list archive related to similar issues with MySQL  
v4.1.x,

http://mail.wikipedia.org/pipermail/mediawiki-l/2004-November/ 
002245.html

but I'm not certain this is exactly the same issue since the dump  
didn't actually turn them into question marks and I can't positively  
identify the characters from the original database that were corrupted.  
I think one of them was 0xe8 or 0xe9 (è or é, if those display  
correctly in this email -- è or é in HTML encoding) but,  
being a hopeless English speaking monoglot, I don't know for sure which  

Re: dump/import data problems

John Blumel wrote:
> I recently dumped (well, someone else dumped it) the data from a
> MediaWiki database stored in a MySQL v3.23.58 server and imported it
> into a v4.0.21 server.
>
> I noticed on the new instance of the wiki, running on MySQL v4.0.21,
> that there were some pages where the text wasn't displaying properly
> and on Editing the page, the 'bad' data was replaced with a number of
> question marks. Without saving the Edit, I noticed that characters in
> the database were garbled (I temporarily do not have access to the
> original site so I can't verify the exact original data but it was
> served correctly there just before that server was taken off-line and
> the dump produced.) and that the "garbling" originated in the dump file
> (probably created in the dump process).

Using the same encoding?

Latin-1 or UTF-8 wiki?

-- brion vibber (brion  <at>  pobox.com)

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l@...
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

Re: dump/import data problems

On Apr 1, 2005, at 5:03pm, Brion Vibber wrote:

> Using the same encoding?
>
> Latin-1 or UTF-8 wiki?

Do you mean using the same encoding on the import as the dump? Or, was 
the correct encoding (to match the DB) used on the dump (or import)? Or 
something else?

I'll have to check on exactly how the dump was generated. I've been 
using CocoaMySQL (Mac OS X) to do the imports and have tried both 
encodings, although, perhaps I should try it from the command line to 
make sure CocoaMySQL is doing what I think it is. (The dump was 
generated from a Linux system, although, I wouldn't think that would 
make a difference.)

As to the wikis, the following are set to their DefaultSettings.php 
values:

$wgInputEncoding	= 'ISO-8859-1'; # LanguageUtf8.php normally overrides 
this
$wgOutputEncoding	= 'ISO-8859-1'; # unless you set the next option to 
true:
$wgUseLatin1 		= false; # Enable ISO-8859-1 compatibility mode
$wgEditEncoding		= '';

But it sounds like I need to learn a bit more about this.

Assuming you can give an answer based on the information I've provided,