P. Kerim friedman | 1 Aug 06:48 2004
Picon

Re: More info

Brion,

Brilliant! But this only does half the job. The links within the wiki 
don't respect the root URL I specified in LocalSettings.php, under 
$wgServer, or the forwarded URL, but all still link to the actual host 
URL. I don't know how to change these?

Also, is there some way to tell MediaWiki to change all links to 
external sites to say target="_top"?

Thanks!

kerim

On Jul 31, 2004, at 6:23 PM, Brion Vibber wrote:

> P. Kerim friedman wrote:
>> I'm a little closer to understanding what is going on with my 
>> absolute failure to get MediaWiki to respect EasyDNS' domain 
>> forwarding. It seems that they use frames. From their website:
> [snip]
>> Now, my problem isn't one of getting the outside links to work, 
>> although that would be nice. (Movable Type seems able to support 
>> this.) But rather, I think the .htaccess file I am using to clean up 
>> the domain names is perhaps breaking the frame?
>
> MediaWiki includes an anti-framejacker defense shield. If you want to 
> take this out, open up stylesheets/wikibits.js and remove this:
>
> // Un-trap us from framesets
(Continue reading)

Brion Vibber | 1 Aug 06:59 2004
Picon

Re: More info

P. Kerim friedman wrote:
> Brilliant! But this only does half the job. The links within the wiki 
> don't respect the root URL I specified in LocalSettings.php, under 
> $wgServer, or the forwarded URL, but all still link to the actual host 
> URL. I don't know how to change these?
 >
> Also, is there some way to tell MediaWiki to change all links to 
> external sites to say target="_top"?

You could try adding something like this to the HTML output:
<base target="_top" href="http://thefakeserver.com/" />

See:
http://www.w3.org/TR/html4/struct/links.html#h-12.4

-- brion vibber (brion  <at>  pobox.com)
_______________________________________________
MediaWiki-l mailing list
@...
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
P. Kerim friedman | 1 Aug 15:24 2004
Picon

Re: More info

Brion,

Excellent! It seems to work. Note for others: I added the line to the 
file "xhtml_slim.pt". I will try to write this all up for the MetaWiki 
documentation sometime this week. But this part, in the end, just two 
these two steps:

(1) Remove the following in stylesheets/wikibits.js

// Un-trap us from framesets
if( window.top != window ) window.top.location = window.location;

(2) Add the following to templates/xhtml_slim.pt (within the 
<head></head> tags):

<base target="_top" href="http://thefakeserver.com/" />

Thanks everyone for your help, especially Alisson and Brion, and thanks 
for putting up with like a 100 e-mails on my problem! Everything seems 
to be working now!

Cheers,

kerim

On Aug 1, 2004, at 12:59 AM, Brion Vibber wrote:

> P. Kerim friedman wrote:
>> Brilliant! But this only does half the job. The links within the wiki 
>> don't respect the root URL I specified in LocalSettings.php, under 
(Continue reading)

P. Kerim friedman | 1 Aug 15:26 2004
Picon

Re: More info

Ooops, I spoke too soon! It seems that, while editing pages work, 
submitting the results does not! After submitting I'm sent back to the 
original edit page. The URL at the top looks like this:

http://wiki.oxus.net/Language_Policy?action=submit

kerim
P. Kerim friedman | 2 Aug 15:03 2004
Picon

Re: More info

Here is more info, with the hopes that someone can help me figure out 
why things still aren't working:

It seems that the normal behavior of MediaWiki when editing a page is 
to, first open this URL:

	http://wiki.oxus.net/Main_Page?action=edit

Then this one:

	http://wiki.oxus.net/Main_Page?action=submit

and then redirect to this one:

	http://wiki.oxus.net/Main_Page

However, with the use of a frameset and URL forwarding, the action to 
take the second URL, store the contents in the database, and redirect 
tot he third URL is not working.

The question is, is this fixable? Or do I have to give up on using URL 
forwarding with my website? It is very frustrating, as everything else 
seems to be working fine with the URL forwarding. If there is some kind 
of redirect, it seems I could perhaps avoid the problem by telling it 
to go to: http://wiki.oxusnet.net/Main_Page?action=submit, or even to 
http://wiki.oxusnet.net/Main_Page?action=edit in the first place, but 
trying to do that manually doesn't help at all.

