Last modified: 2013-04-21 14:50:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5532 - Customize logo via "MediaWiki:Logo" instead of $wgLogo
Customize logo via "MediaWiki:Logo" instead of $wgLogo
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.6.x
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 26992
  Show dependency treegraph
 
Reported: 2006-04-11 02:46 UTC by Nick Jenkins
Modified: 2013-04-21 14:50 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Nick Jenkins 2006-04-11 02:46:46 UTC
Currently the nav bar, parts of the footer, various system messages, etc, can be
customized by changing "MediaWiki:" pages. Currently however, the site's logo
has to be changed by manually editing LocalSettings.php in a text editor and
changing $wgLogo. I would like to suggest that the site's logo instead be
customizable by using a MediaWiki page, such as "MediaWiki:Logo" or
"MediaWiki:sitelogo".

"MediaWiki:Logo" could for example contain something like this:
"[[Image:old-logo.png]]" (or maybe just "old-logo.png", if that seems
preferable). A wiki admin user could then update the site's logo to
"[[Image:new-logo.png]]", without ever having to involve a system administrator
by getting them to manually edit LocalSettings.php. Result: More empowered
users, and slightly less hassled sysadmins.
Comment 1 Rob Church 2006-04-11 15:11:39 UTC
How would this be different from setting $wgLogo to the hashed path of the logo
image on the wiki once upon setup, and leaving the users to it thereafter?
Comment 2 Nick Jenkins 2006-04-12 05:31:56 UTC
It would be different in the following ways:
1) The old logo image would not have to be over-written with a new logo of the
same name, so users could try something and revert it easily.
2) The logo could be changed on special occasions with a switch statement. E.g.
Halloween, Wikipedia's birthday, Christmas, St Patrick's day. (And before you
say no sane person would want to do this, I have two words for you: Google's
Homepage).
3) The logo could be semi-randomized - for example: "{{if: {{expr:
{{NUMBEROFARTICLES}} % 2}} = 1 | [[Image:Logo-1.png]] | [[Image:Logo-2.png]] }}"
4) It would be consistent with the trend towards editing the "MediaWiki:"
namespace to customize a wiki.
5) It's a fundamentally nicer interface for the user/sysadmin than editing a
text file.
6) You can preview any changes to make sure it's what you want before you commit
your changes, which you can't with $wgLogo in a text file.
7) It would have history, so you could see what changed, by whom, and when.
8) You could watch it, and see who changes it and how.
9) You could discuss it on its talk page.

... basically in every way that a wiki article is superior to editing a text
file on a command line, so "MediaWiki:Logo" would be superior to $wgLogo.
Comment 3 Rob Church 2006-05-26 22:48:35 UTC
Also sounds expensive.
Comment 4 Nick Jenkins 2006-05-27 02:29:45 UTC
Presumably it'd have a quite similar run-time expense to the current
"MediaWiki:Sidebar".
Comment 5 Rob Church 2006-07-04 08:21:04 UTC
(In reply to comment #4)
> Presumably it'd have a quite similar run-time expense to the current
> "MediaWiki:Sidebar".

Which is cached to hell and back. In fact, the sidebar cache is so ingrained, we
had a period of having to actually fight it into submission when we wanted to
edit the damn thing.
Comment 7 Micke Nordin 2009-05-08 12:13:01 UTC
This should be implemented in core rather than as an extension since it is as hard for inexperienced users to add an extension as it is to change the logo. I think it is a needed feature though. I recently saw a competion where high schools competed in building web sites. MediaWiki was one of 3 cms's in use (the others being Joomla and WordPress) and I'm sad to say that not one of the teams using MediaWiki managed to change the logo or change skin. This does not seem to have been an issue for the teams using Joomla or WordPress.
Comment 8 Niklas Laxström 2009-05-08 12:17:23 UTC
I'm not sure whether it is a good idea for adding custom solutions for this. Imho it would be more useful to improve the configure extension, for example.
Comment 9 Micke Nordin 2009-05-08 12:49:44 UTC
This particular feature seems to function properly in the configure extension all ready. 

Maybe the configure extension just needs to be installed by default when installing MediaWiki... Or may be we need an on-wiki extension installer so that extensions like this can be easily installed (it would be nice if such an extension manager could also handle installation of skins).
Comment 10 Dan Jacobson 2009-05-09 04:48:55 UTC
We http://www.mediawiki.org/wiki/Manual:Wiki_family users might have tens of (wikis, each with tens of) logos, all via $wgLogo, so please whatever you do, make sure $wgLogo will still work too if not overridden.
Comment 11 Mark A. Hershberger 2011-01-27 20:26:46 UTC
Adding this (despite WONTFIX) as blocker to Bug#26992 so that we can see solutions that have been discussed.
Comment 12 MZMcBride 2011-01-27 20:37:58 UTC
Changing the resolution of this.

The general request is that it be possible to edit the logo from the wiki, rather than requiring LocalSettings.php to be edited. The opening poster is correct that allowing nearly all customizations through the MediaWiki interface except the logo is odd and inconsistent. This functionality appears to have been implemented in the Configure extension, making this "fixed," not "wontfix."

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links