Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. Mike, when you say that nothing has changed are you absolutely certain your hosting has not had software or configuration changes made (by your hosting provider)? http://curl.haxx.se/mail/lib-2010-06/0169.html To save you getting a sore head: Paul.
  2. It's not really practical because of all the separate template components, modules and dynamically generated content. What you could do is to save the source of the different pages and visually edit them (and the associated css files) to work on the layout, but once you'd finished you'd need to translate markup changes back into the smarty template files. Of course, if you're happy with the markup and only want to edit the css, then using the source of generated pages should work just fine for you. I haven;t found a wysiwyg editor I've been happy with though, so tend to just use a text editor for it all, and a browser to preview.... Paul
  3. If you go to phpmyadmin via your control panel, then you can delete the tables in the database. You'll have to run the installer again of course, this time as a fresh install. You can get it to start from scratch by deleting the config/settings.inc.php file. For your question about a suggested feature you can go here: http://www.prestashop.com/bug_tracker/report/feature/ Paul
  4. If you;re using your own theme then you should go the the back office and select "Use Smarty 2 instead of 3" to yes OR reset the theme to thenew 1.4RC1 default. If you're not, then there's something else entirely wrong. I find that enabling logging of php errors to a file is useful in these cases, some hosting plans allow you to view the error from your control panel. Paul
  5. Sometimes being able to do something isn't the same as whether it's a "good" or "wise" thing to do. If you can, then I suggest that you create a separate database for your Prestashop install. If you do not, then for example one issue that you may face is that if you ever need to restore from backup, you have to restore everything - and usually lose content from everything. Lets say you mess up your store after adding lots of content to Joomla. If you restore them in a shared database back to a point that recovers the shop but not the joomla content, then that would be something of a disaster for you I would think. If they were in searate databases you can backup and restore them independently - you'll also find that the database exports you take are more manageable too. Paul
  6. That will allow you to see php errors but if it's an http 500 header response, then it won't show up.
  7. Where do you get the 500 error when the permissions are set to 755/644? You said that modules/paypal/validation.php gives you a blank page and not a 500 error? The reason for not getting an IPN usually falls into one of three scenarios: 1) PayPal are unable to connect to the modules/paypal/validation.php script to send the notification (if this responds with a blank page when navigating to it, then this is unlikely). 2) The validation.php script calls back to the PayPal site to verify any IPNs it receives (to ensure that they are genuine). If your server is unable to verify the IPN with PayPal, e.g. it cannot make external connections due to a firewall, then the notification will fail. 3) In some cases everything is working, but IPN notifications are delayed. This will usually resolve itself eventually, but means that the customer order appears to not have been acknowledged for an extended period of time (Paypal IPNs can be delayed for several hours). The v2 beta module was intended to mitigate this. Paul
  8. You should never, ever set a php file to 777 on your server. Ever. The directory should be 755 and the files should likely be 644. Test by executing the validation.php file in the paypal module directory to ensure you get a blank page (and obviously no 500 error). Most modules do not require that their directories or any associated file be writable To use the sandbox you must register for a sandbox account and log in before testing. Within the sandbox you will also need to create a merchant and test customer account in order to perform testing. The PayPal sandbox has numerous guides which will help in setting up your test accounts correctly. Paul
  9. That's a bit strange. The only thing I can think of is that its timing out, although that's not very many products really. Do you know what the php settings are for your hosting? The only other suggestion I can make is to enable error logging (to a file, not the screen) and maybe send me the errors you gen in there via PM and I can try and work out what's happening. Paul
  10. Prestashop uses jpg for all the product images. When you upload them it converts to jpg (with, by default, a white background) and creates the various "thumbnail" etc. images. Paul
  11. Ah of course, in my case it was. Hmm. Are you setting the size of the iframe? Thinking about it, surely these maps are always a fixed size? Your screenshot is showing the whole google page though rather than just the map. did you use the code provided by google when you click the link symbol at the top right of the map image on the page?
  12. Some browsers (Safari vertainly used to) don't encapsulate the whole content by default, but require you to specify the size. I ended up using some javascript to resize the iframe after loading to get it to work consistently. Dynamic drive might have what you need: http://www.dynamicdrive.com/dynamicindex17/iframessi2.htm Paul
  13. You can probably override the paypal .tpl file that displays the link and duplicate the code with the different wording in the second one. Not tried, but worth a shot
  14. You can override the xhtml part of of the addstuff.tpl (make a directory in your theme folder called addstuff and put a copy of addstuff.tpl in there. By default addstuff.tpl contains (0.6.3): <!-- MODULE Addstuff --> {$addstuff_code} <!-- /MODULE Addstuff --> {$addstuff_block_class} will either be nothing or the standard Prestashop class .block This is enabled/disabled in the module configuration (show in box). You can omit it completely in your own tpl file as you're not using either side bar. In your copy of addstuff.tpl (in /themes//addstuff) you can put whatever markeup you like to style your horizontal div e.g. <!-- MODULE Addstuff --> {$addstuff_code} <!-- /MODULE Addstuff --> Just add defninitions for #addstuff-header{} and .horizontal-stuff{} as required Paul
  15. With virtual terminal you could just use the offline credit card one. Otherwise there's a user contributed PayPal Web Payments Pro one. Paul
  16. How are you paying for these test purchases? Likely payment module related but you're not giving much away Paul
  17. Can I ask why you're using it? Are you running an affiliate store, and not actually selling anything? I would use AddStuff to move it to where you want. Just put the code in the mystuff.html file and you're done. I would be interested in your answer to the above though Paul
  18. They will be highlighted in the integration console. The best option is to set it up in the Google sandbox environment and try and get it to process transactions (you don't need an ssl callback for the sandbox, http is fine). It will soon tell you what you're doing wrong. Specifically you're looking at a) format of the cart sent, ability of Google to call-back your site, c) authentication of callback, d) correct handling of the callback updating the store. Paul
  19. While i fully agree that the firednly urls will give you a boost I'm always wary of implementing something too early that might bite you later. There are lots of things you can be doing first, and then they will be implemented in a well-planned manner which will give you an even bigger bang for your buck Sometimes trying to do everything at once doesn't yield the best result. Paul
  20. A Basic setup will be at least one server plus storage. Commercial grade hardware-based firewall. 2 x 512Mb internet connections with static IP, to maintain uptime these should enter the premises via diverse physical routes. Backup server, there are many network storage based ones now that can recover to within the hour and run continuously. UPS+conditioning. Generator in case of power problems, Air-con and fire protection. Spare hardware to recover (second server would mitigate the need to hold so many spares). Skills: Advanced : System administration, firewall installation/configuration, network troubleshooting, mail server configuration and troubleshooting, DNS troubleshooting. Any mistakes will be all for your own account. Answer. To do it "properly" even to the standard of a low-grade package bought from a reseller at $4USD/month is just far too expensive to be worth it. You might also need to consider little things like of-site backup, insurance etc. I doubt your household insurance policies will cover you. Paul
  21. Hmm looking at the permissions first, as it applies equally to GC and PayPal. Are you certain that every directory right down to /modules/paypal/ is set to 755? e.g. /var, /var/www, /var/www/html, /var/www/html/modules etc. 666 or 644 should be fine for the files, but never an odd number as that signifies executable which most servers should fail on. The key is to get the following to show a blank screen: www.example.com/modules/paypal/validation.php Until you can do that, then you won't get anywhere. I've posted on the subject of php over cgi with GC in here before so have a search (it could be 1yr+ back). Like I said though. One step at a time. Paul
  22. Best advice I could give you is: 1) Type your domain (without the www. prefix) into Google search and check your site actually appears in the first page. If it doesn't then you need to do a bit of work, and try and find out why. Find out why yourself, seeking guidance as appropriate. This will stand you in good stead for the future. 2) After creating your sitemap (e.g. sitemap.xml in your web root folder) add the following to your robots.txt file in the site root (if it exists). If you don't have a robots.txt file create one to put this in: SITEMAP /sitemap.xml EVERY good spider checks for a robots.txt file in sites it "discovers" and those that support the sitemap protocol (most important) will pick up your sitemap without you having to do anything else. Your web stats will show a drop in 404 errors after adding this file if it wasn't there before. Those were caused by spiders looking for it. 3) Sit back, relax and don't worry right now about stopping anything from indexing anything. The time for fine tuning is WAY down the line. I would recommend NOT using search engine friendly links now. Wait until you've a better understanding of the principles and your site and your customer demographics. Fixing them later is a pain and a load on your server (tomerg does have a tool you can use if you do shoot yourself in the foot though!) 4) Make sure your site is listing somewhere appropriate and preferrably popular. Don't worry about page rank or "nofollow" or anything else. Just mention your site in a relevant posts or link from appropriate respectable resource/directory sites. Do not spam. 5) Don't listen to "experts" who seek you out offering to sell you sure-fire ways of improving your SERPS -- they will only take your money. 6) Try and experience your site as a customer would and question the rationale for everything. Remove things you added just because they were "cool" but that actually don't add anything to the shopping experience. 7) Enjoy life Good luck, Paul EDIT: I missed an important one as tomerg had already mentioned it, but 301 redirect your non-www domain to your www domain and select the www as the preference in webmaster tools. If you don't use webmaster tools sign up and over-analyze everything. Sign up for the Yahoo and Microsoft equivalents too.
  23. I'm puzzled. Your thread is about Google checkout, but you mention problems connecting back to a script in the paypalapi module directory. You also sell hosting but are asking questions about a 500 error and permissions..... Ah well. Ours is not to reason why .... Likely it is the permissions causing the 500 error. 777 on a directory is world writeable. Not a show stopper but so very uncool/dodgy should any scripts happen to get on your server. Try 755. Fot files, 777 is read/write/executable by everybody, even though most of the files (in fact probably all) aren't executables. With the directories set to 777 too there's a huge risk now that one of those gets replaced by a REAL executable - BOOM; you're a Warez site. Do yourself a huge favour (not to mention the potential virus and spam victims) and use 644 for files. 600 for config files if your host will allow you to get away with it and php doesn't run as your uid, 440 or 444 otherwise in order of preference. Many of the Prestashop core files (including templates) could be set with similar strict permissions. use 777 (for directories) and 666 (for files) only as a very last resort. Not sure about the google checkout problem, since the symptom you describe doesn't make sense (failing at /modules/paypalapi/payment/submit.php). Maybe it's a type in which case you need to look at the server config (php running over cgi maybe?). Change the permissions first though. Like now. Filezilla has a nifty recursive permissions facility - it will save you hours of messing about using that, although there's a lot of individual files there it will have to go through. Recursively set the permissions to get you back on a decent starting point, and then (if necessary) modify the permissions recommended in the install guide (but don't go for 777/666, try something stricter until it works i.e. for directories 755 (not ideal but ok) -- 775 (pretty cool) -- 777 (rubbish), for files 644 (not ideal anyway)-- 664 (probably the sweet spot) -- 666 (please no) Have fun. You thought PayPal was bad -- you ain't seen nothing yet Paul edited as the forum decided to reinterpret what I wrote. Doesn't like ->
  24. Actually in this case I think I know why it's happening. In the payment return the cart uses the ordering currency in the calculations - and currently you've set it to Rupees. I think if you set the payment preferences such that the PayPal currency to use is the store default one and set the store default to USD it will work. The only downside is that the customer will need to click a button when they view your site to see the prices in the local currency. The trick is to send PayPal an amount in a currency it supports and it will work. PayPal does tell you what currency the numbers it's returning are in, but I think the module currently ignores that and assumes it's the same as the store order currency. Paul
×
×
  • Create New...

Important Information

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