Jump to content

Paul C

  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Paul C

  1. You have to pay to use Product Submit I believe - it's a PPC (Pay per click) system, so not sure you'd want to just throw all your products in there :cheese: If there was sufficient demand for it, then it would be quite straightforward to do. Paul
  2. The Paypal Website Payments Pro (UK and I think AU also) version IS Verisign in all but name. That's the main reason why there is a US version (Paypal's own solution) and a UK version (the solution they acquired from Verisgn) of WPP. I believe the next release of PrestaShop will support WPP, but I suspect it will be the US (Paypal's own) method. It would be a lot of work to implement Payflow in Prestashop, and in fact there's a good chance that it will get phased out anyway. Paul
  3. Have a read here: https://www.paypal.com/cgi-bin/webscr?cmd=xpt/Marketing/general/VerisignAcquisition-outside Does that help? :-) Paul
  4. Your site is still showing that it's in maintenance mode. You could try the attached version, in which I've removed the product_type attribute from the feed. I suspect that if Google performs a check on the product page urls in the feed it will reject it again anyway, since your store is in maintenance mode. Is there a reason for wanting to publish on Google Product Search for a store that nobody can access or buy from??? Have you forgotten to re-enable the store? Paul P.S. I wouldn't suggest anyone else use this version. It is identical to the standard one with the product_type attribute removed, which should not normally be the case. I also suspect that the feed will work once the store has been enabled for Google to see it.... googlebase_0_6_3_npt.zip
  5. You can create your own Admin tabs in the back office, and create classes to encapsulate your own database tables. The reason there's no hooks is because you don't need them Take a look at my random adverts and callouts module for an example of how to do this. I'll be adding tutorials on extending the Back Office in due course too - I'm currently still publishing a series on creating modules, as I noticed that a lot of the existing articles out there are full of "guesswork" or are just wrong ;-) Paul
  6. Two things I noticed, although I can't say if this is what's causing your problems: 1. Your store is in maintenance mode - none of the links in your feed will be valid, as they'll be redirected to the "maintenance" page. You must link to an ecommerce enabled site, which yours currently isn't!! 2. You don't appear to any any categories, so the product_type element is empty. Paul
  7. Glad to say that this ties nicely into another "idea" I have to enhance PrestaShop ;-) It will take a few days as I've got a few social engagements this weekend (yes, I do have a life!) but this will be supported in the very near future, once the research is completed and the code written.... Paul
  8. It's Google that initiate the https connection BACK to your store. In sandbox mode you don;t need to be able to accept/send via ssl, but in production mode you do. The "Failed to Get Basic Authentication Headers" is related to the fact that google wants to log into your site using your merchant id and key. If you're running php over cgi this won't work so you will need to create a .htaccess and .htpasswd pair I believe. There was a script called htaccess.php which was written to generate the appropriate entries (although I found I had to manually edit the files it produced anyway) certainly in the early osCommerce releases. Here's a blog post on the issue (relating to osC, of course). http://prashcom.blogspot.com/2007/09/google-checkout-failed-to-get-basic.html
  9. I think it would need to be logged with the author of the module. If I remember correctly there's an issue with running php over cgi and the authentication which is a whole different ballgame to SSL. That's what the "Failed to Get Basic Authentication Headers" error messaqe relates to, not SSL. Most problems are likely to be server configuration issues, in which case you will have to get advice from your hosting company on how to correctly configure it. There's lots of posts on the subject, as these issues are the same for all the shopping cart implementations. Paul
  10. See now that's where we differ as I'd like the module templates and css in the theme folder.... Paul
  11. If that's "by the book" then maybe there's an explanation why the PrestaShop core paypalapi module in 1.2 places the classes in the module directory Glad you got it sorted, but it's a shame you need to get people to copy files to multiple locations. Paul
  12. It uses PEAR, so I think as long as the class name matches the filename it'll find it, but I've never tried. Hate peppering sites with files, but I guess putting something in /classes makes sense. If you work for Prestashop then when you can't write a module following the rules you just hack the core Paul
  13. Yes you can to both - just read the updated documentation, and there are sdk values you can use for the api, key, password etc. There are regional differences that have to be coded for though (expiry/issue number for UK maestro cards for example). Have any of you actually tried the new code in the latest 1.2 beta? I think you'll find that it's all in there.... As I've said before the only part of mine that works is the direct credit card payments (and you would have to add the extra fields if you want to use it in the UK). You aren't allowed to use the direct payment facility WITHOUT also offering express checkout though, so it's useless Works great though Paul
  14. Actually, from the paypalapi module in the 1.2 beta: public function getContent() { include(_PS_MODULE_DIR_.'/paypalapi/admin/PaypalAdmin.php'); $ppAdmin = new PaypalAdmin(); return $ppAdmin->home(); } Paul
  15. It's a little dodgy it has to be said You could try putting the class in the /classes folder and naming the php to be the same as the class you need, or check if there are any other modules that DO work. I had a class in a separate directory in the /modules tree that was shared between two payment modules. It worked in but is broken in The classes are loaded dynamically which is why you're seeing the errors (the code is being eval'd). An absolute path would probably work, but then you would need to know the server path, which isn't very useful for an end-user module. I assume you're using relative paths, and that they're relative to the directory that the module is in? e.g. require_once(dirname(__FILE__).'/../paypalcore/paypalwpp.php'); Paul
  16. It does look highly customised. Not sure there's much advice I can give without knowing a bit more about how it's set up etc. There's nothing fancy being done to get the products, and no major change from the last version as long as the default settings are used. Paul
  17. hmm. That's weird. Does it return the the config screen and give a red or green message at the top? It would be useful to know what servertype you're running on too. Send me a PM with some details and I'll look into it
  18. Bump. The 0.6.3 download has been fixed - see the original post for details. Paul :red:
  19. This was intended to get around lots of issues folks were having, by actually logging the responses from PayPal (other than just checking that the transaction was ok). It also creates an order BEFORE the IPN comes back - this has been an issue when PayPal have taken up to 15 hours to send an IPN to your store. The standard module will still show the products in the customer's cart, and no order in the front or back office until an IPN has been received. The original is in english. I'm not sure if any new messages added are in english too, but I suspect that they are Paul
  20. I've just used the member function from the Category class - that way it'll break exactly the same way the rest of the store will ;-P We may try that for "minor" testing in the future, but it's good to have as many folks as possible try these out on as many different platforms as possible!!! I'm kind of hoping we're nearly there for now to be honest... Paul
  21. Right, yet another new version. This one should address: - correct file paths etc. on windows machines - possibly... - yet another fix for generating the product type (please say I've nailed it this time!!!) - yet another fix for the product urls (ditto to above!) - A test for at least one image, else the tag is omitted Outstanding features/bugfixes: - just noticed that for 1.2 the price is being output at 6 decimal places instead of two. - need an option to select the long or short product description to be used in the feed. Paul EDIT: made a fix in the archive and re-uploaded : line 93 the pipe should, of course be a > now and not the html entity. googlebase_0_6_3.zip
  22. @diamond204 : It looks to me like you have products with no image or maybe the "cover" image isn't set? I would need to look into it more closely. I'll note down that maybe I should test whether a product has any images, as it would certainly not work as expected in that instance. @Icarus. Sorry, I've realised that my testing methodology isn't catching these variations properly - I have all my sites installed in the root dir for a start, so I'd made an assumption about the return value from the getProductLink() function that was just plain wrong I'm already testing on 3 different setups, so didn't bother actually testing them with __PS_BASE_URI__ other than '/' :red: Will fix it now one way or the other. I will also look at what I've done wrong in the category function using the setup you've suggested. A thought did strike me that the current method won't work if someone decides to have a category named, for example "Themes for PrestaShop 1.2". I'll maybe try and check whether the sorting option is enabled, and if it is specifically remove the prefix only, rather than doing a replace. Paul
  23. For this version, yes that seems to be the only outstanding issue. I've tested this version with two unix based sites running and 3) and all seems to work fine there. That's not to say that differences in hosting environments might come into play introducing yet more "undocumented features" :-P Paul
  24. Just a thought for those who have been trying these versions as we go along. As of 0.6.2 clicking uninstall will remove the old configuration values and let you install the module again "fresh". It is probably a good idea to do an install->uninstall->install loop just to make sure you're starting from scratch again Paul
  • Create New...

Important Information

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