Last modified: 2010-05-15 15:33:46 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 2260 - SITENAME and wgSitename don't take effect
SITENAME and wgSitename don't take effect
Status: RESOLVED DUPLICATE of bug 296
Product: MediaWiki
Classification: Unclassified
Documentation (Other open bugs)
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-05-28 20:02 UTC by Jay Thorne
Modified: 2010-05-15 15:33 UTC (History)
0 users

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


Description Jay Thorne 2005-05-28 20:02:22 UTC
I installed and stared working with 1.4.4 and though I've set wgSitename in
LocalSettings.php, all of the pages show "WikiDocs" as the site name , ie "Main
Page - WikiDocs" as a page title.

Is there somewhere else this should be changed? The documentation implies that
is all you have to do.
Comment 1 Brion Vibber 2005-05-28 21:44:15 UTC
Did you clear your browser cache? Are you viewing new pages?
Comment 2 Jay Thorne 2005-05-29 04:34:08 UTC
Turns out that there are two parts to setting the name of your site;

Setting wgSitename in LocalSettings.php merely sets the namespace of your local

MediaWiki:Wikititlesuffix is used to make the suffix of the title of each page,
not SITENAME nor wgSitename at all. 

The Special:Allmessages item "pagetitle" implies that the suffix of the page
title is set from the {{SITENAME}} global which is set from wgSitename.  This
contradicts what actually occurs, because also in Allmesages was the only
instance of 'WikiDocs', the name I was trying to change using wgSitename -- in
MediaWiki:Wikititlesuffix as mentioned above. Why does pagetitle exist if it is
ignored? Certainly the code doesn't appear to use it.

I've got the workaround, but the code, Allmessages page, the doc, and the
supplied default db page need to agree clear that Wikititlesuffix changes the
page titles, not 'pagetitle' as a reasonable human might surmise.

Comment 3 Brion Vibber 2005-05-29 04:44:12 UTC
The default contents of the wikititlesuffix message are "{{SITENAME}}", which uses the 
$wgSitename setting.

I don't understand what you're trying to do and what, *exactly*, is not working. Please list 
*exactly* what you've tried to change, *exactly* what doesn't change, *exactly* what your 
language configuration settings are, whether you've imported cur from another wiki or if this 
is a fresh installation, whether you've tried clearing the cache, whether you've tried 
clearing the message cache, etc.
Comment 4 Jay Thorne 2005-05-29 05:41:32 UTC
For some reason or other, in my installation. Mediawiki:wikititlesuffix
contained the literal string "WikiDocs", not {{SITENAME}}. Quite a few other
messages also contained "WikiDocs" where the default was {{SITENAME}} or

Which table are messages kept in?
Comment 5 Jay Thorne 2005-05-29 06:23:00 UTC
After a careful re-read of the mediawiki doc, it appears that the install
generates these messages as literals in object cache or something like it
through the rebuildmessages.php in the maintenance/ directory. If you change
your mind or are told to change your mind about site name (As happened to me),
you must re-run rebuildmessages.

The problem is my expectations; I changed wgSitename in localsettings and
nothing happened: The previous site name was still in the messages. Perhaps some
comments in the sample localsettings.php ie:

"# if you change any of these settings, run rebuildmessages.php in the
maintenance directory."

The install phase does this for you, but its not intuitively obvious that it is
actually copying and rendering html from data in the localsettings.php file.

My previous Wiki experience is with JSPWiki -- everything was text files... This
left me expecting that the page title was either in the php code or template
files, not a generated "cache", made by an external process. 

Comment 6 Brion Vibber 2005-05-29 06:39:00 UTC
Was this wiki upgraded from an older version (1.3 or earlier)?
What language did you select?

Normally, changing $wgSitename *WILL* immediately change the appearance of messages using 
{{SITENAME}}. Normally, that message uses {{SITENAME}}, not a literal.

An older version or an out-of-date localization might have used a literal at install time. 
I'm not asking questions just for fun; I'm trying to get enough information to find the 
problem and you you. Can you confirm if these were the case?
Comment 7 Jay Thorne 2005-05-29 06:48:43 UTC
I'm pretty sure it was a 1.3.x upgraded to 1.4.4, I'm not certain, since I
delegated part of the work. I am certain that the some of the messages contained
literal text, and even some rendered links: a href=/the previous install
location/foo instead of [[Project:foo]]

I've "Fixed" them all, so I can't grab the html of the allmessages page. Sorry,
I wanted to get it running.

Compared to JSPWiki, mediawiki is lightyears ahead in terms of rendering, wiki
language, features. 

The fact that you do partial content caching is laudable; I built's forum system and am very familiar with the speed benefits
from doing that kind of thing. I just bumped up against an old bug, from the
look of things: the dereferencing of sitename literal into the messages is
likely not your current strategy.

Comment 8 Brion Vibber 2005-05-29 09:31:52 UTC
Ok, that sure sounds like the old problem. I'm marking this as a duplicate of bug 296, 
the old (fixed) bug for that issue.

*** This bug has been marked as a duplicate of 296 ***

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