Dynamic Price Updater

[MichaelT]

Hello.

Could someone please advise on the following Dynamic Price Updater question?
- ZC version v1.5.5b
- responsive Sheffield Blue template
- DPU version v3.0.4

I installed all of the plugin files and verified that they are in the correct locations.

DPU worked the very first time I tried to test it, but only once- something seems to be changing the status of the plugin to "false" (off).

I can turn it back on in admin, and it works, but only until I refresh the product page, or if I close the browser page entirely and relaunch the site to go to the home page. Any action that closes or refreshes a page causes the plugin to be disabled.

Any advice on how to fix, or where I might start looking for the problem is most welcome. TIA.

Michael

[mc12345678]

Hello.

Could someone please advise on the following Dynamic Price Updater question?
- ZC version v1.5.5b
- responsive Sheffield Blue template
- DPU version v3.0.4

I installed all of the plugin files and verified that they are in the correct locations.

DPU worked the very first time I tried to test it, but only once- something seems to be changing the status of the plugin to "false" (off).

I can turn it back on in admin, and it works, but only until I refresh the product page, or if I close the browser page entirely and relaunch the site to go to the home page. Any action that closes or refreshes a page causes the plugin to be disabled.

Any advice on how to fix, or where I might start looking for the problem is most welcome. TIA.

Michael

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?

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.

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

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