RixStix:
What I did was unexpected or the result was unexpected?
My thinking is that the zencart install should put things together so that they fall into the proper place when using the demo data. Isn't that the purpose of the demo data; to show how things are intended to work?
Putting the download files into the pub folder of the subdirectory where the entire cart was installed is one thing.
Having the download links which are saved into the customer order info/account info direct to a pub folder in the root directory just doesn't seem to be functioning as intended.
IOW, save the file in one location but direct the customer to a similar but completely different location.
So to satisfy my curiosity.... is this functioning as expected or is this a bug?
Well, just ran an install using the "setup" that you provided and without even performing a download operation can tell that I would likely come across the same issue that you have seen and well, even though I wrote that part of the sentence I went ahead and tried to download.
As suspected, the attempt to setup as described in the original post of this thread has caused the issue experienced.
By identifying the domain as domain/sub-directory, that information has populated HTTP_SERVER and left the DIR_WS_CATALOG to be populated with a single slash '/'. The result of this when attempting a download is that the DIR_FS_ related information is used to populate the server's files, but the DIR_WS_ portion is used to tell the customer's browser how to "reach" the file... The result of that though is for the browser to actually just try to reach the path that starts with a slash (the value of DIR_WS_CATALOG) with the remainder of the path to the public folder and the temporary file/folder name as built off of the true domain name (which in the above image is chainweavers.info with the prefix of http:). So the browser is told to go to the root of your store, but the pub folder in the file system for your current store actually is prepared to provide that file.
In this particular store, having performed an install in the same way as described and shown above, the HTTP_SERVER, HTTPS_SERVER, DIR_WS_CATALOG, and DIR_WS_HTTPS_CATALOG variables on the store side are incorrectly populated for the desire/need of this particular store/configuration. With that configuration showing that the HTTP_SERVER contains both the domain name and the sub-folder with an ending that has no slash, and then the DIR_WS_CATALOG variable to be a single slash. In a "normal" install where the site is simply being installed in a sub-folder to be accessed as a sub-folder, I would expect HTTP_SERVER to be just the domain name and DIR_WS_CATALOG to be '/156/'. If this were the case for this store, then the download by redirect would work as expected.
Okay, so that "fixes" this store, but there are occasions and configurations where a site needs to have a "sub-folder" as part of the domain name such as on a shared account where the host offers a SSL, but only through "building" off of the host's account. This also is seen when new domains are setup and perhaps only the ip address and "account name" is available. In those cases, the problem identified by RixStix would occur where the download would be attempted from the "host's" folder rather than the store's folder. To account for this, though I haven't tested all of the other possibilities of the download configurations (e.g. file is remotely retrieved, filename is modified for browser output, etc...) nor download methods (other than redirect), I propose the following change in:
includes/classes/observers/auto.downloads_via_redirect.php
Change from:
/**
* Class constructor
*/
public function __construct()
{
if (DOWNLOAD_BY_REDIRECT != 'true') return false;
$this->pubFolder = DIR_FS_DOWNLOAD_PUBLIC;
$this->wsPubFolder = DIR_WS_DOWNLOAD_PUBLIC;
// attach listener
$this->attach($this, array('NOTIFY_DOWNLOAD_READY_TO_REDIRECT'));
$this->gc_cleanup_time = 0;
if (defined('SYMLINK_GARBAGE_COLLECTION_THRESHOLD') && (int)SYMLINK_GARBAGE_COLLECTION_THRESHOLD > 300) {
$this->gc_cleanup_time = (int)SYMLINK_GARBAGE_COLLECTION_THRESHOLD;
}
}
to:
/**
* Class constructor
*/
public function __construct()
{
if (DOWNLOAD_BY_REDIRECT != 'true') return false;
$this->pubFolder = DIR_FS_DOWNLOAD_PUBLIC;
$server_path = HTTP_SERVER;
if (strpos($server_path, '//') !== false) {
$server_path = substr($server_path, strpos($server_path, '//') + 2);
}
if (strpos($server_path, '/') !== false) {
$server_path = substr($server_path, strpos($server_path, '/') + 1);
}
if (substr($server_path, 0, 1) !== '/') {
$server_path = '/' . $server_path;
}
$this->wsPubFolder = $server_path . DIR_WS_DOWNLOAD_PUBLIC;
// attach listener
$this->attach($this, array('NOTIFY_DOWNLOAD_READY_TO_REDIRECT'));
$this->gc_cleanup_time = 0;
if (defined('SYMLINK_GARBAGE_COLLECTION_THRESHOLD') && (int)SYMLINK_GARBAGE_COLLECTION_THRESHOLD > 300) {
$this->gc_cleanup_time = (int)SYMLINK_GARBAGE_COLLECTION_THRESHOLD;
}
}
For the issue related to the current site, I recommend that unless there is a known reason to change the sub-folder information or the domain name to accept the default values as they are for the current installation when installing to a sub-folder and move on. Ie. in this case, the information presented on the left side of the image in this post was perfectly fine for the configuration described as needed. To correct the current installation (not requiring a full reinstall unless want to just to see that it works as expected) in HTTP_SERVER type entries, remove '/156' and in DIR_WS_CATALOG type entries add '/156' as a prefix to the existing '/' so that it reads '/156/'.
changing from:
define('HTTP_SERVER', 'http://domain.com/156');
define('HTTPS_SERVER', 'https://domain.com/156');
define('DIR_WS_CATALOG', '/');
define('DIR_WS_HTTPS_CATALOG', '/');
to:
define('HTTP_SERVER', 'http://domain.com');
define('HTTPS_SERVER', 'https://domain.com');
define('DIR_WS_CATALOG', '/156/');
define('DIR_WS_HTTPS_CATALOG', '/156/');
