Jump to content

boran

Members
  • Posts

    46
  • Joined

  • Last visited

Everything posted by boran

  1. Well the third comment indicates one immediate fix to modules/mailalerts/mailalerts.php. The fourth indicates that total_discounts, total_shipping, total_wrapping are probably also wrong, and asks why different formulas are used to calculate the totals?. I was trying to understand the reasons behind the current code. Should total_products not be calculated in exactly the same way in mailalerts.php and PaymentModule.php (i.e. the quote line in comment 4 for PaymentModule.php should be replaced with the one from mailalerts.php). Sean
  2. Looking at classes/PaymentModule.php confirms the above issue, in that file, which generates the 'Order Confirmation' sent to the customer, the relevant lines are as follows (note the last two false parameters meaning no conversion): '{total_paid}' => Tools::displayPrice($order->total_paid, $currency, false, false),^M '{total_products}' => Tools::displayPrice($order->total_paid - $order->total_shipping - $order->total_wrapping+ $order->total_discounts, $currency, false, false),^M This, then begs the question as to why the code is duplicated, and in this case different, between classes/PaymentModule.php and modules/mailalerts/mailalerts.php. With the 'Order Confirmation' and 'New Order' emails in two different classes they have to be maintained/corrected in parallel, which will lead to future inconsistencies? Reviewing the differences would indicate that total_discounts, total_shipping, total_wrapping also need to be corrected in the same way. Looking at the total_products the calculation in done differently in each case. modules/mailalerts/mailalerts.php: '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency, false), classes/PaymentModule.php '{total_products}' => Tools::displayPrice($order->total_paid - $order->total_shipping - $order->total_wrapping+ $order->total_discounts, $currency, false, false), getTotalProductsWithTaxes() is in classes/Order.php and does the quantity*price+tax for each item, so its what a product should cost. Does this difference make sense? The logical for calulating totals should only be in one place, probably in the Order class?
  3. As I work more and more with PS, I keep coming back to the debugging issue, and feel it should be possible to keep debug code and enabled when needed. Anyway, I was digging for a way to tie in FirePHP very simply in any class I needed. Trying the OO didn't work to well, but this did: in config/config.inc.php, add include_once(dirname(__FILE__) .'/../FirePHPCore/fb.php'); extract FirePHPCore into the shop root. And from any line a module (for example), add a debug print like this
  4. I think I've found one issue, in modules/mailalerts/mailalerts.php In hookNewOrder(), when building $itemsTable, Tools::displayPrice() is called with a "false" paramter not to do conversion Whereas the totals are converted: '{total_paid}' => Tools::displayPrice($order->total_paid, $currency),^M '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency) So I changed those lines to: '{total_paid}' => Tools::displayPrice($order->total_paid, $currency, false, false),^M '{total_products}' => Tools::displayPrice($order->getTotalProductsWithTaxes(), $currency, false, false), This is a tentative fix, the total products line in the confirmation email seem correct. I'm not sure though, could someone with PS experience please confirm?
  5. Hi, I think that directory like /modules and /classes should have only code in them, so site specific content. the editorial module stores homepage_logo.jpg and editorial.xml. Is there a generic concept in PS of where modules should store any files they need? /config and /img seem likely candidates to me. I tried to adapt editorial.php to pull and store the above two files in /config, but was unable to get the code to work. A diff file is attached, I don't suppose anyone could have a look to make suggestions? editorial_diff.txt
  6. What is not identical? They look the same to me. If the DB and files are copied over, the only thing to worry about is that file permissions, and the DB settings are correct. A little checklist I keep after setting up a copy: # disable friendly URLs on development system, Regenerate thumbnails, maybe change the theme is needed, switch paypal to sandbox mode Back Office >> Preferences Back Office >> Preferences >> Image >> Regenerate thumbnails Back Office >> Preferences >> Apparence >> Teme >> Vl Back Office >> Payment >> Paypal > Sand box mode # Maybe change emails alerts: Back Office >> Modules >> Mail alerts Back Office >> Employees >> Contacts Back Office >> Preferences >> Contact >> Shop Email # Add TEST to the shop name if needed: Back Office >> Preferences >> Contact >> Shop name Check file permissions cd /var/www/shop1 # assume we install in this dir chown -R boran * . # assume we work as "boran", apache runs as group "www-data" chgrp -R www-data . chmod -R g+rx * .htaccess chmod 755 . chmod -R g+rwx img mails modules themes/prestashop/lang translations upload download chmod g+w config upload download tools/smarty/compile/ sitemap.xml config/settings.inc.php chmod -R a+rwx img # don't know why but regenerate would not work otherwise
  7. I've just noticed that the difference between the correct and reported total exactly corresponds to the Euro/CHF exchange rate. So the order is for 6 × 15.43 Euros = 92.59 Euros But the reported total is 57,16, which is in fact 92.59 * 0.617284 0.617284 is the exchange rate Euro/CHF in the shop at th moment. So, it seems like PS calculates the line total correctly 92.59 Euros, but when then applies the CHF/Euro conversion rate and "converts" it to Euros, even though its already Euros. So, for the order confirmation, and payment request, the exchange rate is applied twice. But, as noted in the original post, the order confirmation email is correct. Perhaps someone could explain the differences in the way these totals are calculated, and where I might start looking?
  8. Hi, On http://old.boran.ie:8084/shop1 there is a test shop that has Swiss Francs as the default currency but also allows orders in Euros. If one orders 6 of the product "General Donation 25 Francs Suisse" in Euros, this is 6 x 15.43 Euros = 92.59 Euros. If one makes the above order with Payment by Bank wire, PS then sends out two emails 1. An order confirmation to the client which shows a correct total of 92.59 euros, 2. a second 'New Order' email to the shop administrator with a total of 57.15 euros. Which is wrong. This email looks like this: Commande 001010 passée le 26-02-2009 Paiement : Bank Wire Référence Article Prix unitaire Quantité Prix total General Donation 25 Francs Suisse 15,43 € 6 92,59 € Produits 57,15 € Réductions 0,00 € Emballage cadeau 0,00 € Frais de port 0,00 € Total 57,16 € Note that the total for that detail line is correct, but the lines "Produit" and "Total" are wrong. Now that is email is wrong is not so bad, the serious problem is that if one pays via Paypal, the amount request from Paypal is 57.16, i.e. the wrong amount is requested, and paid! Analysis - Version: I've tested this on SVN 463 (2 weeks old) and SVN 298 (Jan 9th). - Does not happen with the default currency Any suggestions please?
  9. I'm trying to attach a patch to this post, but it is not showing up. Is there some trick to get attachments to work correctly? I've posted it here: http://boran.com/sites/boran.com/files/ps_patch_forum_10649_0.txt
  10. Ok, the issues is resolved, a patch that does the job has been attached to this post. Changes are needed to classes/Product.php product.php classes/Cart.php themes/default/product.tpl I'll put it up on boran.com/presta where I keep my notes.
  11. How about a module to: - list end edit products, but not by first navigating through categories. The products would be listed in grid form. - back office ordering: already noted. - History of currency updates - multiple shops: http://www.prestashop.com/forums/viewthread/9664/modules/is_it_not_time_for_multi_store_multiple_shops__module - newsletter (already noted), but that allow pull the emial list from another table, or from a CSV file.. As regards payment: my PS installation is for a charity so I don't get paid. But I would contribute 50 or 100 euro to an interesting _OpenSource_ module that was really necesary..
  12. > isn’t there any statistics tables ? Yes, good point, can someone give information on how to clean up that stats if orders are deleted as noted above?
  13. If you want to go that way, there is also a tool for windows: http://www.spectralcore.com/datasync/index.php Its about $170
  14. > Why do you say that it’s not enough to just run the upgrade script… I think it’s enough if the Prestateam does’nt forget to update the upgrage.sql file. I imagine that the PS team review and double check the upgrade sql file on each point release, but not for every single SQL change (i.e. SVN commit). However I understand that the other SQL files are updated for each commit. > Imagine that the curent version is 1.1… but your interest is to work with the SVN revision 1.2.0.1 You update all your files via the SVN (with tortoise for ex.) and install your prestashop. Your are now with revision 1.2.0.1 running on your server… > When updating your files via SVN you check if the 1.2.0.1.sql file is updated… if yes you report manualy the changes on your datebase via PHPMyAdmin (this works if Prestateam has not forgoten to update its 1.2.0.1.sql file… wink > The day a new release is ready on the SVN for exemple 1.2.0.2, you juste make an upgrade with classic prestashop procedure. My feeling (I'm not on the PS team, can Damien or a team member confirm?) is that if you upgrade from point release like 1.2.0.1 to 1.2.0.2, then the upgrade SQL file will be fine, and thus the GUI upgrade procedure too. Sean
  15. Like Damien says, its not enough to just run the upgrade script, it may be incomplete (and it was for me) I've started documenting my notes on http://boran.com/presta#Upgrading if that helps you. Attached is an SQL script I've been testing as part of the above. My suggestion would be to wait for a point release if at all possible (but still use SVN), otherwise prepare to have a a few days to manually check for changes in code and SQL with a fine comb.
  16. Found the fix.... in Back Office >> Payment >> Payment module restrictions, The paypal button was on "Shop default currency" instead of "Customer currency".
  17. I see no problem doing step-by-step DB fixes, I just paste one upgrade command at time into the MySQL command prompt. For me what is difficult was going through the SVN diffs and building the SQL update file. >> You said that the install GUI update option cannot be used because it is grayed out (because the official version in settings.inc has not changed). Do you think it could be possible to ungrayed by changing something in the prestashop code ? Just change the version number indicated in settings.inc, then it will compare and allow an upgrade, I think.
  18. Hi, I have a store, default currency is CHF, but a customer can also pay in Euros. If an items is selected in Euros, and one proceeds to checkout, then paypal, then give in credit card details, paypal then shows an invoice before confirmation in CHF! I'd like customers who select in Euros, to be able to pay in Euros (not the shops default currency) as its more transparent to them, and they do not get caught by paypals currencies rates. Apologies in advance if this has already been discussed, the only related thread I found is the following, but the currency seems to arrive in Paypal OK. http://www.prestashop.com/forums/viewthread/9591 Version: I'm using testing with SVN 463 (about 1 week old), and also v1.1 final. Sean
  19. Hi, I had the same question, and came up with the following if my order number is '1', and prefix 'ps2': delete from ps2_orders where id_order=1; delete from ps2_order_detail where id_order=1; delete from ps2_order_return where id_order=1; delete from ps2_order_slip where id_order=1; As regards ps2_order_history, one could either delete the entries there two, or leave a trace by adding an entry with sate 999 (if we want to use that to mean deleted) insert into ps2_order_history set id_order=1, id_order_state=999 date_add=now(); Is that enough, are other tables involved? Hmm, we could also make a stored procedure, to have it available for the future: DELIMITER // CREATE PROCEDURE order_delete (i INT) BEGIN delete from ps2_orders where id_order=i; delete from ps2_order_detail where id_order=i; delete from ps2_order_return where id_order=i; delete from ps2_order_slip where id_order=i; delete from ps2_order_history where id_order=i; END // DELIMITER ; Then call it with order number as an argument: call order_delete(1);
  20. Has a bug been registered, I'd like to track it. I don't suppose you've example SQL statements that I can use as a starting point, i.e. that calculate the total correctly? Sean
  21. Well it took me several days to update, not a trivial task :-) I'm now running SVN 468. This bug has not been fixed.
  22. I think it will, but one will have to be attentive to the errors from the SQL output. Personally I'd suggesting running each statement in the upgrade script one by one, so that if an error happens when a new field is inserted, one can judge whether its OK because the field is already there, or not OK because maybe the field has a different type... Where is gets complicated is when one does not wish to wait for the next release, which is what I was doing above..
  23. Should the diffs in 1.2.0.1.sql not cover the other three files?
  24. I just did some diffs, - 1.2.0.1.sql looks ok, a coherent 1-2 diff was produced - the formatting in db.sql must have changed alot because tortoise has big problems producing a comprehensible diff. - perhaps a comment could be added to the top of db.sql, db_settings_extends.sql and db_settings_lite.sql explaining what they are? - db_settings_extends.sql: this looks like default content and settings. The diff shows many changes not in 1.2.0.1.sql (see attached) - db_settings_lite.sql: seems similar I've attached a combined diff fort the above except for db.sql, which was too complicated. This is a lot of work! Perhaps one could explain the relationship between the three files? Should the diffs in 1.2.0.1.sql not cover the other three files? Sean
  25. So what I propose using The tortoise SVN + diff + highlighting changes above makes sense? (I didn't find an easy way of doing the same thing on the Linux cmd line). Any quick tips on generating the SQL updates apart from copy and paste from the diff? :-)
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More