Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Hmm no takers then :roll: I did notice that if you cancel the order - instead of a refund, then the invoice is hidden. I think maybe that when a full order is refunded then this should probably be what should also happen (a full refund is the same as cancelling the order in most ways, as the customer ends up not paying). I'll post that as a bug and see what the developer folks think. Still would like to hear what anyone else thinks about this..... :question: Paul
  2. I've been working on a full IPN implementation for Paypal, and have come across an interesting situation that affects all payment types. The question is as much regarding business processes I guess as the coding that goes on behind it. When a customer places an order that is subsequently refunded, then the order remains unchanged in the Back Office, apart from the status being changed to "Refund". This is true using the Back Office to manually change the status, as well as the status being updated automatically via the payment method (in my case PayPal IPN). However the customer invoice still only records the initial sale. I'm not an accountant, but shouldn't there be a second invoice issued that reflects the refund, or an updated version of the initial invoice? Secondly, shouldn't the amount paid by the customer also be reduced by the full amount (or partial amount; paypal support partial refunds, which I've implemented via IPN too)? The back office doesn't actually show what has been paid against the order, except where it doesn't match the order value - so I suspect that when changing the state to refund, the amount stored in the database as having been paid remains unchanged currently? I'm a little concerned that these issues may effect any future accounting export/statistics add-ons folks may produce.... Any input would be appreciated either from a developer or commercial perspective, Paul
  3. In the addstuff2 directory rename addstuff.* to addstuff2.* Edit the files and change all the occurrences of addstuff to addstuff2 (search and replace should be fine). That should do it. Most important step of all...... ---->Enjoy! Paul I'm thinking of releasing MoreStuff shortly, to help folks out who don't want to mess about editing files....
  4. Sorry, had a problem with the forum mangling the quotes, so I left them out..... maybe should have mentioned it Great you've got it working. Paul
  5. phillip, Did you try : ORDER BY ag.id_attribute_group, pa.id_product_attribute'); Paul
  6. Where is that error from? I may be useful to post or PM a url to the site too, so I can have a browse myself. Sounds like something isn't configured correctly. Paul
  7. That's more likely to be a permissions error on the files or a .htaccess setting that would cause an HTTP 500 error. Fixing it will depend on the server configuration. I would suggest that the permissions on the files in the /modules/paypal directory should be 644 (i.e. paypal.php, validation.php etc.). The directories from the root downwards should be 755 (i.e. /modules and /modules/paypal if your shop is in the root directory). If those don't work then slowly relax the permissions (e.g. 664 for files and 775 for directories). Temporarily rename any .htaccess files during your testing too (turn off friendly urls in the back office while you test to prevent errors caused by having it switched on with no corresponding .htaccess entries.). You may not even see .htaccess files listed your ftp client depending on how the server and client are set up. If in doubt (and you don't have SSH access to the server) you could always get your hosting company to check. While changing permissions use http://www.example.com/modules/paypal/validation.php as the test url. You should get a blank page when everything is working correctly (as detailed in the thread I referenced earlier). PHP files shouldn't need the execute bit set (e.g. 755 or 775) but if all else fails I guess your server could be configured that way also. I'd leave that as a final option though if all else fails. Paul
  8. Thanks Ken, I've uploaded the code here for anyone that wants to try it out: Paypal IPN modified version Paul
  9. Howdy Red, Did this work out for you ok in the end? I just noticed this thread but I thought we'd sorted it out "elsewhere" for you.... @hydra ZenCart is an "improved" version of osCommerce and you haven't a hope of any improvements being made to the template system.... not by any sane developer! Paul
  10. Just to let anyone following this thread we are still working on it (communications via private messages don't help folks viewing this thread stay in the loop)! I have a version of the module that will now use cURL to connect to paypal should fsockopen fail (resulting in the "Impossible to connect to PayPal server" error message). This has been tested (via the sandbox) using both methods and they operate correctly in my test environment. If only we could get it to work on Ken's site now.... @Ken: I've placed a new version (today) on your site, with some improved error checking that may hopefully shed some more light on what exactly is going wrong, if it indeed fails again (as I suspect it will). If anyone would like a copy of my current version please PM me an email address and I'll send it on, although it's still work in progress. Maybe another pair of eyes could spot any errors in there. After spending so long looking at the PayPal module I think I'll write an alternative one though, as there are several areas where the current one produces misleading error messages etc. and it could be greatly improved upon. Paul
  11. You can add the security seal in a sidebox if you like (with or without heading and box styling) using this: http://www.ecartservice.net/05082008/addstuff-for-prestashop/ Paul
  12. You could look at using this: http://www.ecartservice.net/05082008/addstuff-for-prestashop/ The script goes in the mystuff.html file in the module directory.....
  13. Yup. Go to Back Office. Hit the Modules Tab. Just under the tabs click Positions. Now you just click the red cross that's next to the one you want to remove. TADA! Paul
  14. Ken I've sent you a PM with a modified version of validation.php (not paypal.php as I stated earlier - need to get some sleep some time I think). Paul
  15. I've got a spare hour or two tonight, so I'll have a go at putting something together now. Paul
  16. osCommerce will use curl instead of fsockopen, so that may be why it worked before but not now. I can have a look at a modified version of paypal.php that tries both methods if you like, and we can see if that works? Paul
  17. Sorry ignore the previous post I misread you. It's the validation that isn't working. It looks like your server should fail when using the script you posted regarding the test for fsockopen function? If this is the case, then you'll need to fix THAT. Nothing to do with prestashop itself. If the test works, then it isn't allowing connections outwith your machine, so that needs fixed. You're not with siteground by any chance? http://kb.siteground.com/article/Php_fsockopen_problems.html Paul
  18. It should configure the paypal url as : https://www.paypal.com/cgi-bin/webscr for production, or https://www.sandbox.paypal.com/cgi-bin/webscr for the sandbox. What's at line 24 in paypal.php? Paul
  19. Does the following url work? (assuming that presta is installed in the root directory of www.mysite.co.uk) e.g. http://www.mysite.co.uk/modules/paypal/validation.php If the above url doesn't work, then that's the problem. The fix I posted wasn't related to this, it takes care of the configuration of the IPN return url without the need to specify it in your paypal account. return_url doesn't exist as far as paypal are concerned, whilst the notify_url one should be sent with the url paypal should send notifications to. Its now been tested and works. We have two PrestaShops working off one paypal account now. Paul
  20. You should also add an additional value to the form names "rm" and a value of "1" This will set the return method, which should get paypal to send your customer back to the correct page. i.e. the end of paypal.tpl should read: <input type="hidden" name="notify_url" value="{$returnUrl}" /> <input type="hidden" name="rm" value="1" /> </form>
  21. I've been working on this today, and it looks to me like there's a bug in the paypal payment module. In the forum sent to paypal, the return_url field is being sent the url to validation.php. The url for validation.php should be sent in a notify_url field in the form I think. This would also mean that you won't have to specify it in your paypal account; which is what you do according to threads I've read on here, but that's only because of the error in the paypal module, and is a work-around. e.g. here: http://www.prestashop.com/forums/viewthread/3257/ I could be miles out.... but you could try editing paypal.tpl for now and change "return_url" to "notify_url" and see if that helps. I'll have a closer look at the paypal documentation mean time and confirm my suspicions. This should also mean that you can run multiple stores from one paypal account. Paul Update 16:19 12/08/2008: From the Paypal documentation:
  22. Maybe there needs to be some work done on assisting with configuration then? Detailed requirements? Installation Documentation covering configuration of the environment? Paul
  23. You need to copy the folder blockadvertising and name the new copyblockadvertising2. Then rename all the files i the new directory from blockadvertising.php etc. to blockadvertising2.php etc. Now you edit these renamed files and replace blockadvertising INSIDE them to blockadvertising2. One you've done these steps you should be able to cick install from within the modules section of admin, and you're done. Paul
×
×
  • Create New...

Important Information

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