Dynamic Price Updater

[mc12345678]

That is actually my bad, I ment to write Includes > auto_loaders > config.dynamic_price_updater, not the jscript. As far as placement goes, I have triple checked my uploads, and everything is where it is supposed to be.

That will cause a problem of being present if includes/classes/dynamic_price_updater.php is not in place or not fully loaded to the system

Again though the logs as described in the above link would help to identify the issue otherwise we will be talking about how things should be and aren't in some way as expected.
.

[mc12345678]

I dont know if this has been mentioned previously or not, but in trying to install DPU, I kept getting a complete site crash on upload. Setting DPU Status to False had no effect on this. I personally am just begaining to learn PHP, so I have no idea as to what incompatibilities I should be looking for, however I do know how to narrow it down to what files in general are the problem-causers.

For referance, I am running Zen-Cart 1.5.5d, and DPU 3.0.8.

Includes > auto_loaders > jscript_dynamic_price_updater is causing the entire site crash. Removing it alone made everything run again, but I'm FAIRLY certain it's an important file to have. This did leave me with compleatly blank screens however, when I went to an actual product discription page.

Removing Includes > modules> pages > product_info > jscript_dynamic_price_updater fixed the white-page issue, but it doesn't matter, as with those two files removed, the module wouldn't work in the first place...

Although the above information at least implies that the installer ran (admin->configuration for DPU is present) when reviewing the jscript_ file in the product_info page, one of the first things that is in that file is a test of a database define. If the system were in strict mode and the database settings were removed, but this file was not, then an error would be logged. (not a condition expected here because the database settings were present.) still, there is no real reason to leave that line of the file as is, so will be making a change there. As to removing the autoloader file which in turn wouldn't load the dpu class and have it available for that file? I'm not so sure that coding for that condition is the real right thing to do as it imples that for any program that is installed that it should check on each use that the package is installed. Perhaps during installation or as requested this makes sense, but not each and every time it is used. For example the language class isn't exactly verified for presence by a specific if test, but it is by use of a require.

I (and I'm sure others) would be interested to know what the issue(s) are/were with this install. If you did receive log files (myDebug) would you mind sharing the pertinent contents? If you figured out what wasn't fully/properly installed would you mind sharing as well?

I apologize if I came off too hard with my previous post(s). I allowed the current pressure to resolve some minor things to interfere with my normal patient support.

So back to the file removal scenarios. Removal of the autoloaders file from the catalog side will in fact prevent the dpu class from loading and will cause a cascade of non-functionality since that file does the central processing of the data. Removal of the jscript_ file from the product_info pages directory will prevent "communication" between the user and DPU, but won't generate an error.

With both files in place there are a number of points in between that could have a problem if the upload didn't complete (partial file uploaded) or if there was some other related issue. This is where the debug logs would help rather than guessing at all the possibilities. So, if you wouldn't mind posting back, would appreciate it

[Lordzoabar]

That's fine. I compleatly understand stress from a thousand minor issues building up.

After finally figuring out that the write permissions for our Logs folders were turned off..... (I inherited the site maintainance from someone else, in order to clean up their mess...) This is what I've got.

[B] PHP Parse error: syntax error, unexpected '(float)' (double) (T_DOUBLE_CAST) in /home/athensar/public_html/includes/classes/dynamic_price_updater.php on line 200

Line 200 reads:

      $this->shoppingCart->contents[(int)$id] = array('qty' => (empty((float)$qty) || (float)$qty < 0 ? zen_get_buy_now_qty((int)$id) : (float)$qty)); //(float)$qty); 

[mc12345678]

That's fine. I compleatly understand stress from a thousand minor issues building up.

After finally figuring out that the write permissions for our Logs folders were turned off..... (I inherited the site maintainance from someone else, in order to clean up their mess...) This is what I've got.

[B] PHP Parse error: syntax error, unexpected '(float)' (double) (T_DOUBLE_CAST) in /home/athensar/public_html/includes/classes/dynamic_price_updater.php on line 200

Line 200 reads:

      $this->shoppingCart->contents[(int)$id] = array('qty' => (empty((float)$qty) || (float)$qty < 0 ? zen_get_buy_now_qty((int)$id) : (float)$qty)); //(float)$qty); 

Good work sleuthing out the logs folder issue(s). Probably then also saw that that particular issue had been discussed with a solution provided. Since then (a couple of weeks ago) I've also added some features to the mix for an improved user experience.

Take a look at this comparison between version 3.0.8 and the current github software: https://github.com/mc12345678/Dynami...3.0.8...master

It contains a function that I plagiarized from a Pull Request pushed by DrByte for an upcoming ZC release (please follow the depth of that PR for proper credit recognition).

Unfortunately in trying to enforce variable type and value, a little bit of a work around was needed to provide a single function that gives the needed data/value instead of a continued horrid amount of logic each time. :)

