We have a *need* to be able to access existing documentation in the wiki. This documentation may be in the form of .doc, .xls, .odt etc.
I would like to be able to external link to these documents but have not found a way to do this. In searching the archives I have found some discussions but nothing definitive. We are still searching and reading but if someone has a link that says 'hey .. stupid .. look here -->' I would be appreciative.
What we have tried.
1 ) We know that we can 'upload' these documents into wiki by extending the allowed 'media' types. My guess is adding all these document types to the wiki might cause some size issues. Though I like that it notes the changes
It is funny on the page for the uploaded document it says IMAGE:document_name. Other than this it appears to work well. The only problem that the users have with this is that if they want to make a change to the document they have to save locally then upload again. Doesn't bother me but .. users
2) We have tried adding file:// to the accepted list, and this almost works. It shows correctly as a link (as long as I %20 all the spaces). But the link doesn't do anything.
If in IE or FF I file:///c:/Read%20Inventory%20and%20Prices.txt in the address bar then it opens right and displays. If it is file://c:\Technical%20Design%20Template.dot then we get the 'open or save' dialog box. Which is fine. If we make a change and then save we have to direct it back to itself (opens a a new document .. not "c:\Technical Design Template.dot".
But these external links will not work if used through a wiki page. You can click and click and click .. but nothing happens.
I am sure that I must be missing a setting and wonder what it could be.
So as I said, if someone knows a good 'Links for dummys' link .. link me to it.
Thanks
DSig David Tod Sigafoos | SANMAR Corporation PICK Guy 206-770-5585 davesigafoos@sanmar.com
Dave Sigafoos:
- We have tried adding file:// to the accepted list, and this almost
works. It shows correctly as a link (as long as I %20 all the
spaces).
But the link doesn't do anything.
This is an FAQ; see:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ
and look for "Is it somehow possible to use a "file" URI-qualifier...".
This is a tricky thing to fix, as many browsers will ignore these links anyway; your best bet is to place the files somewhere the web server (or some web server) can see them, and then use http: links rather than file: links.
Ian
Thanks for that. I didn't mention all the bits I had read and FAQ was one of those items. I believe we tried this but will check with the other leader when they get in. If not we will certainly make sure it is on top of the list.
FAQs is my friend <G>.
You mentioned ..
This is a tricky thing to fix, as many browsers will ignore these links
anyway; your best bet is to place the files somewhere the web server (or some web server) can see them, and then use http: links rather than file: links.
If these files are on the server then http will be able to see them? And launch correctly? Not sure I understand this but will look at it.
Thanks
DSig David Tod Sigafoos | SANMAR Corporation PICK Guy 206-770-5585 davesigafoos@sanmar.com
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Ian Smith Sent: Thursday, April 05, 2007 15:50 To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Storing or Linking Documents
Dave Sigafoos:
- We have tried adding file:// to the accepted list, and this almost
works. It shows correctly as a link (as long as I %20 all the
spaces).
But the link doesn't do anything.
This is an FAQ; see:
http://meta.wikimedia.org/wiki/MediaWiki_FAQ
and look for "Is it somehow possible to use a "file" URI-qualifier...".
This is a tricky thing to fix, as many browsers will ignore these links anyway; your best bet is to place the files somewhere the web server (or some web server) can see them, and then use http: links rather than file: links.
Ian
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Dave Sigafoos:
Thanks for that. I didn't mention all the bits I had read and FAQ
was
one of those items. I believe we tried this but will check with the other leader when they get in.
But as I said, you may find the browser ignores file:///// links anyhow, for security.
You mentioned ..
This is a tricky thing to fix, as many browsers will ignore these
links
anyway; your best bet is to place the files somewhere the web server
(or
some web server) can see them, and then use http: links rather than file: links.
If these files are on the server then http will be able to see them? And launch correctly? Not sure I understand this but will look at it.
If you upload the files into the Wiki then you can link to them with internal links.
If you place them under a different directory under your web server's document root then linking to them with http:// should work, and they should download/launch like any docs off the net. So if your Wiki address is http://myserver/mediawiki/Main_Page, and it lives in c:\Web_Server\mediawiki, then you could place a document in c:\Web_Server\files\Stuff.doc, and link to it as http://myserver/files/Stuff.doc.
Or place them on another web server, same deal.
If your files have to live somewhere else on your system, then you should be able to make your web server include them in its virtual tree. For example, I have files in d:/CodeView that I want to make available via http:// links, and my http.conf contains this:
# CodeView directory. Alias /CodeView D:/CodeView <Directory "D:/CodeView"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory>
and I can access them as http://myserver/CodeView/...
Cheers,
Ian
(Seems like you're treading the same path I did... ;-)
Something to consider: regardless of which (if any) of those options you pick, the contents of the documents will not be findable via the built in mediawiki search feature.
Of course, if you already know that, have a solution, or don't care, please disregard :)
-- Jim
On 4/6/07, Ian Smith ismith@good.com wrote:
Dave Sigafoos:
Thanks for that. I didn't mention all the bits I had read and FAQ
was
one of those items. I believe we tried this but will check with the other leader when they get in.
But as I said, you may find the browser ignores file:///// links anyhow, for security.
You mentioned ..
This is a tricky thing to fix, as many browsers will ignore these
links
anyway; your best bet is to place the files somewhere the web server
(or
some web server) can see them, and then use http: links rather than file: links.
If these files are on the server then http will be able to see them? And launch correctly? Not sure I understand this but will look at it.
If you upload the files into the Wiki then you can link to them with internal links.
If you place them under a different directory under your web server's document root then linking to them with http:// should work, and they should download/launch like any docs off the net. So if your Wiki address is http://myserver/mediawiki/Main_Page, and it lives in c:\Web_Server\mediawiki, then you could place a document in c:\Web_Server\files\Stuff.doc, and link to it as http://myserver/files/Stuff.doc.
Or place them on another web server, same deal.
If your files have to live somewhere else on your system, then you should be able to make your web server include them in its virtual tree. For example, I have files in d:/CodeView that I want to make available via http:// links, and my http.conf contains this:
# CodeView directory. Alias /CodeView D:/CodeView <Directory "D:/CodeView"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all </Directory>and I can access them as http://myserver/CodeView/...
Cheers,
Ian
(Seems like you're treading the same path I did... ;-)
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Not searchable -
I had gathered that images weren't searchable which makes sense to me (except for descriptive information) but I did not realize that a document with 'text' would not be searchable.
I do see now that it seems to put all uploaded 'media' to IMAGE: which I am not sure I understand.
I must have missed it. There must be an uploadable type for DOCUMENT or similar? Yes ? Something that IS searchable. Other than converting to a page, which will be our fall back position, the problem with this is the users resistance to 'editing' in anything other than WORD. Then having to 'convert' copy/paste etc.
Thanks for all the help, input and knowledge
DSig
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jim Wilson Sent: Friday, April 06, 2007 8:08 To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Storing or Linking Documents
Something to consider: regardless of which (if any) of those options you pick, the contents of the documents will not be findable via the built in mediawiki search feature.
Of course, if you already know that, have a solution, or don't care, please disregard :)
Dave Sigafoos:
I had gathered that images weren't searchable which makes sense to me (except for descriptive information) but I did not realize that a document with 'text' would not be searchable.
Documents are simply stored as-is in the filesystem; so, an uploaded Word doc ends up stored in c:\WebServer\mediawiki\images\f\f7\foo.doc. In contrast, Wiki pages are stored as fields in the MySQL database.
Search doesn't work on uploaded documents, because: 1. the search uses the MySQL search facility, and so only works on stuff which is in the DB 2. since an uploaded doc could be in any format, there's no way to search it: eg. if a document compresses its content using some proprietary scheme, there's no general way to look inside it.
Note that the problems go beyond search: features like "What links here" only work for links from Wiki pages, etc.
I do see now that it seems to put all uploaded 'media' to IMAGE: which
I
am not sure I understand.
The Image: namespace stores the meta-data for all uploaded files; I guess the "Image" name is based on history and how it's used in WP. But for those of us using MW for corporate nets, "Image:" means any uploaded file.
Believe me, I feel your pain... if you find a way to stop your users using Word for a single sentence of plain text, let me know. ;-)
Ian
The Image: namespace stores the meta-data for all uploaded files; I guess the "Image" name is based on history and how it's used in WP. But for those of us using MW for corporate nets, "Image:" means any uploaded file.
AFAIK, the namespace is called "Image" because that's what it's meant to store - images. Not video, not Excel spreadsheets, not Word docs.
Using the Image upload facility for something other than pure images represents an intentional circumvention of the spirit of the device (regardless of business needs - which I understand).
For the record, we have a wiki here where I work, and yes, people upload Excel spreadsheets and word docs and PDFs and ZIP files and .... etc.
-- Jim
On 4/6/07, Ian Smith ismith@good.com wrote:
Dave Sigafoos:
I had gathered that images weren't searchable which makes sense to me (except for descriptive information) but I did not realize that a document with 'text' would not be searchable.
Documents are simply stored as-is in the filesystem; so, an uploaded Word doc ends up stored in c:\WebServer\mediawiki\images\f\f7\foo.doc. In contrast, Wiki pages are stored as fields in the MySQL database.
Search doesn't work on uploaded documents, because:
- the search uses the MySQL search facility, and so only works on stuff
which is in the DB 2. since an uploaded doc could be in any format, there's no way to search it: eg. if a document compresses its content using some proprietary scheme, there's no general way to look inside it.
Note that the problems go beyond search: features like "What links here" only work for links from Wiki pages, etc.
I do see now that it seems to put all uploaded 'media' to IMAGE: which
I
am not sure I understand.
The Image: namespace stores the meta-data for all uploaded files; I guess the "Image" name is based on history and how it's used in WP. But for those of us using MW for corporate nets, "Image:" means any uploaded file.
Believe me, I feel your pain... if you find a way to stop your users using Word for a single sentence of plain text, let me know. ;-)
Ian
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 06/04/07, Jim Wilson wilson.jim.r@gmail.com wrote:
AFAIK, the namespace is called "Image" because that's what it's meant to store - images. Not video, not Excel spreadsheets, not Word docs.
No, it's for historical reasons, back when we didn't envision that people would want to upload other kinds of media. Now it's for general purpose file storage, and is supposed to hold images, audio and video files, etc. without problems.
Rob Church
No, it's for historical reasons, back when we didn't envision that people would want to upload other kinds of media. Now it's for general purpose file storage, and is supposed to hold images, audio and video files, etc. without problems.
Thanks for clearing that up - I didn't mean to spread disinformation. :(
According to my 1.9.3 DefaultSettings.php:
$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg' );
Should we add bmp, ogg, mp3, avi, wma, etc to better reflect the newer interpretation? (I haven't checked 1.10 alpha yet, so I apologize in advance if this has already been done).
-- Jim
On 4/6/07, Rob Church robchur@gmail.com wrote:
On 06/04/07, Jim Wilson wilson.jim.r@gmail.com wrote:
AFAIK, the namespace is called "Image" because that's what it's meant to store - images. Not video, not Excel spreadsheets, not Word docs.
No, it's for historical reasons, back when we didn't envision that people would want to upload other kinds of media. Now it's for general purpose file storage, and is supposed to hold images, audio and video files, etc. without problems.
Rob Church
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 06/04/07, Jim Wilson wilson.jim.r@gmail.com wrote:
Should we add bmp, ogg, mp3, avi, wma, etc to better reflect the newer
We don't encourage the spread of patent-encumbered formats. "ogg" might be worth adding to the defaults list, however. Bitmaps tend to be large, as do a lot of AVI files.
Rob Church
So how hard would it be to expand the upload process to allow selecting the 'type' of upload? Then the 'type' would be able to be searched thus adding a good benefit to MW.
Also, wouldn't it make sense, since the upload process has a 'comment' that you can enter, that a search against this comment be allowed. I do understand that searching on binary of an image really makes no sense (unless you are storing hidden text :) but allowing entry / search of keywords might be a good idea
Thanks.
DSig David Tod Sigafoos | SANMAR Corporation PICK Guy 206-770-5585 davesigafoos@sanmar.com
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jim Wilson Sent: Friday, April 06, 2007 11:31 To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Storing or Linking Documents
The Image: namespace stores the meta-data for all uploaded files; I guess the "Image" name is based on history and how it's used in WP.
But
for those of us using MW for corporate nets, "Image:" means any
uploaded
file.
AFAIK, the namespace is called "Image" because that's what it's meant to store - images. Not video, not Excel spreadsheets, not Word docs.
Using the Image upload facility for something other than pure images represents an intentional circumvention of the spirit of the device (regardless of business needs - which I understand).
For the record, we have a wiki here where I work, and yes, people upload Excel spreadsheets and word docs and PDFs and ZIP files and .... etc.
-- Jim
On 4/6/07, Ian Smith ismith@good.com wrote:
Dave Sigafoos:
I had gathered that images weren't searchable which makes sense to
me
(except for descriptive information) but I did not realize that a document with 'text' would not be searchable.
Documents are simply stored as-is in the filesystem; so, an uploaded Word doc ends up stored in c:\WebServer\mediawiki\images\f\f7\foo.doc. In contrast, Wiki pages are stored as fields in the MySQL database.
Search doesn't work on uploaded documents, because:
- the search uses the MySQL search facility, and so only works on
stuff
which is in the DB 2. since an uploaded doc could be in any format, there's no way to search it: eg. if a document compresses its content using some proprietary scheme, there's no general way to look inside it.
Note that the problems go beyond search: features like "What links
here"
only work for links from Wiki pages, etc.
I do see now that it seems to put all uploaded 'media' to IMAGE:
which
I
am not sure I understand.
The Image: namespace stores the meta-data for all uploaded files; I guess the "Image" name is based on history and how it's used in WP.
But
for those of us using MW for corporate nets, "Image:" means any
uploaded
file.
Believe me, I feel your pain... if you find a way to stop your users using Word for a single sentence of plain text, let me know. ;-)
Ian
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On 08/04/07, Dave Sigafoos davesigafoos@sanmar.com wrote:
Also, wouldn't it make sense, since the upload process has a 'comment' that you can enter, that a search against this comment be allowed. I do understand that searching on binary of an image really makes no sense (unless you are storing hidden text :) but allowing entry / search of keywords might be a good idea
Text in the file description page is indexed for the search engine.
Rob Church
Ian ..
Thanks for that. I didn't mention all the bits I had read and FAQ was one of those items. I believe we tried this but will check with the other leader when they get in.
But as I said, you may find the browser ignores file:///// links anyhow, for security.
Yes, this is what we are working on.
You mentioned .. This is a tricky thing to fix, as many browsers will ignore these links anyway; your best bet is to place the files somewhere the web server (or some web server) can see them, and then use http: links rather than file: links.
If these files are on the server then http will be able to see them? And launch correctly? Not sure I understand this but will look at it.
If you upload the files into the Wiki then you can link to them with internal links.
I believe that I mentioned this trial in my original message. The problem with this method is that the user must save off locally then upload again.
If you place them under a different directory under your web server's document root then linking to them with http:// should work, and they should download/launch like any docs off the net. So if your Wiki address is http://myserver/mediawiki/Main_Page, and it lives in c:\Web_Server\mediawiki, then you could place a document in c:\Web_Server\files\Stuff.doc, and link to it as http://myserver/files/Stuff.doc.
Or place them on another web server, same deal.
If your files have to live somewhere else on your system, then you should be able to make your web server include them in its virtual
tree.
For example, I have files in d:/CodeView that I want to make available via http:// links, and my http.conf contains this:
# CodeView directory. Alias /CodeView D:/CodeView <Directory "D:/CodeView"> Options Indexes FollowSymLinks Includes AllowOverride All Order allow,deny Allow from all
</Directory>
I get this. Of course this might be un-doable anyway as the users have defined directories like
"\Spokane\IT PM&A\7- PM&A Deliverable Templates\2 - Initiation & Analysis\Project Request Template - New Brands.dot"
<sigh>
(Seems like you're treading the same path I did... ;-)
Hope your requirements were easier <G>
mediawiki-l@lists.wikimedia.org