Doc Product Type Download by redirect redirects to wrong .pub folder

[RixStix]

156B
upload 156b fileset to mydomain.com/156
vanilla install into SUB-directory with demo products
make sure the subdirectory ( /156 in my case ) is appended in every field of the install window.

Change pub folder permissions to 777

Category: mixed product types
Product: sample of document product type $0.93

Add to cart
checkout using check/money order

Admin: change order status to delivered

Go to customer account.
Attempt to download product file

Redirects to ROOT pub folder instead of subdirectory install /156/pub folder
Thus, receive a 404 error because the folder/file does not exist in the Root pub folder

temp product download folder is in the /156/pub folder where expected to be.

[mc12345678]

As this issue appears similar to: https://www.zen-cart.com/showthread....on-Free-orders and also to another thread about filling in the install fields that I can't seem to find at the moment, but recall discussing before.

Want to be sure/understand the statement about verifying that the subdirectory v156 being added to every field.

So the two fields where asked to identify the domain... what was entered was http://DOMAIN/v156 or https://DOMAIN/v156? Where DOMAIN is the domain name for your site and http: or https: was used as applicable, but both fields also included the subdirectory?

[mc12345678]

As this issue appears similar to: https://www.zen-cart.com/showthread....on-Free-orders and also to another thread about filling in the install fields that I can't seem to find at the moment, but recall discussing before.

Want to be sure/understand the statement about verifying that the subdirectory v156 being added to every field.

So the two fields where asked to identify the domain... what was entered was http://DOMAIN/v156 or https://DOMAIN/v156? Where DOMAIN is the domain name for your site and http: or https: was used as applicable, but both fields also included the subdirectory?

I note that the answer to my question will be a no because I incorrectly referenced the sub-directory name that is provided some 4 times in the original post. My example entries should have been: http://DOMAIN/156 or https://DOMAIN/156, though the questions still apply.

[RixStix]

As this issue appears similar to: https://www.zen-cart.com/showthread....on-Free-orders and also to another thread about filling in the install fields that I can't seem to find at the moment, but recall discussing before.

Want to be sure/understand the statement about verifying that the subdirectory v156 being added to every field.

So the two fields where asked to identify the domain... what was entered was http://DOMAIN/v156 or https://DOMAIN/v156? Where DOMAIN is the domain name for your site and http: or https: was used as applicable, but both fields also included the subdirectory?

Surely you know ... about the 2nd or 3rd screen of an install where the there are 6 or 8 "paths". When you install to a subdirectory, some of those fields are prepopulated with the subdirectory appended to the root path and some do not.

I appended the subdirectory to all the ones that were not prepopulated to included the subdirectory. There's really no explanation on that screen of the install.

There are a few other irons in the fire today. I will step through another install into a different server subdirectory and get a screen print of the install screen for you.

Yes, this is nothing new. I had expected it to be corrected in the 156b. That's why I abandoned all work on 156 a couple of months ago.

[RixStix]

Actually, it is the 2nd screen of a default install.
Left side is the default, prepopulated addresses.
Right side has the subdirectory appended.

I hoped/tried to provide enough info in the original post to duplicate the issue, step by step.

[mc12345678]

Well, you did identify what you did, though that was an unexpected action and why I had asked.

The best definition I found in the first page of search for "domain name definition" appeared to be from: https://www.webopedia.com/TERM/D/domain_name.html

Where the example provided in my opinion offering the simplest of explanations is: "For example, in the URL http://www.pcwebopedia.com/index.html, the domain name is pcwebopedia.com."

Another way I have thought about it is, I have an email address associated with my domain. Even if my site is served in a sub-directory, the email address doesn't include the sub-directory in the email address.

It may not play a role in this, but at least in future installations that you may do in a sub-directory shouldn't have to spend that extra time/thought on it. In fact, the only real time I've seen where I've had to really make modifications to these options has been if the server did not have a dedicated SSL for the site, but was instead on a shared server. In those cases, I've had to change the https: domain to that of the host's domain and some variation of the user's account.

But that again is for information/edification.

[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?

[mc12345678]

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/');

[mc12345678]

Oops, minor code adjustment to ensure functionality for sites that *do not* have a sub-directory in their HTTP_SERVER related fields and to add code comments which led to discovering a need for a change:

New code suggestion:

  /**
   * Class constructor
   */
  public function __construct()
  {

    if (DOWNLOAD_BY_REDIRECT != 'true') return false;

    $this->pubFolder = DIR_FS_DOWNLOAD_PUBLIC;

    $server_path = HTTP_SERVER;

    // Remove the protocol from the path if present.
    if (strpos($server_path, '//') !== false) {
      $server_path = substr($server_path, strpos($server_path, '//') + 2);
    }

    // Remove the domain name from the path, if present.
    // if HTTP_SERVER does not contain a sub-directory then no change needed.
    // else remove the domain name and prefix the path to begin at the domain name.
    // Note that there are other potential incorrect configurations that are not tested here, such as 
    //   HTTP_SERVER ending with one or more slashes ('/'), DIR_WS_CATALOG not beginning with a slash, etc...
    if (strpos($server_path, '/') === false) {
      $server_path = '';
    } else {
      // Remove the domain name from the path if present.
      $server_path = substr($server_path, strpos($server_path, '/') + 1);

      // Prefix the path to ensure starting at the base of the domain name.
      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;
    }
  }

[mc12345678]

Or life could be made "easy" by simply changing:

    $this->wsPubFolder = DIR_WS_DOWNLOAD_PUBLIC;

to this:

    $this->wsPubFolder = HTTP_SERVER . DIR_WS_DOWNLOAD_PUBLIC;

Unless there is some known reason that it was designed to not use that initial information in support of the other capabilities incorporated for downloads.