Brion Vibber <brion <at> wikimedia.org> writes:
$wgUploadUrl is set incorrectly on this site to "images" instead of "/ProjectWiki/images".
This reliative URL is resolved by the browser from /ProjectWiki/index.php ok, but not by anything else -- your code snippet simply adds a "/" on the front, making it "/images". (Note this will also fail if $wgUploadUrl is a fully-qualified URL, such as on sites which serve their images from a separate domain.)
I think you mean $wgUploadPath instead of $wgUploadUrl. I found nothing about $wgUploadUrl at http://www.mediawiki.org/wiki/Category:Upload_variables
Adding the starting slash if not existent was only a quick and dirty workaround, because at first the problem seemed to be a missing slash in the middle of the URL. Maybe no good idea.
The Wiki sysop told me he had to set $wgUploadPath="/images" (or "images"?) to get another extension to work. I thought this would cause no problems: Uploads go to the new directory http://robertfant.com/images (or better, one of its subdirectories) and files are retrieved by getURL() from the same place. Seems not to be true. New uploads still go to http://robertfant.com/ProjectWiki/images/<subdir>/subdir>/... Why?
Just for sake of clarity: What is the difference between $wgUploadPath="/images" and $wgUploadPath="images"?
What will the Wiki sysop have to do that uploaded files go to the same place where my extension will retrieve them? Does it help to change both $wgUploadPath and $wgUploadDirectory?
How did you know so quickly about the content of $wgUploadPath without access to LocalSettings.php? Maybe there is a Special:XYZ page showing the content of all $wgXYZ variables.
--Rudi http://www.formelapplet.de
El 4/30/09 9:22 PM, Rudolf Großmann escribió:
I think you mean $wgUploadPath instead of $wgUploadUrl.
Yes, sorry. :) Was from memory.
Just for sake of clarity: What is the difference between $wgUploadPath="/images" and
This is potentially correct, if the path is in fact "/images". (Which it is not in this case, since it's actually "/ProjectWiki/images".)
$wgUploadPath="images"?
This is not correct ever, because $wgUploadPath must be a full path starting from "/".
How did you know so quickly about the content of $wgUploadPath without access to LocalSettings.php?
I looked at the HTML output and saw URLs I know would be formed from $wgUploadPath.
-- brion
On Thu, Apr 30, 2009 at 12:47 PM, Brion Vibber brion@wikimedia.org wrote:
$wgUploadPath="images"?
This is not correct ever, because $wgUploadPath must be a full path starting from "/".
Maybe we should detect this condition and fix it, or at least raise an error message of some kind?
El 4/30/09 2:09 PM, Aryeh Gregor escribió:
On Thu, Apr 30, 2009 at 12:47 PM, Brion Vibberbrion@wikimedia.org wrote:
$wgUploadPath="images"?
This is not correct ever, because $wgUploadPath must be a full path starting from "/".
Maybe we should detect this condition and fix it, or at least raise an error message of some kind?
We probably could. :)
-- brion
Brion Vibber wrote:
El 4/30/09 2:09 PM, Aryeh Gregor escribió:
On Thu, Apr 30, 2009 at 12:47 PM, Brion Vibberbrion@wikimedia.org wrote:
$wgUploadPath="images"?
This is not correct ever, because $wgUploadPath must be a full path starting from "/".
Maybe we should detect this condition and fix it, or at least raise an error message of some kind?
We probably could. :)
Not sure if it's worth the trouble, at least unless someone can think of a good place to put the check such that we don't have to run it on each and every request. Sure, the cost of such a check is minimal, but so is the frequency with which most people change their $wgUploadPath.
Maybe we could add a Special:CheckConfigSanity page. And a hook for extensions to add their own sanity checks...
On Fri, May 1, 2009 at 4:32 PM, Ilmari Karonen nospam@vyznev.net wrote:
Not sure if it's worth the trouble, at least unless someone can think of a good place to put the check such that we don't have to run it on each and every request. Sure, the cost of such a check is minimal, but so is the frequency with which most people change their $wgUploadPath.
If avoiding a single preg_match() would make a noticeable difference in the speed of our code, I'd be *very* happy. :) We already run plenty of trivial sanity checks on every page view. One more is not going to hurt anything.
Aryeh Gregor wrote:
On Fri, May 1, 2009 at 4:32 PM, Ilmari Karonen nospam@vyznev.net wrote:
Not sure if it's worth the trouble, at least unless someone can think of a good place to put the check such that we don't have to run it on each and every request. Sure, the cost of such a check is minimal, but so is the frequency with which most people change their $wgUploadPath.
If avoiding a single preg_match() would make a noticeable difference in the speed of our code, I'd be *very* happy. :) We already run plenty of trivial sanity checks on every page view. One more is not going to hurt anything.
Yeah, but having sanity checks for each and every config option that someone could possibly screw up in the main code path can't be good for performance. The cost of every single one is vanishing, but we have a lot of config options that could use them as much as $wgUploadPath would. And we serve a lot of requests.
Sure, we probably _could_ do it, for each and every config option if we like, without making the code much more bloated than it is. But it's not really the direction I'd personally prefer to see us go. We already suffer from a serious enough case of the inner-platform effect as it is.
Anyway, what I was really thinking was that $wgUploadPath is one of those variables that people rarely if ever change once they've set up their wiki for the first time, and most will get it right the first time anyway. So even if checking it takes only a fraction of a millisecond, the total CPU time spent on checks *per successful detection of an error* may well be surprisingly high.
Hmm... maybe we could make that setting (and the other upload-related ones) part of the install process, and include the checks there. Or we could go with my earlier idea and just include prominent notices saying "After modifying LocalSettings.php, go to Special:CheckConfig to make sure you've made no mistakes.")
On Mon, May 4, 2009 at 10:36 AM, Ilmari Karonen nospam@vyznev.net wrote:
Hmm... maybe we could make that setting (and the other upload-related ones) part of the install process, and include the checks there. Or we could go with my earlier idea and just include prominent notices saying "After modifying LocalSettings.php, go to Special:CheckConfig to make sure you've made no mistakes.")
Or maybe we could encourage people to use Special:Configure, which can automatically ensure sanity at configuration time. And should be easier to use, anyway.
My inclination is that the current model for Configure extension isn't sustainable (manually tracking addition of configuration variables and trying to present a UI for overriding them).
We should start considering migrating most config settings to a queriable configuration database; this can allow new extensions etc to specify their own admin control panel settings requirements, like what we're seeing with the new user preferences.
Attention needs to be placed on ability to cleanly specify group defaults (eg, all wiktionaries get this bit, all Wikibooks get that one), and have a couple different permission levels so eg local admins might be able to make some config changes while others are reserved to system administrators.
I'll toss up a few spec ideas on the tech blog & wiki...
-- brion vibber (brion @ wikimedia.org)
El May 4, 2009, a las 7:46, Aryeh Gregor <Simetrical +wikilist@gmail.com> escribió:
On Mon, May 4, 2009 at 10:36 AM, Ilmari Karonen nospam@vyznev.net wrote:
Hmm... maybe we could make that setting (and the other upload-related ones) part of the install process, and include the checks there. Or we could go with my earlier idea and just include prominent notices saying "After modifying LocalSettings.php, go to Special:CheckConfig to make sure you've made no mistakes.")
Or maybe we could encourage people to use Special:Configure, which can automatically ensure sanity at configuration time. And should be easier to use, anyway.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, May 4, 2009 at 11:53 AM, Brion Vibber brion@wikimedia.org wrote:
My inclination is that the current model for Configure extension isn't sustainable (manually tracking addition of configuration variables and trying to present a UI for overriding them).
We should start considering migrating most config settings to a queriable configuration database; this can allow new extensions etc to specify their own admin control panel settings requirements, like what we're seeing with the new user preferences.
Attention needs to be placed on ability to cleanly specify group defaults (eg, all wiktionaries get this bit, all Wikibooks get that one), and have a couple different permission levels so eg local admins might be able to make some config changes while others are reserved to system administrators.
I'll toss up a few spec ideas on the tech blog & wiki...
Are you thinking this should completely replace LocalSettings.php? That has serious maintainability advantages (vs. maintaining both separately) and would bring us more in line with other web apps, to be sure. In that case we might want the ability to inject arbitrary PHP code anyway (maybe by file edits, maybe through web interface), in case people want to do more complicated stuff. Also might be good for backward compatibility.
El 5/4/09 9:27 PM, Aryeh Gregor escribió:
On Mon, May 4, 2009 at 11:53 AM, Brion Vibberbrion@wikimedia.org wrote:
My inclination is that the current model for Configure extension isn't sustainable (manually tracking addition of configuration variables and trying to present a UI for overriding them).
We should start considering migrating most config settings to a queriable configuration database; this can allow new extensions etc to specify their own admin control panel settings requirements, like what we're seeing with the new user preferences.
Attention needs to be placed on ability to cleanly specify group defaults (eg, all wiktionaries get this bit, all Wikibooks get that one), and have a couple different permission levels so eg local admins might be able to make some config changes while others are reserved to system administrators.
I'll toss up a few spec ideas on the tech blog& wiki...
Are you thinking this should completely replace LocalSettings.php?
Not completely; at a minimum you need to specify database contact info somehow. :)
In that case we might want the ability to inject arbitrary PHP code anyway (maybe by file edits, maybe through web interface), in case people want to do more complicated stuff.
Eww? Just put your scary code in LocalSettings.php. :)
-- brion
wikitech-l@lists.wikimedia.org