avarab wrote:

There doesn't need to be some special interface to it, it just needs to use
Wiki.png if it exists or allow some way of specifying the url to the logi via a
interface message.

robchur wrote:

...while still allowing a directive in LocalSettings.php to override the image
in the uploads repository.

rowan.collins wrote:

Essentially, all this means is to set $wgLogo, by default, to an uploaded image.
However, as I just pointed out in bug 4261 comment 6, uploads themselves aren't
enabled by default, so this doesn't really make sense. Since anyone who can
enable uploads in LocalSettings.php can also set $wgLogo to whatever URL they
want (including one in their own upload directory), I'm tempted to say this is a
"wontfix". [Desire for an ability to set some of these things through a web
interface is a whole nother issue.]

The only thing I can think might be useful is a comment in
Local/DefaultSettings.php showing what to set $wgLogo to if you *do* want to
allow users to upload a logo.

alexandre.campo wrote:

I see your point. All that I can say is, the request of having an easier
interface to change
the logo is sensible to me. So I have 2 things in mind :

• is it acceptable to allow upload of a new logo _only_ to sysops _only_ ?
• what about providing a full preferences page that would have the same role as

LocalSettings.php, but permit non computer scientists to tune their mediawiki
using a graphical interface ?

robchur wrote:

(In reply to comment #4)

• what about providing a full preferences page that would have the same role as

LocalSettings.php, but permit non computer scientists to tune their mediawiki
using a graphical interface ?

I've heard that one before. As I understand it, that thread was discussed, but
the outcome seemed to be that the LocalSettings.php method was better.

rowan.collins wrote:

(In reply to comment #4)

• is it acceptable to allow upload of a new logo _only_ to sysops _only_ ?

It's perfectly acceptable, and possible without any changes to the software -
just configure your LocalSettings.php to point $wgLogo at a "protected" uploaded
image (I'm pretty sure protection of uploads actually works now).

• what about providing a full preferences page that would have the same role as

LocalSettings.php, but permit non computer scientists to tune their mediawiki
using a graphical interface ?

I mentionned that - "Desire for an ability to set some of these things through a web
interface is a whole nother issue." If you want to discuss that, try bug 3395 [I
should have looked that out earlier]. Since an interface to set $wgLogo would be
meaningless without also having an interface to set $wgEnableUploads, you can't
get away without openning the whole can of worms.

(In reply to comment #3)

Essentially, all this means is to set $wgLogo, by default, to an uploaded image.

1. Enable uploads
2. in /LocalSettings.php permanently change

#$wgLogo = "$wgStylePath/common/images/wiki.png";
to
$wgLogo = "$wgScriptPath/images/b/bc/Wiki.png";

3. Upload a new image Wiki.png whenever you want and
4. protect it, if you need this.

robchur wrote:

Better idea.

$wgLogo = ((file_exists("$wgScriptPath/images/b/bc/Wiki.png")) ?
"$wgScriptPath/images/b/bc/Wiki.png" : "$wgStylePath/common/images/wiki.png");

That way, the image Wiki.png will be used as the logo, if it exists, otherwise
the default will be used.

rowan.collins wrote:

(In reply to comment #8)

$wgLogo = ((file_exists("$wgScriptPath/images/b/bc/Wiki.png")) ?
"$wgScriptPath/images/b/bc/Wiki.png" : "$wgStylePath/common/images/wiki.png");

Wouldn't that mean checking the filesystem for the file *every time a page was
accessed*? And I still don't see how this will be easier than editting
LocalSettings.php when someone's got to do that anyway to enable uploads. Also,
unless the installer creates a dummy, protected, image here, this gives a neat
way of messing up someone else's wiki who *doesn't* want users to override their
logo, and doesn't know how you're doing it.

Unless and until the whole of LocalSettings is dumped into the database, the
best we can do is have something like this:

$wgLogo = "$wgStylePath/common/images/wiki.png"; #location of an image to be
used as the logo
#$wgLogo = "$wgScriptPath/images/b/bc/Wiki.png"; #use uploaded "Image:Wiki.png"
[you may want to protect that image so that only admins can overwrite it]
#$wgLogo = "$wgScriptPath/images/Wiki.png"; #location of uploaded
"Image:Wiki.png" if $wgHashedUploads=false;

Next time I've got access to my CVS client, I'll check that into
DefaultSettings.php or the default LocalSettings.php (unless someone beats me to
it).

robchur wrote:

Still not as performance impacting as checking the database. But of course we've
got to sacrifice functionality for performance when reviewing every single
little thing...

rowan.collins wrote:

Hm, I may have been a bit harsh with that comment. I do agree that
LocalSettings.php is a less than optimal configuration system, but I'm not sure
skirting the issue by inserting hacks so that default values are actually
calculated on-the-fly is the best way to go.

In fact, in order to be truly flexible, the above would need to either check
several other variables (is the upload dir hashed or flat, is there a
commons-style external image store, is *that* hashed or flat, etc), or use the
functions in the Image class for doing so, which would be all a bit circular,
and mean this couldn't really happen during initialisation any more...

Which leads me to an intriguing compromise, which I'll elaborate on at bug 3395:
create an interface for *generating* LocalSettings.php. That way, the
uber-sysop(s) can have a switch saying "Use an uploaded image" (and even provide
their preferred filename) which will look at the settings *as currently
initialised*, and generate the appropriate URL, and LocalSettings.php can remain
a static, lean initialisation file. Like I say, more at bug 3395.

robchur wrote:

http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Logo