https://bugzilla.wikimedia.org/show_bug.cgi?id=33120
--- Comment #5 from Daniel Friesen <[email protected]> 2011-12-15 02:01:36 UTC --- (In reply to comment #3) > If the goal is to help people get MediaWiki working as easily as possible, as > it should be, we should have as intelligent, auto-detecting defaults as people > are willing to code. Those interested in speed (or what is your goal?) are > free to then hone. (Until there's a wizard to generate hard coded settings for > LocalSettings.php that obviates DefaultSettings.php entirely, a wizard that > MediaWiki offers to run on errors that suggest bad settings, such as occur > after moving a site.) My goal is to ensure that MediaWiki is not fragile enough to break simply because an extension defines a new entry point. As it stands with the pattern you are suggesting if an extension defines an entry point like /extensions/FooBar/baz.php the SCRIPT_NAME will be /extensions/FooBar/baz.php, then $wgScriptPath will become "/extensions/FooBar" and suddenly every link generated from that entrypoint breaks. And to top it off We're also trying to ensure that when someone tries to run a cli script their configuration actually has enough information to function. Trying to auto-detect $wgScriptPath will give cli scripts even 'less' information and some of them won't be able to function (as I said, this is likely why the new installer now sets $wgServer) And you're arguing two different things. We already have a system for getting running quickly, the installer. And it does auto-detect this information and then adds that to the LocalSettings.php that it generates. Wikis that have moved are a different case. In fact if a wiki moves, and it's ScriptPath changes, then it likely has other changes that have to make anyways, ones we can't do for them. Like rewrite rule updates, etc... You should actually compare what it takes to move your wiki in a way that changes the domain/path to other CMS systems at the same level as MW. For MediaWiki you usually just have to modify one or two config variables. WordPress on the other hand will happily save urls hardcoded with a domain and path in them all over the database in ways that complicate the move and force a pile of changes to the db. In fact last time I tried to setup a beta. subdomain copy of WordPress I found that the base url config was stored inside the database instead of a config file and WordPress was coded in such a way that you couldn't even log into the wp-admin area to change that setting and hence had to manually fix it in the database. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
