Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Well spotted. I'll add that to the list of changes for the next version. I do check whether the file is visible at all (you could generate it into a directory above your web root - in which case is says it's accessible via ftp, but obviously the logic doesn't work in your case :cheese: Paul
  2. It wasn't designed for display in the front office... I think it may freak your customers out if they realised their shopping habits were being shared with anyone else visiting at the same time.....? Don't you think? I guess you could always cover yourself in your "privacy" policy :-P Paul
  3. yup that looks good. The only thing I would suggest is that you use a .htaccess file to deny access from all but the local host to that script - just to be absolutely safe. Paul
  4. You need to dig through the code to look for the appropriate hook functions at the points you need to insert your code into the execution path. There's a table in the database which will list the function names, and yu can take a peek at the Hook class in the classes folder for more clues as to how you would call such a beast. I suspect that you want to use code similar to that outlined in this post, but in your case you'll want to perform different actions based on the order status: http://www.prestashop.com/forums/viewthread/23408/#107041 Paul You may also be interested in a series of articles I've posed on my site regarding writing a module for PrestaShop, they are creatively called Writing your own PrestaShop module :-)
  5. Probably curl is your best bet, although I've never tried reading the output from a cgi script, but I guess it should work. Paul
  6. This was one of the things solved by my "beta" paypal module. It flags these events in the backoffice using the messages functionaility. The default PayPal payment module only looks for a completed transaction - so if it gets anything other than "success" it throws an error. Paul
  7. Yes a module with a tab on the products page would be a nice touch. You could have tabs for installation, FAQ etc. I wonder if you could use the CMS to enter and store them, then just write a module that gets the content from the CMS tables to place on the product page. Shouldn't be too challenging as long as you have a way of identifying which CMS page applies to which product - maybe just something as simple as a structured title would do it.... Paul
  8. Sorry, and what I posted wasn't quite right anyway, and this is a bit beyond Part 4 in my series First thing to do is add the hook to the install function: function install() { if (!parent::install() OR !$this->installDB() OR !$this->registerHook('updateOrderStatus') ) return false; return true; } Next we need to implement the hook function itself: // Track changes in the order status public function hookupdateOrderStatus($params) { if ($params['newOrderStatus']->id === _PS_OS_PAYMENT_) { if (!$this->isSerialIssued($params['id_order'])) { $this->IssueSerial($params['id_order']); } } } Then write our two support functions: // Test if a serial number has been issued public function isSerialIssued($id_order) { $result = Db::getInstance()->ExecuteS('SELECT `id_serialkeys` FROM `'._DB_PREFIX_.'serialkeys` WHERE `id_order` = '.$id_order); return Db::getInstance()->NumRows(); } // Create a new serial number record in the database // Need to also add some email sending mechanism too eventually public function IssueSerial($id_order) { $new_serial = 'abcdefg'; // You would generate this here in real life return Db::getInstance()->Execute("INSERT INTO `"._DB_PREFIX_."serialkeys` (`id_order`, `serialnumber`) VALUES ('".$id_order."','".$new_serial."')"); } So what does it do? Every time an order status changes our module's hookupdateOrderStatus() function gets called. It gets passed two elements in the $params array, which are an OrderState object and an order "id". We're only interested (for now anyway!) in the _PS_OS_PAYMENT_ status that tells us someone has paid, so we first test for that by checking its id against the constant (defined in config/config.inc.php), and if the status is changing to anything else we exit. Now we want to check that this isn't a duplicate (say an IPN based payment module updates the status more than once for example) so we use our isSerialIssued() function. This could also check whether there are any products in the order that need a serial number issued, of course! Finally, we call the member function IssueSerial() to actually do the work. This would generate the serial #(s) and email the customer. You'll probably need to implement tests for multiple products, and may have to issue multiple serial numbers per order, depending on how you set things up and how your serial gen. script works. Paul
  9. I would just use INSERT INTO Your AUTOINCREMENT will handle the missing 'id_serialkeys' field just fine. From what I can see from the hook function it should be getting sent the $params array with the following array elements: [code] $params['newOrderstatus'] $params['id_order']
  10. Good job, although I'd suggest a couple of things: 1) The data should really be defined in a bit more detail -- id_order , for example is defined in Prestashop as: id_order int(10) unsigned NOT NULL You should probably define the data more precisely for your own fields too. 2) I would use "CREATE TABLE IF NOT EXISTS '"._DB_PREFIX_."serialkeys' (...)"; just to prevent errors on reinstall. Paul
  11. As far as I know the only version that exists for 'Website Payments Pro' is the one that is/isn't working in the latest 1.2 beta version i.e 'paypalapi'. This is very unlikely to work on earlier (1.1) Prestashop stores, but is a possibility for when 1.2 is released. The Paypal v2.0beta2 is for 'Website Payments Standard' and replaces the official 'paypal' module in Prestashop 1.1 and 1.2 What we're discussing here is code I wrote a long time ago to implement 'Website Payments Pro' in PrestaShop 1.1 i.e. before the 1.2 'paypalapi' was even a remote possibility. This is actually made up of two modules -- 'paypaldirect' and 'paypalexpress' although I haven't published the code for the second of those yet. Glosticks intends developing these on from where I got to. I hope that makes even a small amount of sense! Paul
  12. NO! :cheese: The versions you find in this thread tend to be "experiments" to try and add/change the main distribution to fix certain issues. I would suggest using the latest version from my site, and reporting any issues you may have with it either there or in this thread. The version above is an attempt at fixing issues with entities in german language feeds. If you submit to the German Google Base service, then your help testing would be appreciated, otherwise 0.6.3 is the version you should use for now Once the current version properly supports the different (US,UK and DE) services as-is, then I plan to allow the user to select which they want to create a feed for (planned for 0.7), then add some nice "extras" (0.8 though 1.0). Paul
  13. The problem with the totals not working correctly is due to the values now being returned with more thn 2 decimal places. If you round the values it should work, although there's a risk that rounding errors could creep in if you;re not careful. I'll fix this issue in my (incomplete) Express Checkout code before I release it. For the Direct Payment function: foreach ($Cart_Products AS $Product) { $nvpRequest->setNVP('L_NAME'.$LineItem , $Product['name']); $nvpRequest->setNVP('L_AMT'.$LineItem , round(floatval($Product['price']),2)); $nvpRequest->setNVP('L_NUMBER'.$LineItem , intval($Product['id_product'])); $nvpRequest->setNVP('L_QTY'.$LineItem , intval($Product['quantity'])); $nvpRequest->setNVP('L_TAXAMT'.$LineItem , round(floatval($Product['price_wt']-$Product['price']),2)); $taxTotal += floatval($Product['total_wt']-$Product['total']); $itemTotal += floatval($Product['total']); $LineItem++; } // Calculated values $shippingFee = $cart->getOrderTotal(true, 5); $nvpRequest->setNVP('TAXAMT' , round($taxTotal,2)); $nvpRequest->setNVP('ITEMAMT' , round($itemTotal,2)); $nvpRequest->setNVP('SHIPPINGAMT' , round($shippingFee,2)); $totalAmount = round($itemTotal,2) + round($taxTotal,2) + round($shippingFee,2); $nvpRequest->setNVP('AMT' , $totalAmount); Paul
  14. Did the breakdown not work? It should do :-) You'll need it to work for Express checkout anyway if I recall correctly.... That's what I though, but sadly... :cheese: The only reason that the 1.2 Express Checkout code will work is because there have been changes in the 1.2 core to allow it to. That's the advantage of controlling both - something we mere "module writers" can't do. Adding the support in 1.1 isn't that easy, and looking at the paypalapi code I'm pretty sure it won't work with 1.1 (although I haven't actually installed and tried it on 1.1). Paul
  15. Ah, but I need you for testing, so you don't get off that lightly :cheese: I'm looking through the API specification and the code, and I don't think it was a problem really at all, apart from in my code.... I've attached a slightly modified version that it would be great if you would test for me? For the next release I'd planned to properly address the german feed and in fact internationalisation in general, as there are folks out there who may wish to publish UK, US and DE feeds from their store - which would be nice. At the moment it decides which language (and currency) to use based on the language preference of the admin user (from their cookie) which isn't really useful, since Google currently only support English and German as the language. This also important for the next stage in the development, which should yield some nice results for all you store owners out there looking for a competitive edge ;-) Paul There's a new translation entry for the word "new" so you can localise the condition tag to german - it appears that this should be enough, rather than changing both that and the tag itself - apparently googlebase.php
  16. I should have mentioned that you can get details out of your database regarding character set in the SQL tab og phpmyadmin using: SHOW VARIABLES LIKE 'char%'; Paul
  17. Out of interest what character set are your database, fields and mySQL client using? I notice in the changelog that as of 1.2.0.6 you need to have UTF-8 support (I haven't looked to see how or what enforcement that entails though) - this may help in the future with these types of issues, but doesn't help us right now... In your site (if I'm looking at the right one) your pages have the encoding set to UTF-8 and since it displays correctly in the browser I'm guessing that the data in the database is also utf-8 but that doesn't necessarily have to the the case (maybe PrestaShop plays with it?)- I'm just wondering if the problem is being introduced via MySQL somewhere. The feed was written to assume that you're using utf-8, and that's what Google are expecting! I'm not sure that there's a simple way to handle this, and that maybe you'll need to hack the data much in the way you've done above on a case-by-case basis :down: Paul
  18. Sure you can. Just edit the template file (almost pure xhtml anyway). It's the template: themes//maintenance.tpl Paul
  19. Should work with both, but I haven't had a chance to test that one in 1.2 - it'll be getting an update in the near future to fix a few little issues and add a couple of tweaks. I believe it has been shown working on one ofthe 1.2 beta versions (by an end user). Paul
  20. You should try to use html entities in your product descriptions - utf8 should be used throughout your store to help get rid of these problems too... I'll have a think about a possible fix though. Paul
  21. I would strongly suggest you disable the countries rather than delete them. Deleting stuff isn't a great idea ;-) in phpmyadmin: UPDATE ps_country SET active=0 WHERE iso_code NOT LIKE 'GB' Not that the above assumes that your table prefix is "ps_". I'm sure you'll figure it out! Remember to set your default country too Paul
  22. There is an option in admin already to do this, you can even allow your own IP address access so you can check the front office without anyone else seeing. Preferences->General->Enable Shop. Paul
  23. You could write a module that implements a hookPaymentReturn($params) callback. Within this function you could then check what had been purchased and whether the payment was successful. If all the checks add up, then you could email the customer the serial number using an email template and the build it messaging code. I can't think of any better ones off the top of my head to be honest, and I think that in some circumstances the above hook might not get called - but once you've tested it with the payment modules you use - it should be fine from then on. Actually the hookUpdateOrderStatus() one might be a better choice. You'd need to test it out and see which works better Paul
  24. See the following thread for current status: http://www.prestashop.com/forums/viewthread/22676/offer_bids_and_prestations/website_payments_pro_for_the_uk/
  25. I've released some of my code on my site, which may be useful: Paypal WPP (Example) – PayPal Direct API Once I've sorted through the Express Checkout one, I'll post it too. Paul
×
×
  • Create New...

Important Information

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