-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Files nearing the high end of that range might not actually succeed, though, as it'll be hitting post-size limits etc.
As time goes on we'll be improving ways to upload large video files in particular...
- -- brion
On Sat, Nov 22, 2008 at 1:49 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Nice!
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's still uploading and didnt fail"
Marco
^_^ If only PHP didn't suck in that area...
If anyone has looked into that area, they'll understand that PHP cannot do upload progress bars. PHP does the uploading on it's own without giving the script any access to the raw file streams to permit that kind of progress meter. The only way to create an upload progress bar is to use another language to do the actual uploading of the file. Most commonly people end up using a perl upload script to allow the progress meter.
Other than that, there is the option of flash. But you know what everyone things of proprietary software here.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) ~Profile/Portfolio: http://nadir-seen-fire.com -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)
Marco Schuster wrote:
On Sat, Nov 22, 2008 at 1:49 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Nice!
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's still uploading and didnt fail"
Marco
On Sat, Nov 22, 2008 at 10:56 AM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
On Sat, Nov 22, 2008 at 1:49 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Nice!
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's still uploading and didnt fail"
Marco
I don't think you can do that reliably with PHP based uploads (assuming your using them).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I believe php 5.2 with some minor configuration supports upload status:
http://www.haughin.com/2007/10/23/php-upload-progress-with-php-52-apc/
- --michael
K. Peachey wrote:
On Sat, Nov 22, 2008 at 10:56 AM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
On Sat, Nov 22, 2008 at 1:49 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Nice!
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's
still
uploading and didnt fail"
Marco
I don't think you can do that reliably with PHP based uploads (assuming your using them).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It could work. I'm no PHP expert through.
On 21-Nov-08, at 8:10 PM, Michael Dale wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I believe php 5.2 with some minor configuration supports upload status:
http://www.haughin.com/2007/10/23/php-upload-progress-with-php-52-apc/
- --michael
K. Peachey wrote:
On Sat, Nov 22, 2008 at 10:56 AM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
On Sat, Nov 22, 2008 at 1:49 AM, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
Nice!
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's
still
uploading and didnt fail"
Marco
I don't think you can do that reliably with PHP based uploads (assuming your using them).
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJJ2n6PPG4QoAtd8MRAl+SAJ9OEVmpwOoK5cE1ojn5+RHwLgCldQCeMdMg AJydmNjl2rmuDWJvzvROS5o= =ZViB -----END PGP SIGNATURE-----
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Nov 21, 2008 at 9:30 PM, techman224 techman224@yahoo.ca wrote:
It could work. I'm no PHP expert through.
On 21-Nov-08, at 8:10 PM, Michael Dale wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I believe php 5.2 with some minor configuration supports upload status:
http://www.haughin.com/2007/10/23/php-upload-progress-with-php-52-apc/
- --michael
Reading a bit more into that, I'm not convinced it's practical. Almost all of the information I'm reading has been negative, just to quote a few:
[1]http://pecl.php.net/bugs/bug.php?id=13607 [2]http://pecl.php.net/bugs/bug.php?id=9323 [3]http://docs.php.net/manual/en/apc.configuration.php
-Chad
Chad wrote:
Reading a bit more into that, I'm not convinced it's practical. Almost all of the information I'm reading has been negative, just to quote a few:
I'd say it's a feature not easy to get running.
Obviously, it doesn't work on fastCGI.
It reports to be fixed
Tricky to realise, but it's obvious it has to be like that. If you add the hidden field after the file, you won't get it until the file loading is complete.
The problem to use it on WMF server is that each subsequent request for the upload status would need to go to the same server handling the upload.
http://pecl.php.net/package/uploadprogress seems a better option, but should be rewritten to use memcached instead of a nfs folder.
techman224 schrieb:
It could work. I'm no PHP expert through.
On 21-Nov-08, at 8:10 PM, Michael Dale wrote:
I believe php 5.2 with some minor configuration supports upload status:
http://www.haughin.com/2007/10/23/php-upload-progress-with-php-52-apc/
--michael
Uh... that sounds like an elaborate, ugly and unreliable hack. And that is all it really can be. Keep in mind: PHP does not perform uploading at all. It does not run in the browser, so it can't upload anything. It's the browser itself that does this, based on what the HTML tells it to do, and using basic features of HTTP. Browsers *could* easily show a progress indicator for file uploads -- but for some reason, they don't.
Anyway, HTTP doesn't support feedback during upload (or any feedback, really), and HTML does not offer a way for multi-file uploads (which would also be quite handy). Any solutions I have so far seen for that are based either on a Java Applet or on Falsh. Both are rather cluncky and and ugly solutions. HTTP and HTML being what they are, I'm afraid we won't see a decent free, reliably and widely compatible solution for this any time soon.
Or maybe HTML5 has something for this?
-- daniel
On Sat, Nov 22, 2008 at 1:43 PM, Daniel Kinzler daniel@brightbyte.dewrote:
Anyway, HTTP doesn't support feedback during upload (or any feedback, really), and HTML does not offer a way for multi-file uploads (which would also be quite handy). Any solutions I have so far seen for that are based either on a Java Applet or on Falsh.
RS.com's upload indicator apparently works via an iframe:
<form name="ul" method="post" action="http://rs426l3.rapidshare.com/cgi-bin/upload.cgi?rsuploadid=149063132559697458" enctype="multipart/form-data" onsubmit="return zeigeProcess();"> <div id="progbar" style="display:none;">
<iframe src="http://rs426l3.rapidshare.com/progress.html?uploadid=149063132559697458" name="pframe" width="100%" height="120" frameborder=0 marginwidth="0" marginheight="0" scrolling="no"></iframe> </div> <div id="dateiwahl"> <input type="file" size="65" id="dateiname" name="filecontent" onchange="zeigeUploadBtn();" /> <input type=image id="btnupload" name="u" src="/img2/upload_file.jpg" style="visibility:hidden;" /> </div> </form>
The usage of an unique upload ID ensures at their end that the progressbar iframe always gets the right data. It refreshes using AJAX technology: http://pastebin.com/f56b8c8f4 I'll take a look if this might be applicable to put into MW.
Marco
The usage of an unique upload ID ensures at their end that the progressbar iframe always gets the right data. It refreshes using AJAX technology: http://pastebin.com/f56b8c8f4 I'll take a look if this might be applicable to put into MW.
Yes, that seems similar to the original proposal: track the status of the opload on the server side, store the status in some cross-request cache (like APC), and query it using JavaSCript (as an iframe or by injecting html doesn't really matter). That's a *little* lighter on the client, but still quite a fugly hack, ant not very reliable, IMHO.
-- daniel
On Sat, Nov 22, 2008 at 2:22 PM, Daniel Kinzler daniel@brightbyte.dewrote:
The usage of an unique upload ID ensures at their end that the
progressbar
iframe always gets the right data. It refreshes using AJAX technology: http://pastebin.com/f56b8c8f4 I'll take a look if this might be applicable to put into MW.
Yes, that seems similar to the original proposal: track the status of the opload on the server side, store the status in some cross-request cache (like APC), and query it using JavaSCript (as an iframe or by injecting html doesn't really matter). That's a *little* lighter on the client, but still quite a fugly hack, ant not very reliable, IMHO.
Does a PHP script using upload stuff get run if the file upload is complete, or will it start while still uploading? If not, can't you figure out the temporary name of the upload on the server and then run ls -lh on it?
Marco
Does a PHP script using upload stuff get run if the file upload is complete, or will it start while still uploading? If not, can't you figure out the temporary name of the upload on the server and then run ls -lh on it?
It gets run only after the upload is complete. And even if not, and you could get the size of the temporary file, what would you do with it? You can't start sending the response until the request is complete. And even if you could, the browser would probably not start resinging it before it has finished sending the request (i.e. the upload). This is the nature of HTTP...
-- daniel
On Sat, Nov 22, 2008 at 4:19 PM, Daniel Kinzler daniel@brightbyte.de wrote:
Does a PHP script using upload stuff get run if the file upload is complete, or will it start while still uploading? If not, can't you figure out the temporary name of the upload on the server and then run ls -lh on it?
It gets run only after the upload is complete. And even if not, and you could get the size of the temporary file, what would you do with it? You can't start sending the response until the request is complete. And even if you could, the browser would probably not start resinging it before it has finished sending the request (i.e. the upload). This is the nature of HTTP...
You could have the iframe script read its size and let the upload be handled by another frame (evil, evil, I know. But still, we can offer a fallback for people who have them disabled). Can you set PHP to name the temp upload files after an URL parameter? In this case, the Rapidshare approach would work. My approach would be then:
1) User loads [[Special:Upload]], upload id is created (here 31337 for example). Upload has two iframes in it: [[Special:Upload/Form/31337]] containing the <form>, and [[Special:Upload/Progress/31337]] containing the progress bar 2) User starts upload, Progress notices this via AJAX query (of course, this requires that one is able to set the tempfile's name, or at least know it!) and displays the bar 3) Upload finishes.
Marco
Marco Schuster schrieb:
On Sat, Nov 22, 2008 at 4:19 PM, Daniel Kinzler daniel@brightbyte.de wrote:
Does a PHP script using upload stuff get run if the file upload is complete, or will it start while still uploading? If not, can't you figure out the temporary name of the upload on the server and then run ls -lh on it?
It gets run only after the upload is complete. And even if not, and you could get the size of the temporary file, what would you do with it? You can't start sending the response until the request is complete. And even if you could, the browser would probably not start resinging it before it has finished sending the request (i.e. the upload). This is the nature of HTTP...
You could have the iframe script read its size and let the upload be handled by another frame (evil, evil, I know. But still, we can offer a fallback for people who have them disabled). Can you set PHP to name the temp upload files after an URL parameter? In this case, the Rapidshare approach would work. My approach would be then:
- User loads [[Special:Upload]], upload id is created (here 31337 for
example). Upload has two iframes in it: [[Special:Upload/Form/31337]] containing the <form>, and [[Special:Upload/Progress/31337]] containing the progress bar 2) User starts upload, Progress notices this via AJAX query (of course, this requires that one is able to set the tempfile's name, or at least know it!) and displays the bar 3) Upload finishes.
This is close to the original APC based proposal, and I'm sure it's somehow possible, even without using iframes. But it remains an ugly hack, which is tricky to setup and does not work in all environments. For wiki mediasites, the fact that requests are load-balanced between multiple webservers complicates things. The temporary upload file may be on one server while the request for status goes to another.
Again: it's possible in theory, and maybe even in practice, but it remains a fugly unreliable hack.
-- daniel
Daniel Kinzler wrote:
Uh... that sounds like an elaborate, ugly and unreliable hack. And that is all it really can be. Keep in mind: PHP does not perform uploading at all. It does not run in the browser, so it can't upload anything. It's the browser itself that does this, based on what the HTML tells it to do, and using basic features of HTTP. Browsers *could* easily show a progress indicator for file uploads -- but for some reason, they don't.
Agree, it's a pity
Anyway, HTTP doesn't support feedback during upload (or any feedback, really), and HTML does not offer a way for multi-file uploads (which would also be quite handy). Any solutions I have so far seen for that are based either on a Java Applet or on Falsh. Both are rather cluncky and and ugly solutions. HTTP and HTML being what they are, I'm afraid we won't see a decent free, reliably and widely compatible solution for this any time soon.
Sorry? You can upload multiple files in the same HTTP POST. Just add several <input type="file" to the same page (and hope you don't hit max_post_size). That can be done with javascript.
Or do you mean uploading half file now and the other half on a second connection later?
Sorry? You can upload multiple files in the same HTTP POST. Just add several <input type="file" to the same page (and hope you don't hit max_post_size). That can be done with javascript.
Or do you mean uploading half file now and the other half on a second connection later?
I mean uploading an arbitrary number of files, without having to pick each one individually. For example by picking a directory, or multiple files fron the same directory.
Sure, HTML can give you 100 "choos file" fields. but who wants to use that?
-- daniel
Daniel Kinzler wrote:
I mean uploading an arbitrary number of files, without having to pick each one individually. For example by picking a directory, or multiple files fron the same directory.
Sure, HTML can give you 100 "choos file" fields. but who wants to use that?
-- daniel
I see. You're right, we would need a "multifile" input type.
Interestingly, type="file" seems to allow that on HTML5: "File Upload Zero or more files each with a MIME type and optionally a file name" and "The input element represents a list of selected files, " http://www.whatwg.org/specs/web-apps/current-work/#file-upload-state
And HTML4 also allowed it: "file select This control type allows the user to select files " http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#file-sele...
Whereas HTML3 expected just one file. "type=file This provides a means for users to attach a file to the form's contents."
However, I don't think it is supported by browsers and many server scripts (including MediaWiki) would break if they are provided several files for one input element.
Maybe ask about it on the whatwg mailing list?
thinking about it, at the moment the best solution for multi file upload is a dedicated client. There are a couple of scripts that are hard to use, some windows-only stuff, and java-based Commonist.
To get something that is easy to install and works cross-platform, how about a firefox plugin? Has anyone here any experience with writing one?
-- daniel
On Fri, Nov 21, 2008 at 7:56 PM, Marco Schuster marco@harddisk.is-a-geek.org wrote:
An improvement suggestion to the UI when uploading large files: display a progress bar like rapidshare.com does, so that user can see "ah, it's still uploading and didnt fail"
This is really something browsers should handle. I have no idea why they don't. The Mozilla bug is this:
https://bugzilla.mozilla.org/show_bug.cgi?id=243468
So everyone go vote for that. I've flagged it as blocking1.9.2? and wanted1.9.2?, which if we're lucky enough might not be rejected straight off. :) Maybe people could look for/file bugs on WebKit and/or Chrome (or Konqueror, or other open-source browsers too? I don't use either of those, so for all I know they already implement this, although I don't think so.
None of this is to say that it wouldn't be worth it to implement one of the hacky workarounds that some other sites have done. I suspect that there are better investments of time that could be made right now in streamlining the upload process, though, since it's such a mess in so many ways and this feature might be relatively hard to code well.
On Sat, Nov 22, 2008 at 7:43 AM, Daniel Kinzler daniel@brightbyte.de wrote:
Anyway, HTTP doesn't support feedback during upload (or any feedback, really)
Yes, this would have to be done using extra asynchronous requests of some kind if we have to do it on our end, like an iframe with Ajax, or a little Java applet.
and HTML does not offer a way for multi-file uploads (which would also be quite handy).
HTML5 doesn't seem to allow these either, for some reason . . .
"There must be no more than one file in the list of selected files." http://www.w3.org/html/wg/html5/#file-upload-state
(So why don't they just say it represents a single file to begin with?)
On Sat, Nov 22, 2008 at 5:51 PM, Daniel Kinzler daniel@brightbyte.de wrote:
To get something that is easy to install and works cross-platform, how about a firefox plugin? Has anyone here any experience with writing one?
Forcing users to use an extension isn't great as a workaround for this, if we plan to work around it at all, since it will only affect the tiny minority of users who a) use Firefox and b) install the extension. If a Firefox extension is written, it would be most sensible to have it just generically provide an upload progress indicator for all uploads.
Forcing users to use an extension isn't great as a workaround for this, if we plan to work around it at all, since it will only affect the tiny minority of users who a) use Firefox and b) install the extension. If a Firefox extension is written, it would be most sensible to have it just generically provide an upload progress indicator for all uploads.
Well, I mixed two things here: the general progress indicator thing, and the specific need for a good upload client for mediawiki. Both could be addressed by firefox ad-ons, btu you are right: for the progress indication, it should be generic, for any file upload. A mediawiki upload should be specific and provide more functionality besides picking multiple files and uploading them. Most importantly, it has to provide a way to provide the basic information about license, source and authorship. Programs for this exist, I was just thinking that a firefox ad-on would be simpler to deploy and maintain that a standalone program, and people would be more likely to iunstall and use it.
-- daniel
On Sun, Nov 23, 2008 at 8:43 AM, Daniel Kinzler daniel@brightbyte.de wrote:
A mediawiki upload should be specific and provide more functionality besides picking multiple files and uploading them. Most importantly, it has to provide a way to provide the basic information about license, source and authorship. Programs for this exist, I was just thinking that a firefox ad-on would be simpler to deploy and maintain that a standalone program, and people would be more likely to iunstall and use it.
If a MediaWiki-specific workaround would exist, it would presumably be a Java applet that wouldn't require separate installation. You're right that such an applet could be written to do way more than just show upload progress. On the other hand, I'm wary about having to maintain multiple sets of functionality for clients with different capabilities. It would be best to keep as many features as possible in universally-accessible HTML-based upload pages, and only use Java or JavaScript where something is not possible in HTML (like selection of multiple files at once for upload, or progress indicators).
On Sun, Nov 23, 2008 at 4:37 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Sun, Nov 23, 2008 at 8:43 AM, Daniel Kinzler daniel@brightbyte.de wrote:
A mediawiki upload should be specific and provide more functionality besides picking multiple files and uploading them. Most importantly, it has to provide a way to provide the basic information about license, source and authorship. Programs for this exist, I was just thinking that a firefox ad-on would be simpler to deploy and maintain that a standalone program, and people would be more likely to iunstall and use it.
If a MediaWiki-specific workaround would exist, it would presumably be a Java applet that wouldn't require separate installation. You're right that such an applet could be written to do way more than just show upload progress. On the other hand, I'm wary about having to maintain multiple sets of functionality for clients with different capabilities. It would be best to keep as many features as possible in universally-accessible HTML-based upload pages, and only use Java or JavaScript where something is not possible in HTML (like selection of multiple files at once for upload, or progress indicators).
For my CommonsHelper [1] and flickr2commons [2] tools I have implemented a universal Commons user verification for the toolserver called TUSC [3] some time ago. All tools can use this to verify that someone using a tool does have a Commons (or any wikipedia) user login, and that account isn't blocked. We could offer mass-uploads via toolserver that way.
Advantages: * Seperate from MediaWiki code * Quickly adaptable * Potentially many ways to upload (Perl, Java, ...)
Drawbacks: * Additional one-time TUSC signup required (quick but potentially annoying) * Files would be uploaded under a bot name
Or, we could enable my option in MediaWiki to "upload" by giving a URL; me could support multiple URLs that way. That would require people to upload their files on some public FTP or HTTP server, and then transfer them to Commons.
My 2 pence, Magnus
[1] http://toolserver.org/~magnus/commonshelper.php [2] http://toolserver.org/~magnus/flickr2commons.php [3] http://toolserver.org/~magnus/tusc.php
Magnus Manske wrote:
Or, we could enable my option in MediaWiki to "upload" by giving a URL; me could support multiple URLs that way. That would require people to upload their files on some public FTP or HTTP server, and then transfer them to Commons.
Or they could directly ftp upload their file. I considered that option some time ago but didn't follow it.
People log into ftpupload.commons.wikimedia.org using their commons (or TUSC) username and password.
They arrive to a personal FTP space, where they can upload and delete any files they want.
It's not per connection, so if their 100MB video stops at 80MB they can resume the upload. FTP clients are also better at showing a progress bar.
They 'approve' the upload using a MediaWiki interface, where they choose which pending files to approve, license and comments.
Files not approved on a couple of hours are automatically deleted. You cannot hold more than 150MB pending approval on your personal area. (We may want to increase these limits for bots, so complete books can be uploaded on a single ftp session)
Downloading the files you uploaded may be blocked, to discourage people from using WMF as storage.
It allows for better (and so slower) file checking.
It also adds the ability for requiring a second approval of the file. Although not much useful on normal wikimedia usage, could be worth considering for upload of potentially dangerous filetypes.
Aryeh Gregor schrieb:
On Sun, Nov 23, 2008 at 8:43 AM, Daniel Kinzler daniel@brightbyte.de wrote:
A mediawiki upload should be specific and provide more functionality besides picking multiple files and uploading them. Most importantly, it has to provide a way to provide the basic information about license, source and authorship. Programs for this exist, I was just thinking that a firefox ad-on would be simpler to deploy and maintain that a standalone program, and people would be more likely to iunstall and use it.
If a MediaWiki-specific workaround would exist, it would presumably be a Java applet that wouldn't require separate installation. You're right that such an applet could be written to do way more than just show upload progress.
That would requrie a signed applet, with users having to click through scary warnings etc. not a good option.
-- daniel
On Sun, Nov 23, 2008 at 3:18 PM, Daniel Kinzler daniel@brightbyte.de wrote:
That would requrie a signed applet, with users having to click through scary warnings etc. not a good option.
Signing and scary warnings are mutually exclusive.
In any case people don't care for the most part, sadly. I accidentally put up a copy of cortado up that gave nasty java security warnings. Many tens of thousands of people used it without any complaints before I noticed and fixed it.
::Shrugs:: I do like the idea of a firefox plugin better. I think 'publish to commons' buttons would be handy in many other applications too (Gimp, Photoshop, Inkscape, etc)
Hoi, When you know what is being indicated by the signing part of a signed message, it may not be scary. However, do you really expect everyone to know and appreciate it as such ? Thanks, GerardM
2008/11/23 Gregory Maxwell gmaxwell@gmail.com
On Sun, Nov 23, 2008 at 3:18 PM, Daniel Kinzler daniel@brightbyte.de wrote:
That would requrie a signed applet, with users having to click through
scary
warnings etc. not a good option.
Signing and scary warnings are mutually exclusive.
In any case people don't care for the most part, sadly. I accidentally put up a copy of cortado up that gave nasty java security warnings. Many tens of thousands of people used it without any complaints before I noticed and fixed it.
::Shrugs:: I do like the idea of a firefox plugin better. I think 'publish to commons' buttons would be handy in many other applications too (Gimp, Photoshop, Inkscape, etc)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Nov 24, 2008 at 10:34 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When you know what is being indicated by the signing part of a signed message, it may not be scary. However, do you really expect everyone to know and appreciate it as such ?
I'm sorry, but I think we've miscommunicated.
The discussion here is related to a uploader functionalty that would make uploading larger numbers (or large sized) files more user friendly and reliable. This could be accomplished with Java, but because the Java would need to access files on your system it would have to do things which are not permitted for "sandboxed" Java applets.
When applets are "signed" they can perform actions outside of the "Java sandbox" without the really nasty security warnings. Signing is otherwise pretty much invisible to the user.
The other point I was making was that in the past I had inadvertently left the media player triggering the nasty warning messages, and no one complained and many (virtually all? as far as I could tell) went ahead and used the player anyways.
Excuse my ignorance here but shouldn't it be possible to write an Apache handler to receive the file uploads (so we get instant notification instead on upload completion) and at the same time use the meta data to write basic progress information to the DB - The page then uses (say) an iframe to post the file(s) to the handler which updates the DB. You may need to do an initial hit to the handler to get the ID to track or similar - Depends on design.
The progress can then be retrieved by the main page using AJAX to populate a progress box - No java so no warnings. If JS is disabled, it should be easy to fall back gracefully as the only real complex JS is for a progress bar - no JS = no progress bar but upload still works.
Admittedly this doesn't solve the multiple file issue or the large file issue but would get you a progress bar.
I don't believe JS will have file access permissions under most circumstances so couldn't do entire thing via AJAX (not to mention possible increase in transfer time based on encoding, etc...).
To add my $0.02 to the previous suggestion of Java - Whilst most tech-savvy people would have no issues with a Javascript box, others might - but there's no reason you couldn't have a page explaining the process. Additionally, I've noticed (certainly in my family/friends) that most of them just click "OK" whatever it says - No matter how many times I drum it into them to read it first. I'd imagine a large portion of the world would assume Wikipedia is OK and just go with it.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Gregory Maxwell Sent: 24 November 2008 15:58 To: Wikimedia developers Subject: Re: [Wikitech-l] Upload filesize limit bumped
On Mon, Nov 24, 2008 at 10:34 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When you know what is being indicated by the signing part of a signed message, it may not be scary. However, do you really expect everyone
to know
and appreciate it as such ?
I'm sorry, but I think we've miscommunicated.
The discussion here is related to a uploader functionalty that would make uploading larger numbers (or large sized) files more user friendly and reliable. This could be accomplished with Java, but because the Java would need to access files on your system it would have to do things which are not permitted for "sandboxed" Java applets.
When applets are "signed" they can perform actions outside of the "Java sandbox" without the really nasty security warnings. Signing is otherwise pretty much invisible to the user.
The other point I was making was that in the past I had inadvertently left the media player triggering the nasty warning messages, and no one complained and many (virtually all? as far as I could tell) went ahead and used the player anyways.
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The information contained in this communication is privileged and confidential. The content is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by telephone or e-mail, and delete this message from your systems. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18. P Please think of the environment before you print this email
On Mon, Nov 24, 2008 at 11:46 AM, Simon Orr Simon.Orr@teleperformance.co.uk wrote:
Excuse my ignorance here but shouldn't it be possible to write an Apache handler to receive the file uploads (so we get instant notification instead on upload completion) and at the same time use the meta data to write basic progress information to the DB - The page then uses (say) an iframe to post the file(s) to the handler which updates the DB. You may need to do an initial hit to the handler to get the ID to track or similar - Depends on design.
This is one way (although we'd likely want to use memcached, not the DB). The other way would be to use Java. Either would work, someone just has to do one or the other. The implementation will be decided by whoever actually does the work.
To add my $0.02 to the previous suggestion of Java - Whilst most tech-savvy people would have no issues with a Javascript box, others might
If the applet were appropriately signed and certified, there would be no popup or warning to worry about.
Aryeh Gregor wrote:
On Mon, Nov 24, 2008 at 11:46 AM, Simon Orr wrote:
Excuse my ignorance here but shouldn't it be possible to write an Apache handler to receive the file uploads (so we get instant notification instead on upload completion) and at the same time use the meta data to write basic progress information to the DB - The page then uses (say) an iframe to post the file(s) to the handler which updates the DB. You may need to do an initial hit to the handler to get the ID to track or similar - Depends on design.
This is one way (although we'd likely want to use memcached, not the DB). The other way would be to use Java. Either would work, someone just has to do one or the other. The implementation will be decided by whoever actually does the work.
Instead of an Apache Handler, I'd do it as a PHP module (PHP is still an Apache module, but i feel PHP is the right place to do it).
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Aryeh Gregor Sent: 24 November 2008 16:59 To: Wikimedia developers Subject: Re: [Wikitech-l] Upload filesize limit bumped
...
If the applet were appropriately signed and certified, there would be no popup or warning to worry about.
FYI Firefox 3.0.4/WinXP SP3 presents a "This applet ahs been digitally signed, do you wish to run it" dialogue to me for signed apps, similar to the "This application's digital signature could not be verified" one for self-signed.
I'd attach a screenshot but can't and can't UL a pic to a pub server as I'm @ work.
This may, of course, be a config setting on my machine but if so, I don't recall setting it...
The information contained in this communication is privileged and confidential. The content is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by telephone or e-mail, and delete this message from your systems. Teleperformance is a trading style of MM Teleperformance Ltd: Reg No. 02060289 England: Registered Office: St James House, Moon Street, Bristol, BS2 8QY. VAT No.763 0980 18. P Please think of the environment before you print this email
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aryeh Gregor wrote:
If the applet were appropriately signed and certified, there would be no popup or warning to worry about.
Loading a signed and certified applet pops up a dialog box that says roughly:
"You are loading a Java applet which is signed by XYZ. The applet will have complete access to your computer. Do you trust the signed applet from XYZ?"
to which the response is either going to be:
"Yes, I want to see the dancing cats!" or "WTF is this? Am I being hacked?!?!"
In the last three times we had this discussion, we already discarded the idea of a Java applet uploader for this reason -- the security warnings for signed applets are disruptive.
(Now, as an opt-in for power users, it might still be neat. But if we can provide the same capability and *no warnings* using a Flash uploader [with no proprietary codecs involved!], there's probably not much need to do it in Java too. Be nice if someone could double-check if Gnash supports file uploading. :)
- -- brion
Dear all,
May i ask a question of importing sub-meta-history into database? for the "content" column, is it possible to know the size of the text object for this "content", which maybe help me to make sense of which data type i can identify. Does "content" enable to show the number of words in this edit?
thanks. zeyi
If the applet were appropriately signed and certified, there would be no popup or warning to worry about.
Er... this has been stated a couple of times now, and it makes me wonder. I haven't tried recently, but my impression was that an applet ALWAYS has to ask before it gets out of the sandbox. The message is just less scary if the applet is signed *properly*, i.e. the signature is certified by a known CA. But you still have to click through.
Otherwise, anyone with a certified key could write an applet and silently gain access to my file system... that would be quite nasty.
-- daniel
On Mon, Nov 24, 2008 at 4:57 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Mon, Nov 24, 2008 at 10:34 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, When you know what is being indicated by the signing part of a signed message, it may not be scary. However, do you really expect everyone to know and appreciate it as such ?
I'm sorry, but I think we've miscommunicated.
The discussion here is related to a uploader functionalty that would make uploading larger numbers (or large sized) files more user friendly and reliable. This could be accomplished with Java, but because the Java would need to access files on your system it would have to do things which are not permitted for "sandboxed" Java applets.
When applets are "signed" they can perform actions outside of the "Java sandbox" without the really nasty security warnings. Signing is otherwise pretty much invisible to the user.
The browser is unreliable as a upload method. Maybe is more reliable if the server is well configured, the php.ini is well configured, the script lifetime is relaxed, etc.. but on the user experience, is already damaged. A signed java optional option is a win-win to me. Users can chose this option as a reliable alternative to the file thingie, and as this nice progress bar, that is like a minimal for usability. Other websites use other methods. I think Berlios and Sourceforge use the "FTP" option because the users already know how to use a FTP program, and is the best method to upload files. More normal user focused sites like Flick use a flash plugin. And theres even people, like the Gallery2 guys, that have special desktop clients (that are a Java app), so the users can upload lots of files happyly... and maybe even tag his binaries.
Wikipedia: - Normal form file=input method: unreliable, standard Berlios, Sourceforge: - FTP "incomming" folder: reliable, ugly, beyond normal users expertise, faster Flick: - Normal form file=input method: unreliable, standard - Flash upload: reliable, no-standard, it haz eyecandy, good usabilty, extra features Gallery2: - Normal form file=input method: unreliable, standard - Java desktop client: reliable, good usabilty, extra features (tagging images)
Proposed solution: - Normal form file=input method: unreliable, standard - (optional) signed aplet uploader: reliable, good usabilty
note: I have not invested time testing that sites, maybe some fact data here is wrong.
On Sun, Nov 23, 2008 at 3:18 PM, Daniel Kinzler daniel@brightbyte.de wrote:
That would requrie a signed applet, with users having to click through scary warnings etc. not a good option.
They wouldn't have to click through if it was signed, would they? They'd certainly have to click through a scary dialog if you gave them a Firefox plugin to install (if they even used Firefox, what percentage is that?).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Aryeh Gregor wrote:
On Sun, Nov 23, 2008 at 3:18 PM, Daniel Kinzler daniel@brightbyte.de wrote:
That would requrie a signed applet, with users having to click through scary warnings etc. not a good option.
They wouldn't have to click through if it was signed, would they?
Yes they would.
If that wasn't the case, then any web site you visited could read all your files without notifying you simply by signing their malware applet.
- -- brion
On Mon, Nov 24, 2008 at 2:31 PM, Brion Vibber brion@wikimedia.org wrote:
Aryeh Gregor wrote:
They wouldn't have to click through if it was signed, would they?
Yes they would.
If that wasn't the case, then any web site you visited could read all your files without notifying you simply by signing their malware applet.
I don't know anything about Java signing; I was relying on (my possibly incorrect reading of) what Greg Maxwell has said in this thread. I was assuming there was some kind of PKI being used here, as with HTTPS, so that "trusted" applets would silently run with more permissions. If not, then never mind what I said above.
On Mon, Nov 24, 2008 at 5:26 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Mon, Nov 24, 2008 at 2:31 PM, Brion Vibber brion@wikimedia.org wrote:
Aryeh Gregor wrote:
They wouldn't have to click through if it was signed, would they?
Yes they would.
If that wasn't the case, then any web site you visited could read all your files without notifying you simply by signing their malware applet.
I don't know anything about Java signing; I was relying on (my possibly incorrect reading of) what Greg Maxwell has said in this thread. I was assuming there was some kind of PKI being used here, as with HTTPS, so that "trusted" applets would silently run with more permissions. If not, then never mind what I said above.
You get no warning *at all* on non-origin network access for applets signed by an approved key. For example: http://www.jcraft.com/jorbis/player/JOrbisPlayer.php?play=http%3A%2F%2Fuploa...
I don't have direct knowledge for file access. I had assumed that it was the same, but I'm guessing there.
For Java Web Start and complete system access I just get a fairly friendly "This was published by Foo Corp. Do you wish to run it. [ ] Always trust content from Foo Corp."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
You get no warning *at all* on non-origin network access for applets signed by an approved key. For example: http://www.jcraft.com/jorbis/player/JOrbisPlayer.php?play=http%3A%2F%2Fuploa...
I don't have direct knowledge for file access. I had assumed that it was the same, but I'm guessing there.
I get a big scary dialog box here:
== This applet was signed by "JCraft,Inc.," but Java cannot verify the authenticity of the signature's certificate. Do you trust this certificate?
Click Trust to run this applet and allow it unrestricted access to your computer. Click Don't Trust to run this applet with standard Java restrictions.
[Show Certificate] [Don't Trust] [Trust] ==
Click "Show Certificate" and it expands to show cert details and adds a little check box:
[ ] Always trust "JCraft,Inc."
This is with Firefox 3.0.4 on Mac OS X 10.5, whatever default Java VM/plugin comes on the system.
- -- brion vibber (brion @ wikimedia.org)
For Java Web Start and complete system access I just get a fairly friendly "This was published by Foo Corp. Do you wish to run it. [ ] Always trust content from Foo Corp."
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Nov 24, 2008 at 6:47 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
You get no warning *at all* on non-origin network access for applets signed by an approved key. For example: http://www.jcraft.com/jorbis/player/JOrbisPlayer.php?play=http%3A%2F%2Fuploa...
When I visit that URL (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111317 Ubuntu/8.04 (hardy) Firefox/3.0.4), I get a pop-up: "The application's digital signature has been verified. Do you want to run the application?"
2008/11/22 Daniel Kinzler daniel@brightbyte.de:
Anyway, HTTP doesn't support feedback during upload (or any feedback, really), and HTML does not offer a way for multi-file uploads (which would also be quite handy). Any solutions I have so far seen for that are based either on a Java Applet or on Falsh. Both are rather cluncky and and ugly solutions. HTTP and HTML being what they are, I'm afraid we won't see a decent free, reliably and widely compatible solution for this any time soon.
Isn't it OK if we have a Java/Flash option for those who can use it, and current Special:Upload for those who can't?
I think it's difficult to say that Java/Flash options are "clunky and ugly", considering all photo and video sharing sites offer this option. As someone on a slo.o.o.o.ow uploading speed feedback is a godsend.
Brianna
On Sat, Nov 22, 2008 at 7:32 PM, Brianna Laugher brianna.laugher@gmail.com wrote:
Isn't it OK if we have a Java/Flash option for those who can use it, and current Special:Upload for those who can't?
Yes, if you remove "/Flash" (we don't use Flash, it has no real open-source implementations). That would be fine, if someone what's to put in the work to do that.
An HTTP-based solution that still uses ordinary POSTing seems like a better idea to me than trying to not use a web form at all for people with Java. That would be forward-compatible with new and useful features that browsers might add for uploads, like progress indicators that are better than ours. :)
Of course, a browser-side solution is more limited than a Java one. The browser can't safely assume that it can resubmit interrupted POSTs, for instance, and there would be no way for it to allow resuming partial uploads. Using Java would allow that kind of thing, perhaps usefully.
I think it's difficult to say that Java/Flash options are "clunky and ugly", considering all photo and video sharing sites offer this option. As someone on a slo.o.o.o.ow uploading speed feedback is a godsend.
It's "clunky and ugly" implementationally -- the browser is what should be providing upload progress info, just like it provides download progress info. Since no browser seems to be in a hurry to improve in this respect, we might want to work around it, but it would still be a workaround, which shouldn't be necessary to begin with.
Brianna Laugher schrieb:
2008/11/22 Daniel Kinzler daniel@brightbyte.de:
Anyway, HTTP doesn't support feedback during upload (or any feedback, really), and HTML does not offer a way for multi-file uploads (which would also be quite handy). Any solutions I have so far seen for that are based either on a Java Applet or on Falsh. Both are rather cluncky and and ugly solutions. HTTP and HTML being what they are, I'm afraid we won't see a decent free, reliably and widely compatible solution for this any time soon.
Isn't it OK if we have a Java/Flash option for those who can use it, and current Special:Upload for those who can't?
I think it's difficult to say that Java/Flash options are "clunky and ugly", considering all photo and video sharing sites offer this option. As someone on a slo.o.o.o.ow uploading speed feedback is a godsend.
And they frequently break. Imageshak's for example kills my firefox every time. I don't know why, but i'm sure i'm not the only one. If we provide something like this, it should be opt-in (a gadget?) unless ist's *very* smooth and reliable. Maybe that is possible, but I have not seen it yet even once.
-- daniel
Brion Vibber wrote:
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
If we've got new beefy servers, another limit to at least consider bumping might be the PNG scaling limit. 12.5 megapixels isn't really all that much.
(On a tangent... there might be some ways to reduce the overall load from scaling large images, at least as long as the servers can handle the full-size images at all without bumping into memory limits. For example, there's no real need to rescale every thumbnail from the full image -- we might as well work from a pregenerated intermediate size image, as long as it's at least some suitable factor (2-4?) times larger than the target size to avoid noticeable aliasing.)
On Sat, Nov 22, 2008 at 7:13 AM, Ilmari Karonen nospam@vyznev.net wrote:
Brion Vibber wrote:
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
If we've got new beefy servers, another limit to at least consider bumping might be the PNG scaling limit. 12.5 megapixels isn't really all that much.
We actually do have code in SVN that can resize large PNGs efficiently. The problem is though that it may or may not work for pallete based images.
This is more of a general setup question than Wikimedia specific, but I'm certain you folks will have an answer.
My domain is 1611kjb.org. I created a sub domain called wiki.1611kjb.org
I want people, when they type in wiki.1611kjb.org to be redirected to
http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
For the moment, I am using an index.html file with a refresh in it, but not all browsers support that method. I have been trying to do it with an .htaccess file, but I can't seem to get it to work. The sight is hosted on an Apache server running Linux with FrontPage Extensions activated.
What is the best way to get the redirect to happen correctly?
---Mike
use index.php
inside that file <?php header("Location:http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page "); ?>
bilal
On Sat, Nov 22, 2008 at 7:00 PM, Praising Jesus 1611kjb@gmail.com wrote:
This is more of a general setup question than Wikimedia specific, but I'm certain you folks will have an answer.
My domain is 1611kjb.org. I created a sub domain called wiki.1611kjb.org
I want people, when they type in wiki.1611kjb.org to be redirected to
http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
For the moment, I am using an index.html file with a refresh in it, but not all browsers support that method. I have been trying to do it with an .htaccess file, but I can't seem to get it to work. The sight is hosted on an Apache server running Linux with FrontPage Extensions activated.
What is the best way to get the redirect to happen correctly?
---Mike
I don't understand.
The file index.php is not visible to the internet (it's in a subdirectory called mediawiki) and certainly won't be seen by anyone typing wiki.1611kjb.org As I understand it, the standard is for a browser to look for index.html and then default.html and those must be in the root directory. I was under the impression that if I put a file called .htaccess in the root directory for the website (i.e., /wiki.1611kjb.org), the browser would follow that file. I found some directions on a website that implied I should create the file with the following inside:
Redirect permanent /wiki.1611kjb.org/ http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
But it doesn't work.
If I remove index.html, default.html and .htaccess from the root, then when someone types in the domain name, they see my directory structure. Consequently, how would I get a browser accessing my site to read a file called index.php buried in a subdirectory (for that matter, if they could see that file, I wouldn't need a redirect, they'd already be accessing the file I'm trying to redirect to.
---Mike
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Bilal Abdul Kader Sent: Saturday, November 22, 2008 7:14 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Redirect
use index.php
inside that file <?php header("Location:http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page "); ?>
bilal
On Sat, Nov 22, 2008 at 7:00 PM, Praising Jesus 1611kjb@gmail.com wrote:
This is more of a general setup question than Wikimedia specific, but I'm certain you folks will have an answer.
My domain is 1611kjb.org. I created a sub domain called wiki.1611kjb.org
I want people, when they type in wiki.1611kjb.org to be redirected to
http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
For the moment, I am using an index.html file with a refresh in it, but
not
all browsers support that method. I have been trying to do it with an .htaccess file, but I can't seem to get it to work. The sight is hosted on an Apache server running Linux with FrontPage Extensions activated.
What is the best way to get the redirect to happen correctly?
---Mike
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This index.php should be at the root where you placed index.html with the redirect. This is different than index.php that is used by Wiki inside your wiki directory.
bilal
On Sat, Nov 22, 2008 at 9:26 PM, Praising Jesus 1611kjb@gmail.com wrote:
I don't understand.
The file index.php is not visible to the internet (it's in a subdirectory called mediawiki) and certainly won't be seen by anyone typing wiki.1611kjb.org As I understand it, the standard is for a browser to look for index.html and then default.html and those must be in the root directory. I was under the impression that if I put a file called .htaccess in the root directory for the website (i.e., /wiki.1611kjb.org), the browser would follow that file. I found some directions on a website that implied I should create the file with the following inside:
Redirect permanent /wiki.1611kjb.org/ http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
But it doesn't work.
If I remove index.html, default.html and .htaccess from the root, then when someone types in the domain name, they see my directory structure. Consequently, how would I get a browser accessing my site to read a file called index.php buried in a subdirectory (for that matter, if they could see that file, I wouldn't need a redirect, they'd already be accessing the file I'm trying to redirect to.
---Mike
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Bilal Abdul Kader Sent: Saturday, November 22, 2008 7:14 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Redirect
use index.php
inside that file
<?php header("Location: http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page "); ?>
bilal
On Sat, Nov 22, 2008 at 7:00 PM, Praising Jesus 1611kjb@gmail.com wrote:
This is more of a general setup question than Wikimedia specific, but I'm certain you folks will have an answer.
My domain is 1611kjb.org. I created a sub domain called wiki.1611kjb.org
I want people, when they type in wiki.1611kjb.org to be redirected to
http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
For the moment, I am using an index.html file with a refresh in it, but
not
all browsers support that method. I have been trying to do it with an .htaccess file, but I can't seem to get it to work. The sight is hosted
on
an Apache server running Linux with FrontPage Extensions activated.
What is the best way to get the redirect to happen correctly?
---Mike
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I see, sorry I didn't understand. It works great. Thank you.
---Mike
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Bilal Abdul Kader Sent: Saturday, November 22, 2008 9:42 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Redirect
This index.php should be at the root where you placed index.html with the redirect. This is different than index.php that is used by Wiki inside your wiki directory.
bilal
On Sat, Nov 22, 2008 at 9:26 PM, Praising Jesus 1611kjb@gmail.com wrote:
I don't understand.
The file index.php is not visible to the internet (it's in a subdirectory called mediawiki) and certainly won't be seen by anyone typing wiki.1611kjb.org As I understand it, the standard is for a browser to look for index.html and then default.html and those must be in the root directory. I was under the impression that if I put a file called
.htaccess
in the root directory for the website (i.e., /wiki.1611kjb.org), the browser would follow that file. I found some directions on a website that implied
I
should create the file with the following inside:
Redirect permanent /wiki.1611kjb.org/ http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
But it doesn't work.
If I remove index.html, default.html and .htaccess from the root, then
when
someone types in the domain name, they see my directory structure. Consequently, how would I get a browser accessing my site to read a file called index.php buried in a subdirectory (for that matter, if they could see that file, I wouldn't need a redirect, they'd already be accessing the file I'm trying to redirect to.
---Mike
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Bilal Abdul Kader Sent: Saturday, November 22, 2008 7:14 PM To: Wikimedia developers Subject: Re: [Wikitech-l] Redirect
use index.php
inside that file
<?php header("Location: http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page "); ?>
bilal
On Sat, Nov 22, 2008 at 7:00 PM, Praising Jesus 1611kjb@gmail.com wrote:
This is more of a general setup question than Wikimedia specific, but
I'm
certain you folks will have an answer.
My domain is 1611kjb.org. I created a sub domain called wiki.1611kjb.org
I want people, when they type in wiki.1611kjb.org to be redirected to
http://wiki.1611kjb.org/mediawiki/index.php?title=Main_Page
For the moment, I am using an index.html file with a refresh in it, but
not
all browsers support that method. I have been trying to do it with an .htaccess file, but I can't seem to get it to work. The sight is hosted
on
an Apache server running Linux with FrontPage Extensions activated.
What is the best way to get the redirect to happen correctly?
---Mike
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ilmari Karonen wrote:
Brion Vibber wrote:
Now that we've got uploads running on our new, beefier file servers, I've experimentally bumped the upload limit from 20 to 100 megabytes.
If we've got new beefy servers, another limit to at least consider bumping might be the PNG scaling limit. 12.5 megapixels isn't really all that much.
Nope, scaling is a totally unrelated issue.
- -- brion
wikitech-l@lists.wikimedia.org