Dynamic Price Updater

rbarbour:

Okay, I had a little extra time this morning. I have worked with that specific "popup" on allot of projects, can't believe I didn't go that route.

Seems to be good, I'll run a few tests, I'm really grateful, haven't had much time these days.
Sometimes a fresh set of eyes can make all the difference. Besides with all that you've done for the ZC responsive design and other useful programs, glad I was able to both make the changes to this plugin that actually made it possible (moving the requery out of the php space and into the on_load event) and help show a way for that code to ZC "friendly". :)

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

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

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.

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.

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.

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.

mc12345678:

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

MichaelT:

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...

mc12345678:

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

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

MichaelT:

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.

mc12345678:

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

MichaelT:

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.

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.)

MichaelT:

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.

mc12345678:

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.

Hi I have a test site set up with Dynamic Price Updater and the attributes are going crazy.

Using http://sitstandforbusiness.com/ssfbtemp/height-adjustable-desks-c-22/the-fundamental-manual-height-adjustable-desk-p-50.html as an example.the price is £224.17 based on the standard or bespoke desktop. The frame only option is meant to discount the price, (which it does) but when you visit http://sitstandforbusiness.com/ssfbtemp/height-adjustable-desks-c-22/the-fundamental-manual-height-adjustable-desk-p-50.html

When I disable VAT it all works fine, but when its included (20%) everything just plays up.

Please could anyone advise? Any advice would be welcome

Ok I've learned a little bit more: IN 1.5.5 the prices are inclusive of VAT only when a zone is applied to Configuration > My Store

But all I need is to include the UK and it works on a fresh install but not my current site.

On the fresh install DPU doesn't work.

Please could anyone give some guidance :cry:

dharrison:

Hi I have a test site set up with Dynamic Price Updater and the attributes are going crazy.

Using http://sitstandforbusiness.com/ssfbtemp/height-adjustable-desks-c-22/the-fundamental-manual-height-adjustable-desk-p-50.html as an example.the price is £224.17 based on the standard or bespoke desktop. The frame only option is meant to discount the price, (which it does) but when you visit http://sitstandforbusiness.com/ssfbtemp/height-adjustable-desks-c-22/the-fundamental-manual-height-adjustable-desk-p-50.html

When I disable VAT it all works fine, but when its included (20%) everything just plays up.

Please could anyone advise? Any advice would be welcome
Dharrison, I didn't get a chance to see the behavior of the page yesterday when this was reported. Just now when looking at the described page, I am seeing the base price upon arrival with the statement that Inc Vat. When changing through the options, I see the price go down (Inc Vat) for the option that recycles the computer, and moves up for the others. I'm not sure what is meant by "everything just plays up", but also it has been a while since I have looked at how Inc/Excl Vat works. I thought that the price display was modified by some "internal" calculations of the plugin rather than by direct use/modification of other code such as the shopping_cart class or otherwise.

To explain how DPU works in the background: when selecting an attribute, a temporary cart is created to include the one item that is on display to include any/all selected attributes. The resulting price of that arrangement of attributes is provided back to the javascript and the applicable/designated location is updated with that information. So, there may be a few things that have to be modified to display both the price with VAT and without VAT so that both can be displayed with the product. One would be the "calculation" done in the dynamic_price_updater class so that a second price can be returned to the javascript and the second would be to collect/use that second price and apply it to the correct screen location...

But, detail is needed to know what is happening, what is expected to happen and what has been tried.

dharrison:

Ok I've learned a little bit more: IN 1.5.5 the prices are inclusive of VAT only when a zone is applied to Configuration > My Store

But all I need is to include the UK and it works on a fresh install but not my current site.

On the fresh install DPU doesn't work.

Please could anyone give some guidance :cry:

As described in the previous message, basically, doesn't work isn't descriptive enough to address a possible solution. Afterall, DPU has been installed on a fresh install of ZC 1.5.5e and it works within a default store. I have not (though perhaps someone else has) installed it in attempts for it to work with the alternate price/display options and the possibility of displaying both prices (including tax and excluding tax ie. with VAT/without VAT) or adjusting the display from/to with tax or without.

Hi mc

I have just included the VAT again.

If I use http://sitstandforbusiness.com/ssfbtemp/height-adjustable-desks-c-22/the-fundamental-manual-height-adjustable-desk-p-50.html as an example. The base price is £269.00

Ignoring the recycling option for a moment, the standard 1200x700x18 and the bespoke option 1220x800x25 have no surcharge whatsoever (+0) but for some reason tax is being added to both options (it should read £269 inc vat, but instead it totals to £322.80)

But when I add the standard desk to the cart, it displays the correct price in the cart (£269)

Please help. I can gladly PM a temporary login