Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Looks like it could be related to the encoding? utf8 versus iso-8859-1 etc. That's when I've usually had such things. I'll need to download this, and see how it's put together, it having been written by a fellow payment module "nut" :cheese: Paul
  2. Just in case editing posts doesn't alert folks, Consider this bumped Paul
  3. Ooh, I didn't think it did, but it's been a while since I looked. I'll check it out. Update: I've uploaded a tweaked version of the Google Base Module now version 0.3 which should only display active products. Paul
  4. I've been working on payments modules recently and the tax thing just gets worse and worse. There are many laws regarding tax and taxation (not surprisingly) and they even go to the extent of defining the rounding policies you should use...... There doesn't appear to be any way of controlling these in PrestaShop either :-/ Paul
  5. Did you follow the installation instructions regarding setting file permissions? A link to them can be found on the download page. In general you should try and avoid using chmod 777 on files, unless they really are executables that you want anyone to be able to modify 755 for directories and 644 for files is the best option, 775 and 664 if the above doesn't work on your server (but they should). Paul
  6. This is one of the things I aim to fix with : http://www.ecartservice.net/08092008/beta-v2-paypal-module-prestashop/ :-) Paul
  7. Module is attached, as promised :-) Not sure if it's going to be easy to install as I've not looked at it since I wrote it.... There's a readme.html file in the zip file with some vague instructions though :cheese: (basically a copy of the module control pane Help text). Paul cs_livehelp_0_1.zip
  8. I hate to be a pessimist, but Google Checkout isn't a payment processor, it's a shopping cart; well it's a Checkout! If there was HOOK_CHECKOUT functionality in PrestaShop (although this is true for osCommerce, ZenCart etc, too) then this would be easy to do. There isn't. The idea behind Google Checkout is that you "Checkout via Google" rather than the site's standard cart, so you need to send all the information; shipping, currency, tax rates etc. on to Google Checkout, then let the customer choose their options there.... including delivery address and currency! At the moment all the options are selected via order.php, then you've to convince Google Checkout not to bother doing it all over again; usually with limited success. Using it as a payment processor is always going to be a compromise. It's unlikely that what Google displays makes sense. 8-/ Paul
  9. The main problem with the ValidateOrder() function is where to put it in my experience! It can't be in the hookPayment() function as that would break the whole cart (the order can't be validated until after a payment method has been selected, obviously). I think of ValidateOrder() as ConvertCartToOrder() - it makes more sense to me This the "Point of no return" since we can't delete orders.... With synchronous payment modules (offline CC/cheque or direct authorisation) you have full control of the program flow, so you'll see the ValidateOrder() function being called in validation.php; which is the next "step" in the process, and is the point at which the payment is deemed to be received/confirmed, so an order can be created. The flow in the cheque payment module seems fine to me for synchronous payment process flow. Asynchronous payment methods such as Paypal (and if implemented with a callback; Google Checkout) have to wait for the payment processor to call the validation.php script, so if the ValidateOrder() function is placed in there for these, the Cart object remains a Cart object, and no order appears in the customer's account. Most days this will only be a 30 second delay (although still time for the customer to get back to their order list first!) other days it could be hours... In my latest version of the paypal module I've attempted to get around this delay by calling ValidateOrder() with a "pending" status at the point of leaving the site to go for payment authorisation - it could have been done on return, but then what happens if the customer closes their browser after making the payment, and never returns to your site? I then use validation.php purely to handle IPN notifications to alter the order state from then onwards, and there is no ValidateOrder() call in there at all. My method partly falls apart if the customer aborts the order before paying though, but at least the cart is removed, and the order left in a "pending" state. I think that we need some changes to the Order class to support this "limbo" state for orders. We need to acknowledge them as orders once a payment method has been chosen, and a commitment to buy has been made, but also factor in the possibility that once the customer leaves the site they can still change their mind and we can't stop them! While I agree that you shouldn't delete orders as a principle; deleting or modifying an order while it's between Cart and (full) Order state is something that needs to be considered, and it would appear to me to be best placed within the order class. How you handle converting a pseudo-order back to a cart is the challenge I think. Thoughts? Paul
  10. I'll package it up, and write some instructions later today, and post it in here :-) Paul
  11. I had a play with wrapping the craftsyntax free live support code into a module if that's any good. If you have a different one in mind, then give me a shout and we'll see what can be done. The craftysyntax one is currently on my demo/test store: http://prestashop.ecartservice.net Paul
  12. Just add // in front of it i.e. change it to: //Mail::Send(intval($order->id_lang), 'order_conf', 'Order confirmation', $data, $customer->email, $customer->firstname.' '.$customer->lastname, NULL, NULL, $fileAttachment); That way if it doesn't work you just need to erase the comment characters to put it back the way it was. Paul
  13. Commenting out the above line should work then. I was just hoping we could get around this without changing things that will likely get changed back at the next upgrade To be honest the whole "email the customer" function is a bit of a mystery. Every time I think I understand how it works I find something that breaks the rule! Paul
  14. I think I understand, but my reply wasn't clear. I don't think (but could be wrong) that you can disable the "Order Confirmed" email without changing the code. You can however disable the preparation in progress one.... so why not disable that one, then modify the "Order Confirmed" template to act in its place? I'm trying to find a way to avoid modifying the code if possible, as going down that route ties you to maintaining your changes through subsequent upgrades, that could get tedious! If you really, really need to modify the code, then the area to look at is in classes/PaymentModule.php. you should comment out line 271: Mail::Send(intval($order->id_lang), 'order_conf', 'Order confirmation', $data, $customer->email, $customer->firstname.' '.$customer->lastname, NULL, NULL, $fileAttachment); But I would suggest that you try not to Paul
  15. You could probably do it within the payment modules (or earlier up the code chain) but why would you? I suggest that you edit the actual order confirmation email template to say what you would like it to ;-) Paul
  16. That installation method isn't supported (yet) by any of the modules that I know of.... You need to unzip the files and upload the subdirectory to the modules directory on your server, then install from the back office. Paul
  17. mayo, you'll need to alter the Product class (in /classes/product.php) as this is the wrapper. If you were to look at the occurrences of say $wholesale_price, for example, then make sure that you perform all the same actions for your new RRP field. You may also have to add member functions to be able to correctly manipulate it throughout the cart. You'll then need to follow the use of this class through the code... doing a search through the entire shopping cart source for the appropriate member functions is a good way of seeing where things are used, and how. Paul
  18. Damien, not being rude but if there was a SVN / weekly snapshot then the rest of us who are also developing for PrestaShop would be able to ensure that things work soon after new releases, rather than having to catch up.... It may also be that certain features that are being developed by the community could be duplicating what you chaps are working on. LOL at reading the forum..... maybe you need someone to manage communications between the community and the team? Paul
  19. Easy. Open up /modules/ganalytics.php and change the following code: At Line 23: if (!parent::install() OR !$this->registerHook('top') OR !$this->registerHook('orderConfirmation')) Changes to: if (!parent::install() OR !$this->registerHook('footer') OR !$this->registerHook('orderConfirmation')) Line 124: function hookTop($params) Changes to: function hookFooter($params) Note that you'll have to uninstall it if it's been installed already. Not sure if the uninstall also removes the previous hook or not. If it doesn't then the code will be inserted twice.... Paul
  20. I assume it's the "payment page" - "standard mode" that you're looking to implement? I would also assume that you don't intend to use deferred settlement? Narrowing down the options would make it easier to implement :-) Paul
  21. I've uploaded a Beta 1 version of my updated PayPal Payment module here: Prestashop PayPal Payment v2.0beta1 The above will have to be unzipped and uploaded to your testing server as a complete replacement for the current module (which must have been previously uninstalled). Install and configure as usual. Feedback would be most appreciated. Please do not use on a production server. You have been warned, as it is highly unlikely that this release is bug-free!! Paul
  22. Rory, Have you entered information in the meta fields for the products? This has a huge influence on how google views and displays your results. Paul
  23. I use beyond compare for this sort of thing : http://www.scootersoftware.com/ If you do a compare between the default template directory for the old version and the new version you can see which files have been modified in the uograde, and what's been changed It's mostly just a case of making similar changes to your template's files.... Paul
  24. Mike, This is due to the way PrestaShop creates paypal orders. This is done (like all the other payment modules) in validation.php but in the case of paypal; only when a "Completed" IPN is sent to your shop. It's related to the other problem of orders not showing up, and/or orders taking a while to show up in the back office. The cart stays as a "cart" until it's converted into an order - if that makes sense to you? Paul
  25. I'm afraid the fun isn't over yet (particularly after the IPN delays from PayPal yesterday, which just highlights this issue further) you folks may want to have a read of this (the important bit is at the end!) and volunteer! http://www.ecartservice.net/20082008/improving-paypal-prestashop/ Paul
×
×
  • Create New...

Important Information

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