Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. I just tried the 1.2.1.0 gsitemap module and it still appears to be broken? Anyone else tried it? Paul
  2. That's weird. What version are you using? I've tested only up to 1.2.0.8 (can't keep up with testing these days with the increased update rate!). I'm upgrading my test stores to 1.2.1.0 at the moment so may discover the problem before I see your reply ;-) Another thought is whether you;re using the default settings? The "transparent" mode for example just gives me a blank box on my browser (the setting was copied unmodified from the WP original). Trying the legacy mode setting may also be worth a shot, depending on what version of the flash plugin you're using. Paul
  3. Does anything show when you enable the original tags module? Paul
  4. The PayPal API module is just a better way of doing the same thing - so there's no point in having both! In terms of what your options are... what do your "competitors" use? Paul
  5. Are you sure it isn't available in Latvian? I know that PayPal do support it as a language (well certainly as far as their documentation is concerned! As a test, you can try editing the paypal.tpl file in the "standard" PayPal module. Find: <input type="hidden" name="bn" value="PRESTASHOP_WPS" /> Which should be near the end of the file, and insert the following line immediately AFTER it: <input type="hidden" name="lc" value="LV" /> And see what happens :-) Paul
  6. Nope, seems that was my mistake - I assumed it would have been implemented in the new PayPal API module, but apparently it isn't. I've got code on my site to allow you to use DirectPayment - however you need to sign up for a PayPal Website Payments Pro account to use it in anything other than the sandbox! IIRC it costs about £20/month and you MUST implement PayPal Express checkout alongside it (i.e. still offer payment by PayPal, but specifically using EC). The code on my site also doesn't support the extra fields required by some UK cards. Paul
  7. I was under the impression that the new PayPal API module supported DirectPayment (Web Payments Pro)? If not then the one based on my DirectPayment stuff will work. Paul
  8. That would be great! Many people come on here, ask questions then disappear - so the next person never gets the benefit of the experience :-) I keep meaning to write an article on how it all works and why it doesn't always do what you expect - I think it might be useful for folks. I also meant to revisit my version and update it with some of the enhancements people have made to it :cheese: Paul
  9. Website Payments Pro requires additional monthly payment to PayPal (Direct Payment allows you to accept credit card payments without the customer leaving your site). In effect it's a merchant account. As far as I'm aware it does support this, but haven't tried it personally Paul
  10. Looking at the changelog, then no it doesn't look like it - they may have made changes something in the core, but there doesn't seem to be any clues in the changelog. Looking at the code, there have been changes made that may fix it (they appear to manipulate the $_SERVER['SCRIPT_NAME'] prior to calling Link::getLangageLink() now), but as always you'd have to test it! The fundamental problem appears to be the method used to re-write the urls. It works on a "real" page by using the current page and server variables - however - when you try to generate them from the back office, these variables don't make "sense" to the Link::getLangageLink() function call (it assumes that these are "valid"). This is why these "constants" have to be manipulated. I would have liked to see the Link class having the tools required to generate an "friendly" SEO url based on the link type (e.g. Link::getProductLink() should return a full "friendly" url to the product optionally including the protocol and domain) cleanly. They've added the images in there though -- why? I have no idea really, as I wouldn't have though that this was a particularly good thing for your store, unless you sell your own products. One of the things I do on sites is to block the Google image crawler as it makes it too easy for folks to search for and then link to your images and steal your bandwidth I think it might be a good idea for me to rename my version of the module, and for my own purposes at least I'll keep maintaining it I think. It would be good to have the ability to add support for other non-official modules at the very least, and add some configuration to customise the behaviour (e.g. allowing you to change the priority settings). Paul
  11. The "under review" happens in real life too - it usually means that the funds are being drawn from a bank account, and the usual result is an eCheque payment etc. All the 1.4 module looks for is a successful "normal" completed paypal instant payment notification - anything else and it doesn't work I'm afraid. I started work on the Paypal v2beta module of mine (you'll find it on my site) as a work-around to let the module gracefully handle the other notifications that PayPal might send, and also to get around a problem whereby the order isn't even created until your store receives an IPN response from PayPal - this can be 10 seconds to 24hrs after the customer has paid -- until it arrives at your store the products remain in the cart, and no order is visible in the store to you or your customer (and neither are any emails sent). I understand that the PayPal API module in 1.2 does work well though, so it may be worth investigating that. Paul
  12. Ok - the problem is that the way this is implemented in PrestaShop is rubbish :zip: The constants for the order status is in /config/config.inc.php (they start at line 101 in the 1.2 version I'm looking at right now). Now, these constants actually map to the id (key) of an order status record in the database.... You actually have to create the status yourself and store the (database key) constant in your module (in the module configuration). If you go to my site and download the PayPal v2Beta module you'll see in that an example of how I did a status for that module. The status is created in the install() function in paypal.php : //Create Order Processing Status if it doesn't exist if (!Configuration::get('PS_PAYPALPROCESS')) { $processPaypal = new OrderState(); $processPaypal ->name = array('Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment','Awaiting Paypal Payment'); $processPaypal ->send_email = intval(1); $processPaypal ->template = array ('preparation','preparation','preparation','preparation','preparation','preparation','preparation','preparation','preparation','preparation'); $processPaypal ->invoice = intval(0); $processPaypal ->color = "lightblue"; $processPaypal ->unremovable = intval(0); $processPaypal ->logable = intval(1); $processPaypal ->add(); Configuration::updateValue('PS_PAYPALPROCESS',$processPaypal ->id); } The order status is then used in payment.php : $valid_order=$paypal->validateOrder(intval($cart->id), Configuration::get('PS_PAYPALPROCESS'), floatval($total), $paypal->displayName, $paypal->getL('to_paypal')); Now - there is a significant problem with this that I didn't come across until the upgrade to 1.2. Remember I said that the entries in config.inc.php were hard-coded mappings to the database keys? Well guess what happened when they needed to add more..... yup you guessed it - and the installer complained that the keys already existed -- because the autoincrement on the primary key had already allocated the ones hard-coded in the upgrade sql to my PayPal ones. Having these values hard-coded like that isn't great, and it's something that should be addressed.... Hope this helps anyway, Paul
  13. Can you PM me links to the store and the sitemap that's generated, and I'll have a look Paul
  14. If DirectPayment is implemented in the PayPal API module, then yes it is. Paul
  15. @quatangsangtao.com: It should just work when you turn it on, so no, there's no extra configuration required. I think though that there's a problem using this with non-latin character sets - it's a flash thing, so not something that's going to get fixed any time soon. I'll have a dig and see if that's the case, but I fear it just isn't going to work for you @kdk: Glad you found it
  16. @AlexH: hmm I think the problem has to do with the Global Server variables - the code removes the first bit based on the domain name configured in the store- it's a hack because 1.1 and 1.2 return different results from the Link generation functions; it obviously doesn't work on a local server- but shouldn't be a big issue unless you want you local webserver indexed @fab4_33: Missing CMS pages can be explained since, like the original - it looks in the cms_block table to determine which pages are "active" - I realise that many people create CMS pages for other uses, so that's something that probably needs changed. On the products.... the only thing I can think of is that you have products and/or categories marked inactive somehow? If that's not the case, then it's something we'll have to look at! Paul
  17. Yes, that's fairly typical, it seems the the time to get all urls index rises exponentially with the number of products. Paul
  18. One additional comment to the above is that it possibly doesn't have that hook there originally because it won't work there, or if hooked there it may cause problems with other modules that are assumed to have been loaded before. Paul
  19. I don't like the fact that there's no visual indication that there's anything in the shopping cart, otherwise a pretty clean, standard theme. Paul
  20. Looks like a module written for 1.1 being installed on a 1.2 store? Paul
  21. I would look in the validation class to check what the payment is typecast to. It may be that the variable type can't cope with such large numbers. Paul
  22. That's common to be honest. One of the things the v2beta one I wrote tried to avoid this problem by creating the order immediately, rather than waiting for the order notifcation (IPN) from Paypal. Your store will do nothing with the order until PayPal confirms the payment which can be minutes-->several hours (and as you've discovered most of a day). The products stay in the cart and there's no sign of the order in the customer's history until the IPN is received by default - which doesn't inspire confidence in your store since as far as they're concerned they have placed an order which hasn't "appeared". Paul
  23. Wasn't it? Strange as it's part of the PHP5 distribution, and was enabled in the php startup! We'll see if anyone else who uses it has a problem I guess. The sitemap I submitted for my demo store has 1 url indexed (the homepage I suspect) which bothered me until I realised I'd also turned on the "friendly urls" option for the first time before generating the sitemap I submitted.... Once Google catches up with those I should be able to continue my "experiment" on this and the canonical module. Paul
×
×
  • Create New...

Important Information

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