Dynamic Price Updater

[RixStix]

It appears to me that the DPU module is not functioning as expected based upon this comment.

// Respect the admin setting for version checking to prevent checking this if the store is disabled. (typically set because the version checker may generate warnings/errors.

The adm debug file creation occurred today on several occassions. Other errors, are the typical undefined_constant errors which seem to be quite frequent since beginning the update to 156c.

[Design75]

I just had a better look at the code, and it appears that there is an older version of the "call home function." I already was working on a new version of this mod, so will include this..
The new mod will include updates made by MC123456778, he did the major development, over the last years. My updates are mainly getting the code to the latest standards.

[mc12345678]

I just had a better look at the code, and it appears that there is an older version of the "call home function." I already was working on a new version of this mod, so will include this..
The new mod will include updates made by MC123456778, he did the major development, over the last years. My updates are mainly getting the code to the latest standards.

It's not the "age" of the call home that is an issue, but as RixStix has pointed out that regardless the setting it still tries. This goes back to the use of a constant *and* the value of that constant. In this case, the *text* value of false... In a loose comparison (not using === for example), true == 'false' == 'true'..

The test would work even if it were == 'true', but without any comparison the text value of 'false' causes the inner content to be executed.

The "older" version of the call home had been retained because that was the version that worked on older style systems that would not be expected to require or may not support the newer style(s) where newer ZC versions would already have the call home code and that portion of the file would be omitted. Although in webchills' version of ZC, he has removed the call home code and therefore if it is not included in the file such as this, then installation to a fully German based ZC site causes issues in this portion of the code.

Anyways, where:

constant($module_constant . '_PLUGIN_CHECK')

is present by itself, it could be changed to:

constant($module_constant . '_PLUGIN_CHECK') == 'true'

Or better still:

constant($module_constant . '_PLUGIN_CHECK') === 'true'

Would be more understood to mean that it better be that value or else. :)

Sorry for any previous "flippant" attempt to incorporate such a switch. I think it is a common problem across the plugins that use or attempt to offer an independent control for the plugin separate from the ZC control.

[Design75]

thx for the clarification.

It's not the "age" of the call home that is an issue, but as RixStix has pointed out that regardless the setting it still tries. This goes back to the use of a constant *and* the value of that constant. In this case, the *text* value of false... In a loose comparison (not using === for example), true == 'false' == 'true'..

The test would work even if it were == 'true', but without any comparison the text value of 'false' causes the inner content to be executed.

The "older" version of the call home had been retained because that was the version that worked on older style systems that would not be expected to require or may not support the newer style(s) where newer ZC versions would already have the call home code and that portion of the file would be omitted. Although in webchills' version of ZC, he has removed the call home code and therefore if it is not included in the file such as this, then installation to a fully German based ZC site causes issues in this portion of the code.

Anyways, where:

constant($module_constant . '_PLUGIN_CHECK')

is present by itself, it could be changed to:

constant($module_constant . '_PLUGIN_CHECK') == 'true'

Or better still:

constant($module_constant . '_PLUGIN_CHECK') === 'true'

Would be more understood to mean that it better be that value or else. :)

Sorry for any previous "flippant" attempt to incorporate such a switch. I think it is a common problem across the plugins that use or attempt to offer an independent control for the plugin separate from the ZC control.

[GoldBuckle]

@lat9 admin/includes/installers/dpu/4_0_0-beta_1.php on line 2

4_0_0-beta_1.php:

<?php
/**
V4.0.0, What changed:
- updated the jquery to 4.3.1
- rewritten the class and javascript. Removing all the ancient code, and moving to the builtin ajax functions of Zen Cart
- removed the Multi code formthe class, as it is not used (since v1). If neededit can always be put back in.

4_0_0-beta_2.php

<?php
/**
V4.0.0, What changed:
- updated the jquery to 4.3.1
- rewritten the class and javascript. Removing all the ancient code, and moving to the builtin ajax functions of Zen Cart
- removed the Multi code formthe class, as it is not used (since v1). If neededit can always be put back in.

4_0_0-beta_3.php

<?php
/**
V4.0.0, What changed:
- updated the jquery to 4.3.1
- rewritten the class and javascript. Removing all the ancient code, and moving to the builtin ajax functions of Zen Cart
- removed the Multi code form the class, as it is not used (since v1). If neededit can always be put back in.
- Added code changes from Torvista, MC12345678, and Zen4All

I just removed all three php files above and wallah it now works! I feel like I accomplished something!

[RixStix]

Anyways, where:

constant($module_constant . '_PLUGIN_CHECK')

is present by itself, it could be changed to:

constant($module_constant . '_PLUGIN_CHECK') == 'true'

Or better still:

constant($module_constant . '_PLUGIN_CHECK') === 'true'

Would be more understood to mean that it better be that value or else. :)

Sorry for any previous "flippant" attempt to incorporate such a switch. I think it is a common problem across the plugins that use or attempt to offer an independent control for the plugin separate from the ZC control.

TNX but for a coding dummy, it would help to know which line and the complete line so that more problems don't occur due to a fatfinger in the edit? I'm guessing that the debug files were only generated because the zencart.com phonehome server was having troubles with accepting the phone call yesterday.

Appears on line 114 and 184

constant($module_constant . '_PLUGIN_CHECK')

[mc12345678]

Both of those are appropriate lines in which to make the change when referring to an unaltered intact fileset. I *am* contemplating the use of != 'false' instead of == 'true'...

[RixStix]

Both of those are appropriate lines in which to make the change when referring to an unaltered intact fileset. I *am* contemplating the use of != 'false' instead of == 'true'...

I think it is more of a problem that the zencart plugin server not accepting the phone home attempt.

If you would post the entire lines of code instead of just a snippet of the line, it would make it easier for a non-coder to fix and reduce the potential for an oops.

[mc12345678]

I think it is more of a problem that the zencart plugin server not accepting the phone home attempt.

If you would post the entire lines of code instead of just a snippet of the line, it would make it easier for a non-coder to fix and reduce the potential for an oops.

Here is the PR that incorporates the suggested change: https://github.com/mc12345678/Dynami.../pull/23/files
The red text is where removal occurs, the green text is where insertion is.

The change is based off of the version 3.2.1 proposed distribution, though Design75 is planning to issue the plugin as a 1.5.6 or perhaps 1.5.7 only version which is expected to remove some of the fallback support that has been maintained. For example the DPU class will likely be completely moved into the ajax area instead of being an extra class in the class list. This may mean that the class file currently in the store's catalog would have to be moved/removed to support.

As far as the attempted phone home attempt, it typically is not related to the Zen Cart server or any issue with its ability to communicate but instead the server that is attempting to execute the code as it may not be connected to the internet, https server certificates may not be installed/setup, or there may be some other issue. That's not to say that there occasionally isn't a real issue between the two and unrelated to specifically one or the other, just talking about what is "often" seen.

Anyways, there is no fool proof method to provide changes/suggested changes, so hopefully the above will support your needs and/or way of making changes.

[GoldBuckle]

Now that I can get into my test site's admin I tested a product and I am just getting the spinning ajax-gif, price never loads.