Dynamic Price Updater

[MichaelT]

Thank you for the reply.

> So you're saying that your admin setting to have it on is getting turned to the off position/condition when navigating the store front?

Yes, exactly:
- Turn on plugin (make "true")(on)
- Launch the site in a browser
- Refresh, the admin, and the setting has changed to "false" (off).

> If so it sounds like another plugin is "listening" for the setting and disabling the plugin. I don't recall the constants name, but you would want to search the files (tools->developers tool kit) for that constant and identify where it is used other than the files provided by the plugin.

I tried uninstalling and then installing the previous version (3.0.4) with the same result. I know how to use the DTK, but not exactly sure what a constant is, what it might be called, or where to look.

[mc12345678]

Thank you for the reply.

> So you're saying that your admin setting to have it on is getting turned to the off position/condition when navigating the store front?

Yes, exactly:
- Turn on plugin (make "true")(on)
- Launch the site in a browser
- Refresh, the admin, and the setting has changed to "false" (off).

> If so it sounds like another plugin is "listening" for the setting and disabling the plugin. I don't recall the constants name, but you would want to search the files (tools->developers tool kit) for that constant and identify where it is used other than the files provided by the plugin.

I tried uninstalling and then installing the previous version (3.0.4) with the same result. I know how to use the DTK, but not exactly sure what a constant is, what it might be called, or where to look.

Had a chance to look it up. The constant (in ZC a define of an all capitalized "string" to a value that can not be changed after it is defined) is: DPU_STATUS

The problem is not in DPU but caused by other code that either loads in advance of the database and prevents the constant from being defined to on, or it allows a single use and in the process of that loading changes the database setting so that the next time the database data is loaded (page refresh or other navigation of the site) the value is set to off... more than likely it is done by that plugin because DPU used to override the javascript to listen to changes in the attribute options and therefore that plugin would not function as expected, or that there were conflicting actions that would occur and the only way for the specific "plugin" (could be a template) is to not allow DPU to do what it does.

Anyways, you'll be looking for code that is not in the DPU fileset that monitors and modifies the constant DPU_STATUS.

[MichaelT]

Had a chance to look it up. The constant (in ZC a define of an all capitalized "string" to a value that can not be changed after it is defined) is: DPU_STATUS

The problem is not in DPU but caused by other code that either loads in advance of the database and prevents the constant from being defined to on, or it allows a single use and in the process of that loading changes the database setting so that the next time the database data is loaded (page refresh or other navigation of the site) the value is set to off... more than likely it is done by that plugin because DPU used to override the javascript to listen to changes in the attribute options and therefore that plugin would not function as expected, or that there were conflicting actions that would occur and the only way for the specific "plugin" (could be a template) is to not allow DPU to do what it does.

Anyways, you'll be looking for code that is not in the DPU fileset that monitors and modifies the constant DPU_STATUS.

Yikes.

I just made what is probably a really inelegant fix, but it seems to have worked.

I looked for the DPU_STATUS per your suggestion; it lives in two (identical) files that are part of the DPU package. I changed the code from:

//-- DYNAMIC PRICE UPDATER ORIGINAL VERSION
//$sql = "INSERT INTO ".DB_PREFIX."configuration VALUES (NULL, 'Dynamic Price Updater Status', 'DPU_STATUS', 'false', 'Enable Dynamic Price Updater?', '".$dpu_configuration_id."', 10, NOW(), NOW(), NULL, 'zen_cfg_select_option(array(''true'', ''false''),')";


to:

//-- DYNAMIC PRICE UPDATER VERSION TO FIX FALSE RESET ISSUE
$sql = "INSERT INTO ".DB_PREFIX."configuration VALUES (NULL, 'Dynamic Price Updater Status', 'DPU_STATUS', 'true', 'Enable Dynamic Price Updater?', '".$dpu_configuration_id."', 10, NOW(), NOW(), NULL, 'zen_cfg_select_option(array(''true'', ''true''),')";

I'm supposing that this change prevents the disabling of the DPU via admin, which is OK, because I'll want it on all of the time anyway.

I'll obviously test this thoroughly. I'm new to coding and don't know if this change is OK, or playing with fire. Opinions welcome.

Grateful thanks to mc12345678 for your time and excellent guidance.

- Michael

[mc12345678]

Yikes.

I just made what is probably a really inelegant fix, but it seems to have worked.

I looked for the DPU_STATUS per your suggestion; it lives in two (identical) files that are part of the DPU package. I changed the code from:

