Hi all

I have been Xooping for about 3 or 4 months now, and set my team at work up with an Intranet running XOOPS on Windows 2003 Server and IIS6, and also set up my own site hosted by a company. Great. Having great success with both.

However, one major problem that plagues me like a stinking beast is the automatic allocation of 'http://' when adding links in forums, News articles, WF-Section, and for a while, WF-Downloads (till they removed it).

The reason it causes me so much pain is because we (at work) have a huge stash of data on a seperate folder on our network (called the FileStore). It is not in the XOOPS web folder but sits on the main data area of our server on D:\. Because our XOOPS system is not an externally linked InTErnet the only way I can get XOOPS to connect to documents is using direct server paths. For example \\server\FileStore\Folder1\Document1.doc. However, for example, if one of my users wants to link to it from a forum, they cannot use the URL icon because it places http:// before the link. Same goes for a news article, the default Sections module, and WF-Sections, and so on.

I realise there are workarounds for some things (like adding the link as in the forum) but I don't want to have to use workarounds. It takes me time to discover them and makes my system a bit 'messy' for users.

My questions then are these...

1) To other Intranet WebMasters : How do you link to documents? Do you have the same problems. If not, why not? If so, how do you get round them?

2) To Developers : Is it possible to either remove the automatic allocation of http:// in time for the next major release of 2.2? If not, it it possible to give an option to either enable or disable the autmatic allocation of it? If not, is there any way I can do it myself?

thanks for reading and I'll forward to your replies.

Have a good weekend

Ted

Quote:

No problem, I'll check this. But there are a lot of things planned for 2.2, and we may forgot about this one.
So once 2.2 has reached beta stage, you'll be welcome to report this behavior as a bug if it hasn't been corrected.

skalpa.>
PS: Thanks, same to you

You can also map the file respositories into the web space and use traditional http:// calls from the site. This makes it transparent to the web server and you maintain authentication control and hide the location specifics. Don't know about Windoze mappings but surely there is a method that achives the same result as for a *nix server. Once you're mapped to the server then it is the same to xoops.

Talking about virtual mappings under the server.
A couple of symlinks and tricks you might get:
http://yourserver/modules/Data/files1/file.html
which actually ==
\\server2\share\files1\file.html
OR
/home/data/files1/file.html
OR
nfs://server2/share/files1/file.html

etc.

What do you mean by 'map the file respositories into the web space'? Are you referring to Virtual Directories that you set up in IIS (I am currently looking into that on iis-resources.com)? Or are you referring to something even easier?

What surprises me is that with so many Xoopsers around the globe, there must be hundreds, if not thousdans, who run it on an Intranet. I'm so very surprised that others do not have the same problem?

Quote:

I guess he does (and if not, Virtual Dirs should effectively do the trick), but I don't really understand why you're asking about something easier, as those are really easy to configure.

Let's say you have your files in \\server2\share\ and want to get those accessible using the url http://server1/ShareFiles/ ( so \\server2\share\file.ext can be accessed through http://server1/ShareFiles/file.ext, and so on...).
- Ensure the machine running IIS also has access to \\server2\share\
- Open the IIS admin console
- Right-click on the server1 site, and choose New/Virtual directory
- Enter the name you want for the virtual dir (in this example 'ShareFiles' )
- Enter the path to the source dir ( here: \\server2\share\ )
- Customize access permissions (I guess you only want to let 'Read' and maybe 'Browse' )

And that's it. The virtual dir should have appeared in the tree view. It there is a red icon next to it, that's because IIS got problem trying to access it (verify that the IIS user has permissions to access the share path).

skalpa.>

I will try this out next week and see if I can get that working. I'm sure I did do that before (and there was no red icon in the tree) but when I tried to access a document using a hyperlink I got a 'Page Cannot Be Displayed'. I'll try it again though and see what happens. Thanks.