Dynamic Price Updater

[mc12345678]

Contents of YOUR_ADMIN/includes/auto_loaders/config.dpu.php :
-----------------------------------
<?php
// Dynamic Price Updater

if (!defined('IS_ADMIN_FLAG')) {
die('Illegal Access');
}


$autoLoadConfig[999][] = array(
'autoType' => 'init_script',
'loadFile' => 'init_dpu_config.php'
);

// uncomment the following line to perform a uninstall
// $uninstall = 'uninstall';

-------------------------------------

Installation for the plugin instructs to place the init_dpu_config.php in these two folders, which is where my search led me:

- YOUR_ADMIN/includes/init_includes/
- /includes/init_includes/

-MT

There are two files that have the same name, one in the admin and one in the catalog side, but they each have different content and function. DPU does not have code to do what you are seeing (disable of the operation after installed and set to on). Something else outside of the DPU fileset is causing your issue. I realize this post and my previous crossed each other and that this is a restatement of my last, but the issue is outside of the DPU fileset. Sure, setting the install settings to default to true "corrects" the current problem of it continuously getting set to off, but the auto-disablement of DPU is not caused by DPU. Unfortunate, but I'm thinking that on the next update to rename things so that such code doesn't find DPU and potentially cause aggravation to those attempting to install it only to find that "it doesn't work" when the lack of operation has nothing to do with DPU but instead someone else choosing to consistently think that it basically shouldn't exist.

[MichaelT]

There are two files that have the same name, one in the admin and one in the catalog side, but they each have different content and function. DPU does not have code to do what you are seeing (disable of the operation after installed and set to on). Something else outside of the DPU fileset is causing your issue. I realize this post and my previous crossed each other and that this is a restatement of my last, but the issue is outside of the DPU fileset. Sure, setting the install settings to default to true "corrects" the current problem of it continuously getting set to off, but the auto-disablement of DPU is not caused by DPU. Unfortunate, but I'm thinking that on the next update to rename things so that such code doesn't find DPU and potentially cause aggravation to those attempting to install it only to find that "it doesn't work" when the lack of operation has nothing to do with DPU but instead someone else choosing to consistently think that it basically shouldn't exist.

Duly noted. I'm going to roll back the change that I made. I appreciate your position that it's not a proper fix. I'll keep looking for the underlying cause. If unsuccessful, I'll have to find another way to use dynamic price updating, as management is insisting on this feature.

With regard to posting, I'm one week into ZC, PHP coding, this forum, etc. I have inherited this store-building task and I'm compelled by management to learn in real-time. I'll do a more thorough job next time.

Thank you again for your time and talent.

-MT

[mc12345678]

Duly noted. I'm going to roll back the change that I made. I appreciate your position that it's not a proper fix. I'll keep looking for the underlying cause. If unsuccessful, I'll have to find another way to use dynamic price updating, as management is insisting on this feature.

With regard to posting, I'm one week into ZC, PHP coding, this forum, etc. I have inherited this store-building task and I'm compelled by management to learn in real-time. I'll do a more thorough job next time.

Thank you again for your time and talent.

-MT

Understandable and understood about the expressed need to resolve this. As I said a few posts back, I suggest using the developers tool kit (DTK) to search on smaller pieces of "unique" information within the store. Something that a program might use to evaluate the response. One such fragment is DPU_ then to possibly use DPU filenames, as they tend to not change from version to version. Or do a comparison of a vanilla install of your version of ZC to your ZC store, skim through the differences of the active part of the site to see what may be doing this disabling.

Many ways to approach the issue, I wish I could remember what it was that I saw a long time ago that did exactly that. It was one reason I wanted to update DPU was because in a way the software needed DPU not to be disabled, but to play nicer with the javascript. Instead of doing some "polite" brush-off action, it just basically stomped on it. Once you figure out the culprit, it would be nice to know so that something can be done with that software to not have someone else in the same position.

[mc12345678]

Okay, so identified the issue.

It appears that in uploading the files that one or more of the admin files were placed in the catalog side. Specifically of concern is/was the admin/includes/auto_loaders/config.dpu.php file. This file kicked off the installation process for the plugin which includes removing itself before inserting, but at the end of the process within the loaded file, it is to remove the config file, but it was looking for the config file in the admin directory.

So, my temporary fix (until the fileset is uploaded again) would be to modify the admin/includes/auto_loaders/config.dpu.php file to be like below:

<?php
// Dynamic Price Updater

if (!defined('IS_ADMIN_FLAG')) {
  die('Illegal Access');
} 

if (IS_ADMIN_FLAG === true) {
  $autoLoadConfig[999][] = array(
    'autoType' => 'init_script',
    'loadFile' => 'init_dpu_config.php'
  );
}else {
  @unlink(__FILE__);
}

// uncomment the following line to perform a uninstall
// $uninstall = 'uninstall';

May come up with a different solution, but it seems it would solve the issue that was observed by @MichaelT and would prevent it from occurring again in the future.

Without such a correction, if someone sees the issue described (activate DPU and then navigate and it deactivates it), the operational fix is to remove catalog/includes/auto_loaders/config.dpu.php and then investigate how many of the other admin files were copied/stored on the catalog side of the store and remove the admin files from the catalog side.

Would recommend verifying that the admin files are in place on the admin side and that the catalog side wasn't installed into the admin folder. (Note: generally should not be anything needed to do/check on the admin side at that point, but it wouldn't hurt. I say this because if the plugin wasn't previously on the server, then the only way to activate it is to have had the files at least temporarily in the admin directory, if it was previously installed, there is little that was changed regarding the admin installation file(s) at least for 3.0.4 other than the version number change and therefore not likely to be "much" missing if not again temporarily placed on the server.)