Printable View
I have looked for a piece of code, it maybe slove this problem.Quote:
firstGroup optionID: 3
Uncaught NotFoundError: Failed to
execute 'removeChild' on 'Node': The node to be removed
is not a child of this node.
Code:function removeElement(_element){
var _parentElement = _element.parentNode;
if(_parentElement){
_parentElement.removeChild(_element);
}
}
Does the latest version of this work on 1.39h? Or should I install an older version?
(Im fully aware of the problems with running 1.39h and I am working towards migrating this site to Wordpress and Woocommerce but its going to be a few months...)
It probably will, but I have not tried
Quote:
Originally Posted by Chargin
Can anyone provide a reason why this code should claim all onchange, onkeyup, and onselect javascript actions for applicable attribute types rather than sharing those actions with other javascript code or be required to be in some way loaded after the other javascript code?
Quote:
Originally Posted by mc12345678
Nope,
The code is ancient, and in the past there probaly was a reason, or the original coder did not now or had no better reason to do it another way. I have been planing on updating the codebase for a long tome, but am lacking the time. If you want to update this mod be my guest :D
In a very small part that was something I was considering, but I'm truly just stepping into this game. :blush: Recalled maybe 2 years ago installing it somewhere and having to make a change so that the actions of this plugin and another would fire, but didn't remember that this last weekend when I was again trying to get it to play nice with another javascript action. Do you happen to have your code on github or otherwise available?Quote:
Originally Posted by Design75
Forgot to add that I wasn't sure if there was some sort of "security" concern or other tidbit that I wasn't aware of. I've got a post prepared at least to address that issue which may help others like the tidbits that I found in this forum to address errors encountered.
FWIW, generally speaking with addressing the few issues encountered, this code does/can be used with Stock By Attributes (specifically when using multiple attributes and dynamic dropdowns as implemented in the github version). I haven't worked through the initial display of a 0 price instead of starting at, but I think while reviewing the thread that it is addressed.
It would be nice if this mod could be rebuild to work nice with SBA. I always cheated 0 price issue with setting the base price to 0.0001. Not a good solution (I know), but it worked).Quote:
Originally Posted by mc12345678
I the new mod is written properly it may make a chance to get incorporated into the core code
So what is the final consensus? Is that officially broken on 1.55a? Are there any alternatives? I'd rather have an updated price on the fly so I can get rid of hte (+3.00) in the attributes drop down.
Functional with minor modification as either described in this thread or as identified through troubleshooting with browser's tools (F12).Quote:
Originally Posted by Kcin
There are some github forks with a few already included modifications to address some of the items/issues. But it does or relatively can work with ZC 1.5.5a.
As to the (+3.00), I don't know why you wouldn't want to indicate to the customer that the option being chosen affects the price in some way rather than the possibility that if they 1) have javascript disabled or 2) fail to see the change in price upon selection for some other reason and then not realize how the prices play out.Quote:
Originally Posted by Kcin
The prices are listed pretty large and noticeable. You would see it change, I have no doubt. The (+3.00) just looks jenky. Look at any large corporate website and show me one where the options change like that. I may just end up changing the code so it just has the price and remove the + and price everything by attribute.
Plus, I have some products that the attribute just increases the price, and I have other products that are priced by attribute. On those priced by attribute, the price is listed as the smallest amount from attributes. Lets say $5.00. So now the listing says "Starting at $5.00" and when you hit the list of drop down attributes, you have one attribute that sets the price to (+$10.00). I think to the average consumer, they are going to see the "starting at $5.00" and then see the (+$10.00) and assume it costs $15, when in fact it's just $10.00.
IMO, updating the price on the fly by attribute makes way more sense whether you keep the additional display in the attribute or not.
I know just enough to get me by, I'm not sure I have it in me to trouble shoot and correct code. Oh well. Thanks!Quote:
Originally Posted by mc12345678
Haven't fully tested all possibilities but I have done a little updating on github to at least address the code that breaks operation. It's not like a huge modification, but I'm using it on a test 1.5.5 site with success so far.Quote:
Originally Posted by Kcin
Internet service caused this to be double posted. Original duplicate removed.
So you know the + in (+$10) is not required. Particularly isn't needed in such a price-by-attribute condition where the value of the entire product is based on the value of the attribute and not by some form of increase/decrease.Quote:
Originally Posted by Kcin
As to using the +$3 scenario for a product not priced by attributes, got ya thinking didn't I? So, I have seen a site that actually changes the option listings based on which attribute was selected, though I can't recall which it was. Basically, if starting at the "base" model, some attributes had +x, others might have -y, once one of them was selected say +x, then the -y value changed to the result of -y-x... this way one knew that based on selecting a particular value from the list the price would change by this much and in this direction.
As to the "big price change" again, I resort back to conditions where javascript is disabled or more rarely not available. It is advisable to ensure that the maximum audience can be reached without sacrificing the "needs" of the many.
Oh, and BTW, there is no code change needed to remove the +, simply don't put a negative or anything in the box to the left of the attribute price in the attributes controller.
Ahhh. Very nice.Quote:
Originally Posted by mc12345678
I changed my approach after our exchange. I just defaulted what I believe to be the "main" variant, and then price goes up and down from there. So I'm okay with leaving the additional info, but I would still love to have the price update on the fly, because for instance, the product I just listed it's primary price is $27, it's sample price is 1/5th of that, so $5.40, and the attribute pricing for that is (-$21.60). When you select that though, the customer won't know the price until they add it to their cart or do the math. It would be nice if they could quickly see the price change, and then the attribute is there for backup in the scenario you detailed where the updater might not work.
Did you already post the link in this thread to your tweaked version? I'd like to give it a try.
Something to keep in mind with your attribute pricing seeing as you offer a sample of a product is the effect of any pricing "arrangement" on "published" pricing and others searching for that product based on the "base" price.Quote:
Originally Posted by Kcin
As to posting the link, I had not. Partially because although I was trying to get everything modified merged into one branch and tested a few additional things about it. I was able to update the changes onto a test site and didn't get JS errors but I didn't totally have a chance to compare the code at that state with the original code to see if one of the issues had really been corrected or just simply "ignored".
Anyways, I have a forked copy of what looks like the current version found at:
https://github.com/mc12345678/Dynamic_Price_Updater
with all of the changes I have made found at:
https://github.com/mc12345678/Dynami...debox-possibly
The changes include a little data sanitization and then action taken to permit "fair play" with other javascript code affecting the product_info page, and I think I have prevented one of the objSB errors related to the sidebox from becoming an issue with a default install, but could still be implemented with an appropriate code change where some additional comment was added to describe what may be necessary to use that feature.
Is it possible to make this work in conjunction with the inc/ex vat mod?
With the VAT mod installed it displays both prices on the product page but adding DPU it replaces that with a single price only.
I know that the price output on the product info page uses get_products_display_price instead of zen_get_products_display_price so I tried changing that in jscript_dynamic_price_updater.php but it didn't work.
I'm assuming that something will need to be coded into the function prepareOutput() found in the class file.
I've seen it working on the product listing pages. I coded this site so I know it can be done.Quote:
Originally Posted by Design75
Go to https://www.liberro.co.uk/electronic...dvanced-vapers and then look at product Aspire Plato All in One Kit. Click the Select Options button and the attributes will pop up. Select the option to add a Mains Charger and you will see the listing price updates after you click the Finished button.
I can't remember how much I had to do on DPU to get it working as that site has had a LOT of customisation to get attributes to display on listings.
Slightly off the DPU topic, but it's so heavily modified that it even displays all products within sub categories on a single page, as can be seen here https://www.liberro.co.uk/ecig-liquid-uk. That took a fair bit of work too!
Hey mc12345678,Quote:
Originally Posted by mc12345678
I tried the latest fork from github: https://github.com/mc12345678/Dynami...debox-possibly
However, the price always shows as $0... Using ZC 1.5.5a - will this work, or is there something extra I need to do?
Thanks,
Chris
How do you have your attributes setup? Product priced by attributes? Sample page of where this issue is occurring? (can obscure the address slightly if wish).Quote:
Originally Posted by clange
Here is an example page:Quote:
Originally Posted by mc12345678
https://tacunasystems.com/zc/index.p...roducts_id=271
However, I've disabled the plugin as the site is live. Maybe I could PM you and enable the plugin so you can see it?
Thanks so much!
Chris
Also, I used the old DPU with 1.5.1 and all was well...Quote:
Originally Posted by mc12345678
Well, a smidge of a template issue...Quote:
Originally Posted by clange
See part of calculating the total cost is to include the quantity of product to be added to the cart. In the case of your current template which is HTML5 styled, the cart_quantity field has been designated as an input type="number". This wasn't previously captured by DPU and therefore, the price would be $0.00 afterall, 0 * any number is well 0. :) I've updated my github distribution to incorporate the input type="number" and it is working on my "test" site, but there may still be some other issue involved after you get the file(s) updated. Effectively you have sort of two dropdowns. One which is the ZC original version, the other is this I guess javascript based (I didn't look far into it yet, because of the other issue needing to be addressed first). It looks like the two operate independently and well after making some modifications to make the original ZC version visible which I believe because it was hidden doesn't have the appropriate events tied to it that neither is really being listened to for the price update, so there is that little bit to overcome... But at least the price wouldn't show as 0.
Again, the way I see it, and if you do still have your "version" from 1.5.1 and you were using this current template, there may still be some value to holding onto the older one and just having to update a few things to further the functionality within the latest ZC...
Quote:
Originally Posted by mc12345678
Ah I see. I updated it and it almost works properly. The price displays but will only update after you fiddle with the quantity. ie. I can select an attribute with +$100, but the price won't change. After I increase the quantity to 2 and back down to 1, the price is correct given the chosen attribute.
mcQuote:
Originally Posted by mc12345678
Do you think it is a simple fix to get the price updater to "listen to" the attribute drop down? It appears to be updating based on quantity changes at the moment. However, the attribute drop down is not creating a price update event...
I'm curious to know if anyone else is experiencing the same problems I am.
zc 1.5.5
dpu 3.0.3
MyDEBUG files show:
[27-Mar-2017 13:11:07 America/Denver]
PHP Warning: reset() expects parameter 1 to be array, null given in /includes/classes/dynamic_price_updater.php on line 175
[27-Mar-2017 13:11:07 America/Denver]
PHP Warning: Variable passed to each() is not an array or object in /includes/classes/dynamic_price_updater.php on line 176
Browser Developer Tool shows:
TypeError: objSB.appendChild is not a function
/includes/modules/pages/product_music_info/jscript_dynamic_price_updater.php #256
Code:function createSB()
{ // create the sidebox for the attributes info display
if (!(document.getElementById('dynamicpriceupdatersidebox')))
{
var tempC = document.createElement('div');
tempC.id = 'dynamicpriceupdatersideboxContent';
tempC.className = 'sideBoxContent';
tempC.innerHTML = 'If you can read this Chrome has broken something';
objSB.appendChild(tempC);
temp.parentNode.insertBefore(objSB, temp);
}
}
Page Bounce
selecting an attribute price causes the ajax-loader.gif to briefly appear forcing text down, then the ajax-loader.gif disappears and text bounces up
Can't speak for version number, but the first is a coding issue that I've worked on and believe I've resolved at least on my test site with code to be uploaded to github and then compared with the most recent ZC push to see how to move forward with the changes of that version. See the sidebox concept was partially incorporated into the code, then some of it was removed, some disabled, and there has been some further development to provide a real sidebox object instead of using javascript to create one, etc... anyways. That aside, if I remember correctly the sequencing of the javascript also was an issue which could lead to the reported problem. Javascript doesn't like to have to guess about an object that is defined after it is used. Big difference compared to how say php let's you used a function that is in a file but defined below the point of use.
The second issue, well there are a number of ways to prevent/address. One is to set aside css space at the location where the image will appear so that when it does appear, nothing else moves. Another is not to show the image when processing/waiting, yet another is to get a smaller image that also doesn't push content.
But it's not really a DPU "problem" per se in my opinion. There is no one size fits all "response" to the action.
Just submitted an updated version (3.0.4) of this plugin to address the following issues.
Will be available from here upon review and posting by a software moderator. Will post when discovered to be uploaded.Quote:
3.0.4 has a few bugfixes as well as general improvements for the overall operation.
- Added data sanitization to the database queries.
- Incorporated full database table names instead of providing some sort of prefix to the anticipated table name.
- Added ZC 1.5.5e ajax.php file for use to take the place of dpu_ajax.php
- Added zcDPU_Ajax class to support AJAX calls.
- Incorporated currency number formatting based on the currency selected in the session instead of with a hard value of 2.
- Converted code to be PHP 7.2 compliant regarding known deprecations.
- Split out the on_load code to its own file.
- Applied parenthesis around actions to be taken for if statements.
- Correct a potential javascript error if secondPrice isn't being used.
- Added ability for image to replace the text to be updated such that there is no line height adjustment.
- Remove the eval function and instead call the function dynamically that is expected.
- Converted single quotes to double quotes.
- Added evaluation of number style fields as an additional option.
- Made monitoring of entered data by event as an added event instead of a replacement event to improve Javascript interactions.
- Removed unnecessary underscore from variables.
- Added semi-colons to end of functions for appropriate Javascript syntax.
- Removed the code from dpu_ajax.php as the code is otherwise incorporated to use the ZC ajax.php file.
- Added tax for display of price with currency symbols.
- Replaced intval() with (int) casting.
- Copied changes from standard product_info to product_music_info.
Version 3.0.4 has been posted and is available here.Quote:
Originally Posted by mc12345678
I'd like to use this with a inline ajax popup.
However, I would need to pass the products_id in a link to the script instead of the script requesting it through the GET method.
Any quick ideas or solutions?
Was busy yesterday coding something ... which tends to result in me having reduced forum/response time.Quote:
Originally Posted by rbarbour
No full blown solution, but in review of the involved code, the current use of $_GET['products_id'] is basically a verification against the page in which that JS code is loaded (product_info related) and is not specifically pertinent to operation. It's sort of an on/off switch because if the page is not one that should have that specific code or if someone is trying to spoof it then it provides at least one check for validity. Others might be able to be performed as well, but long and short of it is that the $_GET is not required for overall operation. Knowing what product is to be used about which to obtain information is necessary and basically the class does look for the $_POST of that information (expected to be a part of the data provided to the class likely by a hidden field within the data to submit as part of your routine).
So basically would want a "tailored" version of the javascript file that is included in includes/modules/pages/product_info for the "routine" that you are using with the suggestion of having some sort of "don't display/use me *if*" checks up front followed by the code to manage processing and display, whatever that may be.
Help any?
I really haven't looked into the code but I will disagree that $_GET['products_id'] is not pertinent to operation. Without the products ID the script doesn't function.Quote:
Originally Posted by mc12345678
I could be wrong.
I don't think an "if" statement is necessary. Maybe another script to pass the id to dpu_ajax.Quote:
Originally Posted by mc12345678
Maybe I should play with this more. :blush:
As written, I would agree with your disagreement about the $_GET being necessary, but the target of the modification/use is not the products_info page so therefore any need for the products_id (which the current code does have such a need up front that likely could be fulfilled by existing code.Quote:
Originally Posted by rbarbour
Mostly will want to attach the existing javascript from this plugin in such a way to listen to the desired "indicators" or selections and to update the applicable price "field" based on the "final" price or other data being collected/displayed. All-in-all there is little that is done by the javascript part found in includes/modules/pages/product_info. It is pretty much a translator of action/data with some initial "do you think it's a good idea to even be presented to the customer checks" at the beginning.
Hi
I am trying to install Dynamic Price Updater onto a fresh 1.5.5 install using a template bought from ThemeForest.
The DPU works fine on the standard ZenCart template but doesn't work on the new ########## template.
I have taken a look at the page and the script is visible.
Please could anyone help? :shocking:Code:<script language="javascript" type="text/javascript">
// <![CDATA[
// Set some global vars
var theFormName = "cart_quantity";
var theForm = false;
var theURL = "/newinstall155/ajax.php";
// var theURL = "/newinstall155/dpu_ajax.php";
var _secondPrice = "cartAdd";
var objSP = false; // please don't adjust this
var DPURequest = [];
// Updater sidebox settings
var objSB = false; // this holds the sidebox object // IE. Left sidebox false should become document.getElementById('leftBoxContainer');
// For right sidebox, this should equal document.getElementById('rightBoxContainer');
// Perhaps this could be added as an additional admin configuration key. The result should end up being that a new SideBox is added
// before whatever is described in this "search". So this may actually need to be a div within the left or right boxes instead of the
// left or right side box.
// May also be that this it is entirely unnecessary to create a sidebox when one could already exist based on the file structure.
var imgLoc = "replace"; // Options are "replace" or , "" (empty)
var loadImg = document.createElement("img");
loadImg.src = "images/ajax-loader.gif";
loadImg.id = "DPULoaderImage";
var loadImgSB = document.createElement("img");
loadImgSB.src = "images/ajax-loader.gif";
loadImgSB.id = "DPULoaderImageSB";
loadImgSB.style.margin = "auto";
// loadImg.style.display = 'none';
function objXHR()
{ // scan the function clicked and act on it using the Ajax interthingy
var url; // URL to send HTTP DPURequests to
var timer; // timer for timing things
var XHR; // XMLHttpDPURequest object
var _responseXML; // holds XML formed responses from the server
var _responseText; // holds any textual response from the server
// var DPURequest = []; // associative array to hold DPURequests to be sent
// DPURequest = new Array();
this.createXHR();
}
objXHR.prototype.createXHR = function () { // this code has been modified from the Apple developers website
this.XHR = false;
// branch for native XMLHttpDPURequest object
if(window.XMLHttpRequest) { // decent, normal, law abiding browsers
try { // make sure the object can be created
this.XHR = new XMLHttpRequest();
} catch(e) { // it can't
this.XHR = false;
}
// branch for IE/Windows ActiveX version
} else if(window.ActiveXObject) { // this does stuff too
var tryNext = false;
try {
this.XHR = new ActiveXObject("Msxml2.XMLHTTP");
} catch(f) {
tryNext = true;
}
if (tryNext) {
try {
this.XHR = new ActiveXObject("Microsoft.XMLHTTP");
} catch(g) {
this.XHR = false;
}
}
}
};
objXHR.prototype.getData = function(strMode, resFunc, _data) { // send a DPURequest to the server in either GET or POST
strMode = (strMode.toLowerCase() == "post" ? "post" : "get");
var _this = this; // scope resolution
this.createXHR();
if (this.XHR) {
this.XHR.onreadystatechange = function () {
if (_this.XHR.readyState == 4) {
// only if "OK"
if (_this.XHR.status == 200) {
_this.responseXML = _this.XHR.responseXML;
_this.responseText = _this.XHR.responseText;
_this.responseHandler(resFunc);
} else {
alert("Status returned - " + _this.XHR.statusText);
}
}
};
this.XHR.open(strMode.toLowerCase(), this.url+"?act=DPU_Ajax&method=dpu_update"+(strMode.toLowerCase() == "get" ? "&" + this.compileRequest() : ""), true);
if (strMode.toLowerCase() == "post") {
this.XHR.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
this.XHR.setRequestHeader("X-Requested-With", "XMLHttpRequest");
}
this.XHR.send(_data);
} else {
var mess = "I couldn't contact the server!\n\nIf you use IE please allow ActiveX objects to run";
alert (mess);
}
};
objXHR.prototype.compileRequest = function () {
// parse the DPURequest array into a URL encoded string
var ret = ""; // return DPURequest string
for (var e in DPURequest) {
ret += e + "=" + DPURequest[e] + "&";
}
return (ret.substr(0, ret.length - 1));
};
objXHR.prototype.responseHandler = function (theFunction) { // redirect responses from the server to the right function
DPURequest = new Array();
this[theFunction](); // Eliminates concern of improper evaluation; however, does limit the response value(s)
};
objXHR.prototype.getPrice = function () {
var psp = false;
if (imgLoc == "replace") {
var thePrice = document.getElementById("productPrices");
var test = thePrice.getElementsByTagName("span");
for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
}
if (psp && imgLoc == "replace") {
if (thePrice) {
loadImg.style.display = "inline"; //'block';
var pspClass = psp.className;
var pspStyle = psp.currentStyle || window.getComputedStyle(psp);
loadImg.style.height = pspStyle.lineHeight; // Maintains the height so that there is not a vertical shift of the content.
psp.innerHTML = loadImg.outerHTML;
}
} else {
document.getElementById("productPrices").appendChild(loadImg);
}
if (document.getElementById("dynamicpriceupdatersidebox")) {
var theSB = document.getElementById("dynamicpriceupdatersideboxContent");
theSB.innerHTML = "";
theSB.style.textAlign = "center";
theSB.appendChild(loadImgSB);
}
this.url = theURL;
var n=theForm.elements.length;
var temp = "";
for (var i=0; i<n; i++) {
var el = theForm.elements[i];
switch (el.type) { case "select":
case "select-one":
case "text":
case "number":
case "hidden":
temp += el.name+"="+encodeURIComponent(el.value)+"&";
break;
case "checkbox":
case "radio":
if (true == el.checked) {
temp += el.name+"="+encodeURIComponent(el.value)+"&";
}
break;
}
}
temp += "pspClass="+encodeURIComponent(pspClass);
//temp = temp.substr(0, temp.length - 1)
this.getData("post", "handlePrice", temp);
};
objXHR.prototype.handlePrice = function () {
var thePrice = document.getElementById("productPrices");
if (loadImg !== undefined && loadImg.parentNode != null && loadImg.parentNode.id == thePrice.id && imgLoc != "replace") {
thePrice.removeChild(loadImg);
}
// use the spans to see if there is a discount occuring up in this here house
var test = thePrice.getElementsByTagName("span");
var psp = false;
for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
var type = this.responseXML.getElementsByTagName("responseType")[0].childNodes[0].nodeValue;
if (document.getElementById("dynamicpriceupdatersidebox")) {
var theSB = document.getElementById("dynamicpriceupdatersideboxContent");
theSB.style.textAlign = "left";
var sbContent = "";
updateSidebox = true;
} else {
updateSidebox = false;
}
if (type == "error") {
this.showErrors();
} else {
var temp = this.responseXML.getElementsByTagName("responseText");
for(var i=0, n=temp.length; i<n; i++) {
var type = temp[i].getAttribute("type");
switch (type) { case "priceTotal":
if (psp) {
psp.innerHTML = temp[i].childNodes[0].nodeValue;
} else {
thePrice.innerHTML = temp[i].childNodes[0].nodeValue;
}
if (_secondPrice !== false) {
this.updSP();
}
break;
case "quantity":
with (temp[i].childNodes[0]) {
if (nodeValue != "") {
if (psp) {
psp.innerHTML += nodeValue;
} else {
thePrice.innerHTML += nodeValue;
}
this.updSP();
}
}
break;
case "weight":
var theWeight = document.getElementById("productWeight");
if (theWeight) {
theWeight.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "sideboxContent":
if (updateSidebox) {
sbContent += temp[i].childNodes[0].nodeValue;
}
break;
}
}
}
if (updateSidebox) {
theSB.innerHTML = sbContent;
}
};
objXHR.prototype.updSP = function () {
// adjust the second price display; create the div if necessary
var flag = false; // error tracking flag
if (_secondPrice !== false) { // second price is active
var centre = document.getElementById("productGeneral");
var temp = document.getElementById("productPrices");
var itemp = document.getElementById(_secondPrice);
if (objSP === false) { // create the second price object
if (!temp || !itemp) {
flag = true;
}
if (!flag) {
objSP = temp.cloneNode(true);
objSP.id = temp.id + "Second";
itemp.parentNode.insertBefore(objSP, itemp.nextSibling);
}
}
objSP.innerHTML = temp.innerHTML;
}
};
objXHR.prototype.createSB = function ()
{ // create the sidebox for the attributes info display
if (!(document.getElementById("dynamicpriceupdatersidebox")) && objSB)
{
var tempC = document.createElement("div");
tempC.id = "dynamicpriceupdatersideboxContent";
tempC.className = "sideBoxContent";
tempC.innerHTML = "If you can read this Chrome has broken something";
objSB.appendChild(tempC);
temp.parentNode.insertBefore(objSB, temp);
}
};
objXHR.prototype.showErrors = function () {
var errorText = this.responseXML.getElementsByTagName("responseText");
var alertText = "";
var n=errorText.length;
for (var i=0; i<n; i++) {
alertText += "\n- "+errorText[i].childNodes[0].nodeValue;
}
alert ("Error! Message reads:\n\n"+alertText);
};
var xhr = new objXHR;
function init() {
var n=document.forms.length;
for (var i=0; i<n; i++) {
if (document.forms[i].name == theFormName) {
theForm = document.forms[i];
continue;
}
}
var n=theForm.elements.length;
for (var i=0; i<n; i++) {
switch (theForm.elements[i].type) {
case "select":
case "select-one":
theForm.elements[i].addEventListener("change", function () { xhr.getPrice(); });
break;
case "text":
theForm.elements[i].addEventListener("keyup", function () { xhr.getPrice(); });
break;
case "checkbox":
case "radio":
theForm.elements[i].addEventListener("click", function () { xhr.getPrice(); });
break;
case "number":
theForm.elements[i].addEventListener("change", function () { xhr.getPrice(); });
theForm.elements[i].addEventListener("keyup", function () { xhr.getPrice(); });
theForm.elements[i].addEventListener("input", function () { xhr.getPrice(); });
break;
}
}
this.createSB();
xhr.getPrice();
};
// ]]></script>
When dealing with javascript, it is important to first verify that the template passes an html validation. Errors in the that validation may prevent firing of the javascript, also, other javascript may interact/override the actions that are being waited on which can depend on load sequence of the javascript (for example the code here has been modified to also listen for the change of attribute selections instead of replacing any previous/other listening operations), then also it is good to watch execution of javascript through your browser to see what is going on, if there are any console errors, etc... This last thing can be done through pressing F12 while using your browser with the suggestion to reload the page after doing that.
Otherwise, for others to help the web page would need to be provided so that they can do the same or similar actions as described.
Hi i checked and there no errors but 26 warnings. Mainly sloppy coding and unclosed <p> tags etc
Curious... If in your current implementation, if you remove the check of the $_GET from the javascript code, does everything still work when using your inline type ajax? Meaning, does the code fire, or does it still not "work"? Wondering if there is a separate issue (and possible/likely solution) than just the initial call to display the page? Like maybe an update on the page needs to be performed? and/or maybe to display the value of the $_GET on the page load just to see if there is a difference between the two methods of accessing the page? (zen_get_all_get_parameters() should provide/retrieve all of the values set at that time/page and could be briefly added to say the tpl_product_info_display_default.php). Afterall, the $_GET parameter has to be set/available in order for the particular content to be gathered/displayed in the first place...Quote:
Originally Posted by mc12345678
Hmm.. Sorry, feel like speaking in a circle... But the "output" would at least confirm/reaffirm the concerns/situation. I'm leaning more towards the need to fire a specific javascript event or to parse the javascript/ajax or something as part of displaying the object.
Well, first suggestion would be to try to close those things up properly to have none, the other would be to review how the code of the template differs from that of a standard ZC install and see if either there are files that are not loaded or some other sequencing issue that could maybe interfere with the standard ZC load/execution sequence. Then to also look at what/how other javascript is loaded. Not much made available with which I can help otherwise.Quote:
Originally Posted by dharrison
Not sure how quick the solution/idea came, but a specific solution was identified to support this request and it seemed to jive with the above/previous discussion.Quote:
Originally Posted by rbarbour
In the end, the javascript/jquery code that was being used included an ajax call/function. Primarily it allows display of the content at a link's destination within a window. But, for this particular module, in order to "properly" fire it off, the dpu code had to be called/activated in order to process. Basically, one way for DPU to work within this popup was to call/process the content of the includes/modules/pages/YOUR_PAGE/on_load_dpu.js file after the ajax work of the javascript/jquery program successfully completed.
So the answer is yes it can be used for the most part as is but integrated into other code as that code needs...
@mc12345678Quote:
Originally Posted by mc12345678
Thanks for the quick response and solution provided. I will try it later today on my test site. I really appreciate the time spent looking into this and will certainly send a few cups of coffee your way.
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.Quote:
Originally Posted by rbarbour
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". :)Quote:
Originally Posted by rbarbour
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?Quote:
Originally Posted by MichaelT
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.
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_STATUSQuote:
Originally Posted by MichaelT
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.Quote:
Originally Posted by mc12345678
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.phpQuote:
Originally Posted by MichaelT
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 :Quote:
Originally Posted by mc12345678
-----------------------------------
<?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
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 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.Quote:
Originally Posted by mc12345678
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.Quote:
Originally Posted by MichaelT
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:
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.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';
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.)
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.Quote:
Originally Posted by MichaelT
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.Quote:
Originally Posted by mc12345678
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:
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.Quote:
Originally Posted by dharrison
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.
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.Quote:
Originally Posted by dharrison
Hi mc
I have just included the VAT again.
If I use http://sitstandforbusiness.com/ssfbt...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
I have also added the Dynamic Price Updater sidebox on teh right hand side, and the pricing here reads correctly.
Looks like a perceived improvement was unnecessary...Quote:
Originally Posted by dharrison
The following should restore the operation:
in includes/classes/dynamic_price_updater.php
line 116, change:
BACK To:Code:$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, zen_get_tax_rate($product_check->fields['products_tax_class_id'])/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);
Deleting the additional tax calculation/determination. Seeing that the shopping cart class already determines the price based on tax included/excluded, there is no need to do a further calculation here.Code:$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, 0/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);
This will be again incorporated back into the upcoming change that I have been preparing to use the ZC zcJS variable (when available), and to provide an improved installer so that issues like previously seen are less likely to occur. :)
Currently what is seen is that on page load a price is displayed, upon change of attribute (triggering the price adjustment), the displayed price becomes adjusted as if the displayed price needed to have the tax rate applied to it (again)... Thank you for your testing, the values and explanation of what was going wrong.
Yayyyy it works :clap:
I'm always glad to help on the very odd occasions that I do.
Thank you
I think what happened was that I was going to add more return data so that both the price with and price without tax could be returned as separate values and got sidetracked... Even trying to look at it now, it seems I would have to do a "reverse" calculation for cases where the store is set to display the price with tax and the without tax price was desired, because the function to "add" tax does not accept a negative number and at the point of return of data to the class, the shopping cart has already done all its math with the tax included in the final price and no "intermediate" or untaxed value is returned. I.e. other method is to do like what is done in the sidebox of running all of the numbers in the code. Prefer re-usability over maintaining additional/duplicate code, but... Alternatively the incl VAT/Excl VAT code includes some features for this, so could detect and reuse that code as necessary adding a potential dependency.Quote:
Originally Posted by dharrison
*shaking head* okay enough about that, thank you for noting the issue and providing the explanation(s). Once I had a "final" price, original price and an idea of what the VAT percentage was and looking at the code, it became quite obvious what was going on.
Hi is there a way to add a suffix after the price? Because we're displaying the price including & excluding VAT, we need to make sure that the customer knows the price is ex VAT
There is, but seems to me that with the incl/exc VAT program installed that there are quite a few options available, things to set and a few modifications to make such as modifying the information to be displayed at the product info page to have/contain the suffix related to the price being displayed and that is contained in its own span.Quote:
Originally Posted by dharrison
Basically, the suffix (like the prefix) information (right or wrong) is located in the includes/classes/dynamic_price_updater.php file within the prepareOutput function. A suffix would logically follow after the assignment/line I suggested changing above.
Ok the updated price once an attribute is selected does not display whether the price is including or ex VAT. As we cater to both trade and customer, this makes a big difference (especially at 20%)
I see where to add the suffix, but (and yes I am a newbie when it comes to javascript) what do I add: I tried document.write() and this didn't work
Please help :)
Sorry I had a blonde moment. This is PHP :bangin:
But in my defence <?php echo ?> doesn't appear to work
To be sure that we're going down the right path: on initial display of the price, the price value as well as a "suffix" are presented, correct? Isn't the price value in its own span class as compared to the suffix?Quote:
Originally Posted by dharrison
If so, it sounds like maybe the javascript portion is replacing "too much" text. I don't recall the class name even though I was adding functionality to the plugin yesterday to specifically address that plugin, but it includes text something like "...IncExc..." for the case where it is the "opposite" tax display, and a different class for the one that is the "normal" final display. If there are two spans displayed, one to show the price, one to show the text of what the price represents, then the file to change is in the includes/modules/pages/YOUR_PRODUCT_TYPE/ folder in the jscript_ file and the handlePrice function to capture the location to be updated as the variable psp.
If there is only one such class at the product price display then yes need to go back to the class file which is a php file not a javascript file. By that I mean, the responseText would be updated to append the suffix through standard php methods of appending text.
I believe you provided a link to one of your products, so will take a look soon and be able to further advise, but wanted to express what seemed to be expected as compared to what was asked.
Welcome to AJAX. :) as stated in my last post, the suffix if added to the class file, would be appended to the responseText of the priceTotal key similar to the line modified in the correction posted before.Quote:
Originally Posted by dharrison
Yes just a suffix on the second price that reminds the visitor that the price given is "ex VAT"
I'll give my recommended code to add the suffix into the class file in a moment, but it appears that the inc_ex_functions file in includes/functions/extra_functions is missing a span tag in one place as seen by your website and then review of that code as downloaded a while back from zc. There is a line in that function file starting withQuote:
Originally Posted by dharrison
The right side of that "equation" should be encompassed by a span of class normalPrice or similar it looks like.Code:$show_normal_price=display_price(
On line 110? I have corrected that
So here are the changes I recommend to support the inc/excl VAT module.Quote:
Originally Posted by mc12345678
First, update the includes/functions/extra_functions/inc_ex_functions.php file to change this:
Around line 112 to this (in red):Code:if ($product_check->fields['product_is_free']=='1')
$show_normal_price='<s>'.display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])).'</s>';
else
$show_normal_price=display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id']));
Then in includes/modules/pages/product_info/jscript_dynamic_price_updater.php:Code:if ($product_check->fields['product_is_free']=='1')
$show_normal_price='<s>'.display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])).'</s>';
else
$show_normal_price='<span class="normalprice">'.display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])).'</span>';
At and around line 222:
Add: a check for the className normalprice and a check for the "alternate tax" display possibilities:Code:for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
Then below that beginning at line 243:Code:var pspInclEx = false;
var pspEx = false;
var pspIncl = false;
for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "normalprice" || test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
if (test[a].className == "productIncExTaxPrice") {
pspInclEx = test[a];
}
if (test[a].className == "productTaxExPrice") {
pspEx = test[a];
}
if (test[a].className == "productTaxPrice") {
pspIncl = test[a];
}
Insert additional cases of "priceTotalInclTax", "priceTotalExcTax", and "priceTotalIncExcTax" to support the various classes that the plugin uses.Code:switch (type) {<?php // the 'type' attribute defines what type of information is being provided ?>
case "priceTotal":
if (psp) {
psp.innerHTML = temp[i].childNodes[0].nodeValue;
} else {
thePrice.innerHTML = temp[i].childNodes[0].nodeValue;
}
if (_secondPrice !== false) {
this.updSP();
}
break;
case "quantity":
with (temp[i].childNodes[0]) {
if (nodeValue != "") {
if (psp) {
psp.innerHTML += nodeValue;
} else {
thePrice.innerHTML += nodeValue;
}
this.updSP();
}
}
break;
Then in includes/classes/dynamic_price_updater.php within the prepareOutput function modifying (for now) the area in blue below (a similar modification will be incorporated for when not showing the currency symbols, but first am trying to get through with when they are displayed):Code:switch (type) {<?php // the 'type' attribute defines what type of information is being provided ?>
case "priceTotal":
if (psp) {
psp.innerHTML = temp[i].childNodes[0].nodeValue;
} else {
thePrice.innerHTML = temp[i].childNodes[0].nodeValue;
}
if (_secondPrice !== false) {
this.updSP();
}
break;
case "priceTotalInclTax":
if (pspIncl) {
pspIncl.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "priceTotalExcTax":
if (pspEx) {
pspEx.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "priceTotalInclExcTax":
if (pspInclEx) {
pspInclEx.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "quantity":
with (temp[i].childNodes[0]) {
if (nodeValue != "") {
if (psp) {
psp.innerHTML += nodeValue;
} else {
thePrice.innerHTML += nodeValue;
}
this.updSP();
}
}
break;
Incorporate the following (in red, the "blue" line remains unchanged):Code:if (DPU_SHOW_CURRENCY_SYMBOLS == 'false') {
$decimal_places = $currencies->get_decimal_places($_SESSION['currency']);
$this->responseText['priceTotal'] .= number_format($this->shoppingCart->total, $decimal_places);
} else {
$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, zen_get_tax_rate($product_check->fields['products_tax_class_id'])/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);
}
I may add a "switch" to the jscript file to detect if the incl/exc VAT plugin is installed/enabled/active, but need to identify what would trigger that "knowledge". Otherwise, for non-users of that code, additional javascript is sent to a browser and possibly a little processing speed/time by calculating the opposite price of what the store is showing on page load/attribute change with no other ill effect(s) by this change.Code:if (DPU_SHOW_CURRENCY_SYMBOLS == 'false') {
$decimal_places = $currencies->get_decimal_places($_SESSION['currency']);
$this->responseText['priceTotal'] .= number_format($this->shoppingCart->total, $decimal_places);
} else {
$product_tax_class_id = zen_products_lookup((int)$_POST['products_id'], 'products_tax_class_id');
$tax_rate = zen_get_tax_rate($product_tax_class_id); // Rate comes back as a "whole number" such as 20% returns 20 and NOT 0.20
if (DISPLAY_PRICE_WITH_TAX != 'false') {
$price_without_tax = 100.0 * $this->shoppingCart->total / ($tax_rate + 100.0); // Price of product without tax
$this->responseText['priceTotalInclExcTax'] = $this->responseText['priceTotal'] . $currencies->display_price($price_without_tax, 0);
$this->responseText['priceTotalExcTax'] = $currencies->display_price($price_without_tax, 0);
} else {
$this->responseText['priceTotalInclExcTax'] = $this->responseText['priceTotal'] . $currencies->display_price($this->shoppingCart->total + zen_calculate_tax($this->shoppingCart->total, $tax_rate), 0);
$this->responseText['priceTotalInclTax'] = $currencies->display_price($this->shoppingCart->total + zen_calculate_tax($this->shoppingCart->total , $tax_rate), 0);
}
$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, 0)/* 0 */ /* DISPLAY_PRICE_WITH_TAX */;
}
If I am correct, line 10 didn't have a class assigned and just had a strike through <s>. Generally speaking, that is as expected because there would/should be some other class that follows and would be replaced with an applicable price to update. It would be two lines down where there is no "html" surrounding the price value(s). It appears to be causing on your product info page for the "base price" to not be uniquely surrounded by a span that can be "tagged" and therefore the entire content is being replaced not just the applicable price(s).Quote:
Originally Posted by dharrison
BTW, feedback on the above modification would be greatly appreciated as I have it staged (locally) to be posted to github and to ZC for incorporation. Would like to get it as close to fully operational as possible.
Hi
Ok will do.
I did this and as a result the including VAT price now has a strikethroughQuote:
Around line 112 to this (in red):
Code:if ($product_check->fields['product_is_free']=='1')
$show_normal_price='<s>'.display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])).'</s>';
else
$show_normal_price='<span class="normalprice">'.display_price($display_normal_price, zen_get_tax_rate($product_check->fields['products_tax_class_id'])).'</span>';
Attachment 17049
This stopped the Price Updater workingQuote:
Then in includes/modules/pages/product_info/jscript_dynamic_price_updater.php:
At and around line 222:
Code:for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
Add: a check for the className normalprice and a check for the "alternate tax" display possibilities:
Then below that beginning at line 243:Code:var pspInclEx = false;
var pspEx = false;
var pspIncl = false;
for (var a=0,b=test.length; a<b; a++) {
if (test[a].className == "normalprice" || test[a].className == "productSpecialPrice" || test[a].className == "productSalePrice" || test[a].className == "productSpecialPriceSale") {
psp = test[a];
}
}
if (test[a].className == "productIncExTaxPrice") {
pspInclEx = test[a];
}
if (test[a].className == "productTaxExPrice") {
pspEx = test[a];
}
if (test[a].className == "productTaxPrice") {
pspIncl = test[a];
}
Insert additional cases of "priceTotalInclTax", "priceTotalExcTax", and "priceTotalIncExcTax" to support the various classes that the plugin uses.Code:switch (type) {<?php // the 'type' attribute defines what type of information is being provided ?>
case "priceTotal":
if (psp) {
psp.innerHTML = temp[i].childNodes[0].nodeValue;
} else {
thePrice.innerHTML = temp[i].childNodes[0].nodeValue;
}
if (_secondPrice !== false) {
this.updSP();
}
break;
case "quantity":
with (temp[i].childNodes[0]) {
if (nodeValue != "") {
if (psp) {
psp.innerHTML += nodeValue;
} else {
thePrice.innerHTML += nodeValue;
}
this.updSP();
}
}
break;
Code:switch (type) {<?php // the 'type' attribute defines what type of information is being provided ?>
case "priceTotal":
if (psp) {
psp.innerHTML = temp[i].childNodes[0].nodeValue;
} else {
thePrice.innerHTML = temp[i].childNodes[0].nodeValue;
}
if (_secondPrice !== false) {
this.updSP();
}
break;
case "priceTotalInclTax":
if (pspIncl) {
pspIncl.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "priceTotalExcTax":
if (pspEx) {
pspEx.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "priceTotalInclExcTax":
if (pspInclEx) {
pspInclEx.innerHTML = temp[i].childNodes[0].nodeValue;
}
break;
case "quantity":
with (temp[i].childNodes[0]) {
if (nodeValue != "") {
if (psp) {
psp.innerHTML += nodeValue;
} else {
thePrice.innerHTML += nodeValue;
}
this.updSP();
}
}
break;
The DPU doesn't work at the moment. I have followed your instructions clearly twice now with the same result.Quote:
Then in includes/classes/dynamic_price_updater.php within the prepareOutput function modifying (for now) the area in blue below (a similar modification will be incorporated for when not showing the currency symbols, but first am trying to get through with when they are displayed):
Incorporate the following (in red, the "blue" line remains unchanged):Code:if (DPU_SHOW_CURRENCY_SYMBOLS == 'false') {
$decimal_places = $currencies->get_decimal_places($_SESSION['currency']);
$this->responseText['priceTotal'] .= number_format($this->shoppingCart->total, $decimal_places);
} else {
$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, zen_get_tax_rate($product_check->fields['products_tax_class_id'])/* 0 */ /* DISPLAY_PRICE_WITH_TAX */);
}
I may add a "switch" to the jscript file to detect if the incl/exc VAT plugin is installed/enabled/active, but need to identify what would trigger that "knowledge". Otherwise, for non-users of that code, additional javascript is sent to a browser and possibly a little processing speed/time by calculating the opposite price of what the store is showing on page load/attribute change with no other ill effect(s) by this change.Code:if (DPU_SHOW_CURRENCY_SYMBOLS == 'false') {
$decimal_places = $currencies->get_decimal_places($_SESSION['currency']);
$this->responseText['priceTotal'] .= number_format($this->shoppingCart->total, $decimal_places);
} else {
$product_tax_class_id = zen_products_lookup((int)$_POST['products_id'], 'products_tax_class_id');
$tax_rate = zen_get_tax_rate($product_tax_class_id); // Rate comes back as a "whole number" such as 20% returns 20 and NOT 0.20
if (DISPLAY_PRICE_WITH_TAX != 'false') {
$price_without_tax = 100.0 * $this->shoppingCart->total / ($tax_rate + 100.0); // Price of product without tax
$this->responseText['priceTotalInclExcTax'] = $this->responseText['priceTotal'] . $currencies->display_price($price_without_tax, 0);
$this->responseText['priceTotalExcTax'] = $currencies->display_price($price_without_tax, 0);
} else {
$this->responseText['priceTotalInclExcTax'] = $this->responseText['priceTotal'] . $currencies->display_price($this->shoppingCart->total + zen_calculate_tax($this->shoppingCart->total, $tax_rate), 0);
$this->responseText['priceTotalInclTax'] = $currencies->display_price($this->shoppingCart->total + zen_calculate_tax($this->shoppingCart->total , $tax_rate), 0);
}
$this->responseText['priceTotal'] .= $currencies->display_price($this->shoppingCart->total, 0)/* 0 */ /* DISPLAY_PRICE_WITH_TAX */;
}
Quote:
Originally Posted by mc12345678
It seems that there are other changes that have been made unrelated to the above suggestions to support continued display of both included and excluded taxes. Possibly something modified in the includes/classes/dynamic_price_updater.php file? Or more likely based on system response, the includes/configure.php file has been modified for this sub-directory store, because from the above link, clicking on anything there takes one to the "live" store instead of remaining in the temporary store.Quote:
Originally Posted by dharrison
I've "externally" checked what is presented at the provided link and while initially the page loads just fine, all of the links point to the main directory not to the "temporary" directory that appears to have been created. This then causes thing like the ajax to fail because it look like there is a cross browser type situation occurring. When the default sub-directory is removed, then the site loads, and as of just now, DPU is working as it originally was recently provided, but without edits suggested above being visible. So, it seems that the primary issue over the last few days related to the provided link is that it did not direct/redirect to a properly formed/generated site, therefore any other issues at that point were unrelated to DPU.
As to the line through with the normalprice class, yeah I can see how the use of that class is already designated to format with a line-through (the normalprice class is used when the normal price is displayed and some other price is present such as a special or a sale). Not using a class of some type in that area causes the overall price swap to fail/cause what is being seen of the entire "block" being replaced. Perhaps use of normalInclExcPrice as the class to be used to support swapping could work. That way at least the price is editable without a lot of text manipulation or substitution. It somewhat depends on what is desired/necessary. I have installed a version of the includes/excludes VAT price module and have been working on a solution that does not require an additional incl/exc VAT function with the current result being that on change of the attribute, both the included and excluded VAT price are shown, but the sale, special, etc.. price has been replaced as well thus far in testing. It would be nice to just replace the necessary values, which in part I have been able to do, but further ideally would be for this plugin to be provided to operate as normal without any subsequent changes and to also operate "as normal" with the incl/exc VAT plugin such that again no code changes to DPU would be necessary. It does look like though that the incl/exc VAT plugin could use a few tweaks to support being installed, to have the necessary switch adjustments to affect display, but to also be "disabled" without having to be removed. I believe countrycharm had at one point posted a slightly updated version, but even that could use a few modifications to accomplish the installed but not adding to the returned text.
@dharrison - is just me or does the zenID also appear for you on every link?
To prevent that:
Admin -> Configuration -> Sessions
Cookie Domain
Force Cookie Use
- make sure they both say True
Also, you have some links in the HTML HEADER using "http://" links instead of "https://" which is causing my Browser to give Warning msgs.
I have noticed that the config setting DPU_SHOW_LOADING_IMAGE (true to show a small loading graphic so the user knows something is happening) is misleading as if you set it to false the whole functionality is not loading anymore. There is no image loading but no price change as well :-) If the graphic is needed it would be better to remove this setting. If the graphic is not needed something must be wrong in thesections.Code:<?php if (DPU_SHOW_LOADING_IMAGE == 'true') { ?>
Danke, webchills,Quote:
Originally Posted by webchills
Have confirmed the same lack of response when set to false, looking into the why and how to resolve.
See commits:Quote:
Originally Posted by webchills
(includes/modules/pages/product_info)
https://github.com/mc12345678/Dynami...f6e0dc82d089b9
and:
(includes/modules/pages/product_music_info)
https://github.com/mc12345678/Dynami...d9c1ae60d810dc
For resolution.
Files affected are the jscript_dynamic_price_updater.php file for each of the pages (similar to be applied to any other page where the jscript_dynamic_price_updater.php file has been placed.
Thanks for the speedy fixes. Working like a charm now. And thanks for taking care of this plugin, it came a long way since Chrome invented the first version...
Hi mc
Thanks for the advice ref the ZenID. I have set this properly now.
How can I add a suffix to the 2nd price?
Just to pinpoint, this is the price which shows below the add cart button at https://sitstandforbusiness.com/heig...dule-p-29.html
Unable to access your site at the moment to identify the details of what is going on; however, if all that is needed is to add something at the end of the text, then this could be done within the includes/modules/pages/product_info/jscript_dynamic_price_updater.php file within the objXHR.prototype.updSP = function () { section such as:Quote:
Originally Posted by dharrison
The content between the double quotes could be php provided to depend on settings of the store or to use a constant that is language dependent for example.Code:if (objSP === false) { // create the second price object
if (!temp || !itemp) {
flag = true;
}
if (!flag) {
objSP = temp.cloneNode(true);
objSP.id = temp.id + "Second";
itemp.parentNode.insertBefore(objSP, itemp.nextSibling);
}
}
objSP.innerHTML = temp.innerHTML + " suffix";
If the suffix is to be added elsewhere within the content, then some additional javascript or other php could/would be used to split out temp.innerHTML to the desired parts in order to insert the associated text.Code:objSP.innerHTML = temp.innerHTML + " <?php if ($condition) { echo CONSTANT;} else { echo CONSTANT2; } ?>";
This area was chosen because the updSP (Second price location) is not presented until one of the attributes has been changed and that text is dependent on/reflects the content of the primary price display.
Thanks. The first method worked.
Glad that worked.Quote:
Originally Posted by dharrison
The "second" method is intended to support multiple languages and demonstrates a simple if/then/else comparison or operation, but requires at least one define to be added into the includes/languages file structure such as either at the base language file includes/languages/YOUR_LANGUAGE.php (overrideable at includes/languages/YOUR_TEMPLATE/YOUR_LANGUAGE.php) or the applicable product type (also overrideable) as in includes/languages/YOUR_LANGUAGE/product_info.php or preferably includes/languages/YOUR_LANGUAGE/YOUR_TEMPLATE/product_info.php for example. If placed in the individual product type file, then it would need to be duplicated across product types used on the site; however, by being placed in the probably more preferred overridden main language file, then it is entered once and applied across all product types that may be used in the store.
The define(s) would be similar to:
Code:define('CONSTANT', 'suffix text');
define('CONSTANT2', 'other suffix text');
Apologies for the late notification.
Last weekend, I uploaded an updated copy of DPU for review; however, in true fashion shortly after doing so I discovered a couple of issues when I attempted to use the features from a specific mobile device which ultimately was a result of using a default value in a parameter within the javascript code. By review of javascript discussions, this shouldn't have been a problem, but it would seem that the particular device wasn't playing by "today's" standards, so a resolution to that has been created. Also, in rewriting a portion of the dpu class code, I had not taken into account changes that would be needed for the provided/included sidebox. Also, the newly included installer includes a check for updated versions; however, it also expects the ability to disable version checking which was not included in the installer sql.
Anyways, all of that said, I am working on the instruction to address the updates/modifications most of which are available currently from github: https://github.com/mc12345678/Dynamic_Price_Updater
So stay tuned for version 3.0.6, I would like to have it pushed to the forum for review over the weekend, other projects pending.
Available here.Quote:
Version 3.0.5:
- Improved installation/installer
- Previous process for installation included a delete of previous settings. This is now performed using insert ignore style sql and as necessary to update settings with a focus of configuration sort order.
- Rewrote the data collection about a product to improve ability to compare to the active cart.
- If using the class function of insertProducts, the resulting prid is an integer only and does not include the possibility of addressing attributes based on the change(s) made here. This is equivalent to a standard product being listed in the product listing screen being added to the cart where attributes are "typically" not selectable.
- Modified quantity reporting to provide quantity already in cart for selected attributes if the quantity is greater than zero.
- Incorporated forum correction for operation when DPU_SHOW_LOADING_IMAGE is set to false.
- Added JSON response information when retrieving results.
- Incorporated the use of Zen Cart's provided zcJS when it is available.
- Made the DPU class part of the overall system to better support additional observers as needed.
- Maintained the "default" XML response if JSON is not requested to align with potential historical alterations.
- Added the restoration of the price display if the transaction fails.
- Added jscript function to perform data/screen update/swap.
Submitted v3.0.6, awaiting review. When posted should be available from here: https://www.zen-cart.com/downloads.php?do=file&id=1301
Description provided:
Anyone that has fully installed version 3.0.5 should be notified through their admin when version 3.0.6 is made available for download.Quote:
3.0.6:
- Modified/updated the class information to provide the sidebox data.
- Correct additional javascript errors to prevent having to catch them.
- Modified sidebox to not display/be active if the page's javascript for dpu is not active.
- Added additional type casting to force data to the expected type.
- Incorporate the tax calculation correction posted in the forum into the code.
- Removed the use of default parameters because some browsers do/did not support it.
- Add separate control for update checking of this plugin.
- Updated installer version check to ZC 1.5.5e version.
- Corrected installer code to validate new version exists.
Version 3.0.6 has been posted for download; however, there were a few additional things discovered that are addressed in version 3.0.7 (also on github):Quote:
Originally Posted by mc12345678
Only the dpu class file was modified in version 3.0.7 as compared to 3.0.6 and the addition of the installer "version" file.Quote:
3.0.7, What changed:
- Corrected issue that price of product without attributes was not incorporated/considered because
the dpu javascript code basically prevented overwriting the price until corrections were made
in version 3.0.6 that would automatically rewrite the current price display based on what
dpu determined based on the product. (This additional feature was added to support display of
the appropriate information when returning to the product from the shopping cart.)
- Because the price is automatically calculated based on arriving at a product, if a product is
priced by attributes and not all of the "mandatory" attributes are selected then the price
was only showing the price point of those that were selected. The code now calculates the
lowest available price based on the selections already made. The displayed text has not been
edited to account for this "feature" yet, but could be modified to support the condition.
When the software review team has made it through the review and posting of the update it should be available here: https://www.zen-cart.com/downloads.php?do=file&id=1301
Welcome further feedback/suggestions of how these additional features/calculations are presented. See at least one place where an additional notifier could maybe add some functionality to the code.
Good morning at all, I can not change the decimals ie I would like the decimal ones to be a spin instead of a point, and miles a point instead of a comma.
In the currency the comma is set to the decimal then it is not zen cart the problem but dpu. Thank you for the reply.
Ps
I installed version 3.07
What is your setting for: Show currency symbols?Quote:
Originally Posted by diamond1
If it is true, then all currency related values should be reflected when displaying a price (i.e. a number such as 3000 with a fraction of 1/2 would be displayed as 3.000,5 when using a decimal for the thousands place and a comma (spin) for the part of a number, or if a comma (spin) for the thousands place and a period for the part of a whole it would be 3,000.5).
As to other "units" such as miles/km, DPU should return whatever has been entered. If there is some other "special" conversion to be performed based on what attribute is being addressed then this conversion/handling would need to be incorporated into the includes/classes/dynamic_price_updater.php file. To address this in the sidebox (only place that updates with a specific attribute's option "name" or value "name"), then would suggest that if modifying the displayed attribute that it be handled in the function getSideboxContent with further suggestion of addressing in this "area"
At/after this last line ($name = ...) would evaluate the options_id ($option) and options_values_id ($value) to see if either/both should be the one(s) to be manipulated to display an alternate series of comma (spin) and period... Ie. if the option name is miles and has an option_id of 27 and all available option values are numbers, then:Code:if (is_array($this->shoppingCart->contents[$products[$i]['id']]['attributes'])) {
// while (isset($this->shoppingCart->contents[$_POST['products_id']]['attributes']) && list($option, $value) = each($this->shoppingCart->contents[$_POST['products_id']]['attributes'])) {
foreach ($this->shoppingCart->contents[$products[$i]['id']]['attributes'] as $option => $value) {
$adjust_downloads ++;
$attribute_price = $db->Execute("SELECT *
FROM " . TABLE_PRODUCTS_ATTRIBUTES . "
WHERE products_id = '" . (int)$prid . "'
AND options_id = '" . (int)$option . "'
AND options_values_id = '" . (int)$value . "'");
$data = $db->Execute("SELECT products_options_values_name
FROM " . TABLE_PRODUCTS_OPTIONS_VALUES . "
WHERE products_options_values_id = " . (int)$value);
$name = $data->fields['products_options_values_name'];
Otherwise I am not sure what you mean by the usage of miles in this context because the values presented/calculated by DPU are the cost factors and not some "unit". Such "comparison" or use of units would be or have been a modification to the core coding of ZC.Code:if ((int)$option == 27) {
$name = /* function or code to convert the previous value of $name to use the new units */;
}
I guess it could also be possible that a "cost" could be displayed with specific units/decimals by use of the php function number_format described in the php manual here as applicable.
But would need more information to provide further guidance/assistance.
Titre : Euro
Code: EUR
Symbole à gauche :
Symbole à droite : €
Point décimal : ,
Séparateur des milliers : .
Nombre de décimales : 2
It's all set up as it should, without DPU everything works the prices are 3.000,50 €
With DPU the price becomes 3,000.50
Sorry, I should have been clearer:Quote:
Originally Posted by diamond1
What is your setting for: Show currency symbols?
As found on the admin->configuration->Dynamic Price Updater window.
Based on your report it sounds like it is set to false and should be set to true.
Thanks you were right I have to enable the currency to change the comma to point, although it does not make sense but you helped me solve this thanks again
I was also wondering why the code had an option to return the value without using currency symbols but then realized that the javascript that processes the response can be altered and it may be that one needs to not have currency symbols and that they would add them in.Quote:
Originally Posted by diamond1
Anyways, glad that the issue is resolved.
If i would like to modify it by javascript what would be the change and where?