What kills the ability to save pages is the following alteration to 
templates/xhtml_slim.pt (within the <head></head> tags):
(Continue reading)

Lex Thoonen | 2 Aug 20:36 2004
Picon

pear problem while trying to install

Hi,

Installing mediawiki went fine up to the point where it said:

"then follow this link to your wiki"

clicking on it (after having moved the config file) produces:

[pear_error: message="failed to open stream: Permission denied" code=0 mode=return level=notice
prefix="" info=""]

I've seen it's listed as a bug before and reported on this list, but
not with the way of solving it.

John Ingleby suggested:
***************
The solution is to alter the file PHPTAL-NP-0.7.0/libs/PHPTAL.php
and replace the line:

define('PHPTAL_DEFAULT_CACHE_DIR', '/tmp/'); 

to point to a new /tmp directory I made within the wiki's file
tree.

At  first it didn't work, until I remembered to make my local /tmp
directory writeable...
***************

Well, 'my' line looked different, but I changed it anyway, looks now
like this:
(Continue reading)

Lex Thoonen | 2 Aug 21:18 2004
Picon

Re: pear problem while trying to install - follow up

Monday, August 2, 2004, 7:36:35 PM, you wrote:

LT> What am I to do?

looking further and further on the net I found this:

make the 'images' directory world writable.

That did the trick...

Thanks anyway.

--

-- 
Lex Thoonen
Pêng Smart Web Design - http://www.peng.nl
Gran Canaria Info     - http://www.gran-canaria-info.com
Hollandse Nieuwe      - http://www.hollandsenieuwe.com
tel. +34 928 88.61.77
Oliver Lineham | 3 Aug 03:05 2004
Picon

Image uploads - "Save anyway" button

Hi,

I'm running beta4, and when a user uploads a .gif file, the next page just
has the usual warning message (".gif" is not a recommended image file
format.), but neither of the buttons ("Save file", or "Re-upload").  It's a
dead-end.

Is there a regexp/variable somewhere I can set the list of file formats that
do/don't trigger a warning?

Alternatively, is there a setting I need to use to turn on those buttons?  I
thought it might be in the MediaWiki:badfiletype message, but it's not.

Thanks,

Oliver
Brion Vibber | 3 Aug 04:56 2004
Picon

Re: Image uploads - "Save anyway" button

Oliver Lineham wrote:
> I'm running beta4, and when a user uploads a .gif file, the next page just
> has the usual warning message (".gif" is not a recommended image file
> format.), but neither of the buttons ("Save file", or "Re-upload").  It's a
> dead-end.
> 
> Is there a regexp/variable somewhere I can set the list of file formats that
> do/don't trigger a warning?
> 
> Alternatively, is there a setting I need to use to turn on those buttons?  I
> thought it might be in the MediaWiki:badfiletype message, but it's not.

There are a lot of settings listed in includes/DefaultSettings.php which 
can be tweaked (it's recommended to change the settings always in your 
LocalSettings.php to keep customizations isolated).

Since the Unisys LZW patent has now fully expired, we'll probably go 
ahead and enable GIF by default in the next release, but for now you can 
add it easily enough.

These settings will be relevant to you:

# This is the list of preferred extensions for uploading files. Uploading
# files with extensions not in this list will trigger a warning.
$wgFileExtensions = array( 'png', 'jpg', 'jpeg', 'ogg' );

# Files with these extensions will never be allowed as uploads.
$wgFileBlacklist = array(
	# HTML may contain cookie-stealing JavaScript and web bugs
	'html', 'htm',
(Continue reading)

Oliver Lineham | 3 Aug 05:58 2004
Picon

RE: Image uploads - "Save anyway" button

Brion Vibber wrote:
> These settings will be relevant to you:
> 
> # This is the list of preferred extensions for uploading files. Uploading
> # files with extensions not in this list will trigger a warning.
> $wgFileExtensions = array( 'png', 'jpg', 'jpeg', 'ogg' );

> # If this is turned off, users may override the warning for files not
> # covered by $wgFileExtensions.
> $wgStrictFileExtensions = true;

Thanks Brion, that's what I was after.  Strange that I couldn't find it on
meta.

Regards,

Oliver

Gmane