DIR_WS_HTTPS_ADMIN Constant appears to be removed but is still used/referenced

On the admin side, the constant DIR_WS_HTTPS_ADMIN appears to no longer exist; however,
admin/includes/functions/html_output.php still references it in zen_href_link if the connection is 'SSL', and ENABLE_SSL_ADMIN == 'true'

There does not appear to be any define to complete out DIR_WS_HTTPS_ADMIN

Hmmm ... that appears to be true.

Quick fix for that: either set ENABLE_SSL_ADMIN to 'false', or remove it altogether. It is NOT defined in the configure.php files anymore, unless you've added it yourself (or in your case I suspect it's in your "local" override, which will require manual updating)

(all SSL in the admin is now determined by whether you supply an https URL in HTTP_SERVER or not)

DrByte:

Hmmm ... that appears to be true.

Quick fix for that: either set ENABLE_SSL_ADMIN to 'false', or remove it altogether. It is NOT defined in the configure.php files anymore, unless you've added it yourself (or in your case I suspect it's in your "local" override, which will require manual updating)

(all SSL in the admin is now determined by whether you supply an https URL in HTTP_SERVER or not)

Actually in the situation that identified the condition, an admin module attempts to recognize that the user may have chosen to store files on the catalog side or the admin side, and then further to ensure continuity of file interaction to use the same style of communication and as necessary to perform some substitution/changes in the event that the user has chosen to try to enter the admin directory path into the database. The goal being for the code to 1) recognize that the admin directory has been entered as a part of the path to the user defined storage location (there remains some work to be done to that as it does not "properly" address the use of /../../. for example, though if that begins with the admin directory's folder name then it will be "better", but still needs a smidge of work and there are examples in ZC that can be used to do this), 2) align the user to the applicable file/folder locations that were chosen and based on a few factors, this is primarily where the error is as there was not a consideration that one of the many constants in the configure.php files were going to go away, so now to just rethink/refactor the decision tree so that functionality is maintained for the newest and existing ZC versions that are/have been supported. Understand that the path forward ought to be to support the latest, but it should at least support ZC 1.5.4 for now and does/will if the above is properly addressed in the code.

For compatibility purposes, you could put a line in the startup of your plugin to do:
if (!defined('DIR_WS_HTTPS_ADMIN')) define('DIR_WS_HTTPS_ADMIN', DIR_WS_ADMIN);

DrByte:

For compatibility purposes, you could put a line in the startup of your plugin to do:
if (!defined('DIR_WS_HTTPS_ADMIN')) define('DIR_WS_HTTPS_ADMIN', DIR_WS_ADMIN);

Having not yet "rerevieed" the two sets of code (ZC 1.5.5) and the plugin that certainly was one of the avenues I was considering. I want to be sure it's not just a quick fix too. While the code worked for earlier versions of ZC, it possibly could be better sequenced to address/consider this condition. :) more than appreciate the guidance.

Zen Cart can still be configured with separate values for HTTP_SERVER and HTTPS_SERVER for the administrative interface (by defining it in the configure.php or an override file)... And they can also still define and override ENABLE_SSL_CATALOG as well... While this is still possible (and supported by the core code), DIR_WS_HTTPS_ADMIN may still be needed on some server configurations...

Perhaps in the future Zen Cart will force end users to configure the admin to only operate using one protocol and host... But until that time, I would prefer if an "automatic" define for DIR_WS_HTTPS_ADMIN was added to the file "/admin/includes/defined_paths.php" for compatibility purposes.

lhungil:

Zen Cart can still be configured with separate values for HTTP_SERVER and HTTPS_SERVER for the administrative interface (by defining it in the configure.php or an override file)... And they can also still define and override ENABLE_SSL_CATALOG as well... While this is still possible (and supported by the core code), DIR_WS_HTTPS_ADMIN may still be needed on some server configurations...

Perhaps in the future Zen Cart will force end users to configure the admin to only operate using one protocol and host... But until that time, I would prefer if an "automatic" define for DIR_WS_HTTPS_ADMIN was added to the file "/admin/includes/defined_paths.php" for compatibility purposes.

This is how I addressed handling compatibility:

$path_to_file = (IS_STORE_SIDE ? /* BOF Storeside */ defined('ENABLE_SSL_CATALOG') && ENABLE_SSL_CATALOG === 'true' ? HTTPS_CATALOG_SERVER . DIR_WS_HTTPS_CATALOG : HTTP_CATALOG_SERVER . DIR_WS_CATALOG /* EOF Storeside */ : /* BOF Adminside */ (defined('ENABLE_SSL_ADMIN') && ENABLE_SSL_ADMIN === 'true' ? (defined('HTTPS_SERVER') ? HTTPS_SERVER : HTTP_SERVER) . (defined('DIR_WS_HTTPS_ADMIN') ? DIR_WS_HTTPS_ADMIN : DIR_WS_ADMIN) : HTTP_SERVER . DIR_WS_ADMIN) /* EOF Adminside */) . $sub_directory_ends_with_slash . $file_name;
  

The thing is that previously I was checking to see whether they accessed this admin page using SSL or not and then generated the path using the applicable SSL folder path rather than counting on the settngs of using SSL as being true or not. It's rare, but I wanted the associated link to maximize. The use/possibility of using the SSL if it was available whether the admin configure.php had the setting correct or not... I could to some extent still do that, but at the moment the "cost" outweighs the reward... The above works...