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.

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

[RixStix]

Thank you mc12345678

I can understand and make those edits without fearing a catastrophic fatfingered mistake.

The bits and pieces I read, updating to 157 scares the crap out of me.

[dbltoe]

The bits and pieces I read, updating to 157 scares the crap out of me.

I guess it's like the bible. One group reads it and drinking is fine while the other says it's a sin.

Don't read into any info about upgrade without optimism as your glasses. So many things are improved. Many are involved. Nearly decades old bugs are being "found" because more are invited to contribute. Heck, they even let me help here and there.

I've found I can swap in 1.5.7 even faster than before and easier than with 1.5.6c. The only thing you have to fear.... Well, you know.

But, it's more about what the owner thinks they need than what they really need. "Gotta have purdy!" "Need geo tags!" Really? So the person can stop buying on line at 2 AM and wait until tomorrow to drive to your store?

But here's just one small part of 1.5.7. Accessibility. Doesn't mean you get more workspace on your desk. It's standards the W3C have set forth worldwide to make it better for everyone to shop. There's a couple of Chrome extensions (Web Developer and Lighthouse) that can make a store owner stop the craziness of thinking the SEs like big, fancy colors and graphics which the SEs will NEVER be able to see. We've been playing with responsive_classic as there still needs to be something for the little guy to use until they can find something "better". And, believe me, I use the term facetiously!.

https://tinyurl.com/yb5b3p36 is a test site for 1.5.7 with no mods and all demo products added. It has all sideboxes and visible settings turned on.

Using Web Developer, the site has no CSS errors except for those in the font-awesome.css that we can't control. And, there's only one HTML warning still to be addressed. Web Developer's Accessibility test gives us no errors (well, occasionally one when the bannerSix doesn't have an alt tag) and, importantly, no contrast errors. The Alerts are really a feature for the responsiv_classic template in that they result from Zen Cart "covering" the page with your product's name. It's Zen Cart's version of, "That number to call, again, is.."

Using Lighthouse, we get a score of 99, 100, 100, 100. Again, the 99 is due to external issues (jQuery and the aforementioned font-awesome.css). We could bring them in house but, you'd have to update once a week. Now, THAT is scary. I've attached an image of the score.

SO.... After all this, what in the world does it have to do with DPU? Actually, a lot. When you add a special/discount, the price is shown with any changes on the product's page and any other page that contains a listing for the product. The original price is lined out and the new price is in red (good old #FF0000). Nearly 10% of the world's population might never see the price. They cannot see red. So, if you look at the Specials Page, you may think the color is a little off but, its setting means the entire world has a better chance of seeing it. Google Web Accessibility Lawsuits. 2017 - #814. 2018 - #2285. 2019 - ~2500+. These are US figures.Attachment 19021