Btw, it also was that I was aggrivated at myself that I couldn't better express what was needed so that you (and others) could get through this faster than slower. :)

[Lordzoabar]

SUCCESS!

If I am understanding what you said correctly, the module has issues when presented with a product that has multiple attributes? Our shop deals with custom framing and photo printing/restoration, so I'm assuming when it was requesting product size, paper type, glass type etc... everything else got overwhelmed which led to a full-on crash.

That it's finally working, especially with those stated options, this is an absolute godsend for us. :)

[mc12345678]

Just posted Version 3.2.0 of DPU to be reviewed for issue.

Here is a summary of the changes made:

3.2.0, What changed:
- Identified this version as 3.2.0 because 1) this update provided significant new functionality and modified/provided new database features and 2) 3.1.0 had previously been identified in the github path/history and did not want to cause undo confusion.
- Commented out code that performed no operation/action.
- Added an update to the customer's latest page when using an ajax style call to improve display of information on the who's online admin page.
- Added a method to update price text to represent when none and less than all attributes have been selected.
- Added DPU_ATTRIBUTES_MULTI_PRICE_TEXT to be able to control which of the pretext(s) to allow to show.
- Added a variable to be able to update/display the text before the first price when price includes a special and/or a sale.
- Added ability to update what is known as the normalprice which is the price/value that is crossed out when there is a sale or other special.
- Added stock quantity update capability which incorporates the possibility of operating with ZC 1.5.x and control how the information is replaces other content. Guidance for display modifications provided in readme.txt.
- Corrected use of float casting to use code published in ZC 1.5.6 to support strict server mode.
- Reworked code to better account and control sub-functional area execution.
- Removed single quotes from SQL queries that included casted integers to minimize further processing.
- Expanded attribute text switching to more than product priced by attribute such that should apply to product that have attributes that affect the base price.
- Corrected price display and determination to include pricing associated with text (word and/or letter pricing, etc...)
- Updated javascript side to use exactly equal to instead of loosely comparing two values (in a majority of examples.
- Switched javascript calls to use dot notation where able.
- Added a fallback attempt for collecting/setting JSON response if responseJSON is empty but a non-fault responseText is provided.
- Moved javascript variable declaration out of most function calls.
- Corrected an issue reported by mvstudio of where the expected text to be in front of the priced item would not be displayed if the imgLoc variable in the includes/modules/pages/PRODUCT_TYPE/jscript_dynamic_price_updater.php file was not set to "replace". Essentially the result was that pspClass would be blank when sending to ajax.
- Added change detection and capture of the html element textarea and changed the text detection to an input event instead of a keyup event. This allows capture/detection of pasted content without firing off multiple events for the same modification. Additional testing may reveal the need to incorporate other event listeners. The process would be similar as shown for the number case.
- Updated ajax.php file to prevent known spiders from performing ajax requests. This is from the ZC 1.5.6 version of the file
- Moved the status notification from an alert to a console log when zcJS is not used and a 200 status result is not received.

Once reviewed and accepted it will be available for download from this ZC download page.

It may also be obtained from this github tag.

[mc12345678]

Just posted Version 3.2.0 of DPU to be reviewed for issue.

Here is a summary of the changes made:


Once reviewed and accepted it will be available for download from this ZC download page.

It may also be obtained from this github tag.

Version 3.2.0 of Dynamic Price Updater has been posted to the download section and is available from here.

[Lordzoabar]

Updated and everything is (mostly) working perfectly. Dynamic Price Updater is doing everything it is supposed to be doing, except for any items I have that are marked as on sale. It still dynamically updates the price, both before and after the sale is effected, but it is causing a weird graphical glitch. I've included pictures of one of the product pages, both with and without DPU enabled.

Enable=FALSE


Enable=TRUE


I have Error Logging activated, but it isn't turning anything up, so I have no idea where to actually look.

https://www.athensartandframe.com/ is our live site, if you want to see what I'm talking about in action. It's pretty much every item that is marked as being on sale, which will be our Diploma and Business frames, and the framed artwork.

[mc12345678]

Updated and everything is (mostly) working perfectly. Dynamic Price Updater is doing everything it is supposed to be doing, except for any items I have that are marked as on sale. It still dynamically updates the price, both before and after the sale is effected, but it is causing a weird graphical glitch. I've included pictures of one of the product pages, both with and without DPU enabled.

Enable=FALSE


Enable=TRUE


I have Error Logging activated, but it isn't turning anything up, so I have no idea where to actually look.

https://www.athensartandframe.com/ is our live site, if you want to see what I'm talking about in action. It's pretty much every item that is marked as being on sale, which will be our Diploma and Business frames, and the framed artwork.

So, a portion of the issue was identified after posting the change to the ZC forum for review, another part though is new "territory" as I haven't seen the space that follows the Sale: turned into the html entity   before.

The part that was identified was the reuse of the definition: PRODUCT_PRICE_SALE for the preDiscPrefix when displaying the product's "original" price as compared to its sale price.

If you take a look in: includes/classes/dynamic_price_updater.php
Within the function prepareOutput, you would see this code section related to the final display of a product that has a sale:

        case ($_POST['pspClass'] == "productSalePrice"):
            $this->prefix = PRODUCT_PRICE_SALE;
            $this->preDiscPrefix = PRODUCT_PRICE_SALE;

Basically you will want to provide different text (right side) for the last line of code provided above. This can be done by adding another language definition for the plugin such as UPDATER_PREFIX_SALE_DISCOUNT_TEXT, add the define to the language file, then replace the second use of the above PRODUCT_PRICE_SALE with the above UPDATER_PREFIX_SALE_DISCOUNT_TEXT and then should be fine.

I wanted to provide such definitions for each entry, but the realized that searching for the text to change it would return many entries or I would have to put text in for all of them that was different and more than likely undesirable anyways. :) The third option which is needed regardless is to offer more instruction about how to use/modify the results to get something more desirable.

For comparison of what the store did as compared to what it will, looks like you will want a prefix for the pre-discount price of empty single quotes: ''.

So, in: includes/languages/english/extra_definitions/dynamic_price_updater.php

Add:

define('UPDATER_PREFIX_SALE_DISCOUNT_TEXT', '');

Then in the class file at line 116, change:

           $this->preDiscPrefix = PRODUCT_PRICE_SALE;

To:

           $this->preDiscPrefix = UPDATER_PREFIX_SALE_DISCOUNT_TEXT;

That should resolve your situation for sale product.

[Lordzoabar]

That ended up working perfectly, except I have another issue, which I honestly thought this would have fixed as well, but IDK...

Enable=FALSE


Enable=TRUE


I'm assuming this is from the same Class file, but I didnt see anything that would create that "Your Price" thing.

https://www.athensartandframe.com/in...index&cPath=73 It's only our First Dollar frames that really show this issue. All of the frames in other subcategories have "Starting at" show up at first, but after a second, and the updater fully loads, it disappears and everything works as it should.