5
Hello all, another days efforts and here's the update:
The statement did have a ; at the end of the line and was on one line, so that wasn't it.
I chatted with my ISP and they haven't resolved it. It seems that if the trust path is defined AT THE SAME LEVEL as the root, then it falls outside the assigned apache area for my files.
I wondered if the 'root' (Sites) should have a sublevel with my XOOPS files (equiv to htdocs and the trust path both are.
Indeed in what seems to be a documentation error this is what the Protector V 3.02 module documentation
at
http://library.fishbreeder.net/xoopsdocs/protector-3-02.pdf saysQuote:
6. Edit mainfile.php, which is in your website root folder. You need to define
XOOPS_TRUST_PATH as a new constant here by adding a new line. The value should be
the physical path to the trust path folder, eg:
define('XOOPS_TRUST_PATH', '/home/my_user_account/public_html/my_trust_path');
when jus before it had said to make that same my_trust_path AT THE SAME LEVEL as public_html (see below - the actual documentation is indented)
Quote:
3. Create a new folder outside of your website root to serve as your 'trust path'. You can call
the folder anything you like, but I'll use 'my_trust_path' in this example. If your website root
is called public_html, the directory structure would probably look something like this:
/home
/my_account
/public_html [this is the website root, your site is in here somewhere]
/my_trust_path [lies outside the website root]
These statements are contradictory are they not?
Bottom line is placing a trust path OUTSIDE my root folder gives blank pages on this server Quote:
Software server Apache/1.3.33 (Darwin) PHP/5.0.4 DAV/1.0.3 mod_ssl/2.8.24 OpenSSL/0.9.7l mod_perl/1.29
PHP version 5.0.4
MySql version 4.1.13a
Is this unusual - surely someone should have confronted this and resolved it, or does everyone give up at this point and forget about protector?
