Dynamic Price Updater

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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.

Quote:

---

Originally Posted by 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

Quote:

---

Originally Posted by 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:

Code:

---

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

Quote:

---

Originally Posted by MichaelT

Contents of YOUR_ADMIN/includes/auto_loaders/config.dpu.php :
-----------------------------------

Code:

---

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

Quote:

---

Originally Posted by 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/ssfbt...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/ssfbt...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: