Problem with cache and files on Plesk host

The security instructions say that the BEST security is to have cache (and some other folders) put above the web root.

However on Plesk, when I try to put the cache folder only above the httpdocs so that the path to cache is /var/www/vhosts/domainname/cache

I constantly get the following error

"The Session/SQL Cache Directory entry does not exist"

I have followed the instructions to the letter. I first installed Zencart as normal then made changes in the admin, includes/configure.php and admin/includes/configure.php to give the correct path below the web root, this did not work, i got teh message that the directory did not exist.

Now i'm trying to do it through the installation process and set the path without having to move the cashe file after install, and the message still appears, saying

"The session/SQL Cache Directory does not exist"

Does someone or the Zencart team know how to solve this problem, especially as it's an emphasized security recommendation from Zencart, and not some kind of security solution being implemented out of the blue.

1. create the folder outside webroot, as you mentioned:
   /var/www/vhosts/domainname/cache

Make sure it's world-writable/world-readable.

2. start zc_install again, after ensuring both /includes/configure.php and /admin/includes/configure.php are world-writable.

3. on the database-setup page, specify the path from #1 for cache

4. complete the setup process

5. access your store

I tried again and again, it does not work. For some reason, it can't read or recognise the the path where cache is set.

Are you able to test it out on plesk and see what you achieve? because i have followed all teh instructions to the letter. The only possibility if that this wasn't tested out well and there is a bug somehwere in the code that prevents it to pick up the url below the web root.

I just did it on a client site. Sorry - not Plesk ... I don't use it and don't like it.

1. Upload fresh v1.3.7 set of files to site.
2. Move cache folder up a level by drag-and-drop with FTP.
3. Mark the folder world-writable (chmod 777)
4. Run zc_install and edit the cache path by removing "public_html/" (equiv to httpdocs).
5. Complete the install.

The installer checks for the existence of the folder using the PHP is_dir() function. If your server doesn't allow the use of that function or sends a response other than "true" during the inquiry, then you'll see the error and will be prevented from continuing installation.

Some hosts may configure things to prevent PHP scripting from accessing files outside the webroot due to security concerns. IMO that would be not the smartest approach, as it would bust more things than it would solve. But it's possible.

As to this being a bug, as you suggested:> The only possibility if that this wasn't tested out well and there is a bug somehwere in the code that prevents it to pick up the url below the web root. ... if you find a bug and can report the solution, we'll be happy to consider including the fix in the next release. That's what community is for.

The security recommendation is just that ... a recommendation. The program is written to work out of the box with minimal setup configuration requirements and minimal knowledge or comprehension of FTP or other hosting issues. Moving folders outside the webroot is a slightly more advanced concept, and not one that newcomers-to-the-web grasp quickly, and as such, other less advanced security measures are implemented by default. Moving the folder outside the webroot is not required, but is certainly a wise choice if you understand the concept ... and your host is friendly to it.

You have a few options, in order of increasing complexity:

a) leave the folder in your webroot

b) get your hosting company to assist you in determining what may be causing the directory-not-found response to PHP for folders outside the webroot
You might work with them to check the webserver errorlog to see if it has any information that may help you.
Also be sure it's been uploaded as a folder and not a file.
Also be sure it's world-writable and even world-executable.

c) find another host or another control-panel interface