//-- DYNAMIC PRICE UPDATER ORIGINAL VERSION
//$sql = "INSERT INTO ".DB_PREFIX."configuration VALUES (NULL, 'Dynamic Price Updater Status', 'DPU_STATUS', 'false', 'Enable Dynamic Price Updater?', '".$dpu_configuration_id."', 10, NOW(), NOW(), NULL, 'zen_cfg_select_option(array(''true'', ''false''),')";


to:

//-- DYNAMIC PRICE UPDATER VERSION TO FIX FALSE RESET ISSUE
$sql = "INSERT INTO ".DB_PREFIX."configuration VALUES (NULL, 'Dynamic Price Updater Status', 'DPU_STATUS', 'true', 'Enable Dynamic Price Updater?', '".$dpu_configuration_id."', 10, NOW(), NOW(), NULL, 'zen_cfg_select_option(array(''true'', ''true''),')";

I'm supposing that this change prevents the disabling of the DPU via admin, which is OK, because I'll want it on all of the time anyway.

I'll obviously test this thoroughly. I'm new to coding and don't know if this change is OK, or playing with fire. Opinions welcome.

Grateful thanks to mc12345678 for your time and excellent guidance.

- Michael

What are the contents of: YOUR_ADMIN/includes/auto_loaders/config.dpu.php

For your files on your server?

The only way that you wouldn't face errors by inserting an existing key is if it was being uninstalled as part of a load and immediately reinstalled...

Also what files were involved with your search? You said two identical places...

[MichaelT]

What are the contents of: YOUR_ADMIN/includes/auto_loaders/config.dpu.php

For your files on your server?

The only way that you wouldn't face errors by inserting an existing key is if it was being uninstalled as part of a load and immediately reinstalled...

Also what files were involved with your search? You said two identical places...

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

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

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

Then also in trying to see what might have led to the observed issue or faster resolution there is this above part of our conversation.

At the time I read this I mistakenly thought that the issue was the confusion of auto_loaders/config.xxx.php file and it didn't dawn on me that the file(s) actually considered were the init_includes/ related files. I've gone back through the instructions (both the readme.txt and readme.md files) and neither identifies that init_includes exists in both admin and catalog, also the config file is named slightly different between the two sides. The catalog spells out dynamic_price_updater while the admin uses dpu as part of the filename.

So had that piece of information been further evaluated then the issue at this server would have likely been resolved faster as an init_includes file is only used on the admin side performing an install by deletion of previous database settings.

[MichaelT]

Then also in trying to see what might have led to the observed issue or faster resolution there is this above part of our conversation.

At the time I read this I mistakenly thought that the issue was the confusion of auto_loaders/config.xxx.php file and it didn't dawn on me that the file(s) actually considered were the init_includes/ related files. I've gone back through the instructions (both the readme.txt and readme.md files) and neither identifies that init_includes exists in both admin and catalog, also the config file is named slightly different between the two sides. The catalog spells out dynamic_price_updater while the admin uses dpu as part of the filename.

So had that piece of information been further evaluated then the issue at this server would have likely been resolved faster as an init_includes file is only used on the admin side performing an install by deletion of previous database settings.

DPU is now working perfectly with no issues. A relief and great start to the day.

Grateful thanks to @mc12345678 for persistent and skillful review of the issue, as well as generous patience with a new Zenner. I have learned quite a lot in a week and will strive to improve my skill set.

Much appreciation from here.

[mc12345678]

Somewhat on second thought that doesn't seem like it would relate either. I also remember seeing some code in something a long time ago that "surreptitiously" disabled/removed DPU.

See problem is that if DPU_STATUS isn't specifically affected then this other code is affecting DPU more generically/globally. Either it is uninstalling everything from the database or particular keys by way of associating the one or more keys for deletion. It would be good to do a few things. One broaden the search to just DPU_ and also to check your logs file(s) to see if/what errors are being logged. By a process of elimination can maybe identify what is being used to filter/affect the database and "narrow" down the search.

Another rather obvious bit of information that would help is as requested for all posts about an issue to follow the posting tips (plugin's installed, template, etc...)

I have a concern for the above fix as it relates to your store and possible changes made to suit your needs. If something else is removing the settings, to only have DPU detect that removal and reinstall, then any changes made in the admin to support your needs will be wiped out requiring a similar "file change" to keep those settings.

Another question, did that search include the entire store (catalog and admin) or just one side?

Another thing, I'm a little disappointed in the person that wrote the code to disable/remove DPU. At least two parties worked to get the desired operation made possible to have one person come along with their code and chuck the other work. And that's making the "parties" small. There have been several that have worked to get this code where it is. There's been yourself to install it, and then there's the fact of just blanketly removing the operation without finding a way for both to co-exist or to document the effect of having both installed so that the installer can make a choice. Afterall, if that other code did what this does, then there would no need to affect DPU, right?

//EOF rant