Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. I'm working on getting Wordpress to play nicely in Prestashop - just some template/display issues left to sort out and it will be good to go. I'm currently only displaying "posts" and "comments" on the PrestaShop homepage, and article listing in a side box; but my intention is to use it to create and edit the information pages (you could then disable the standard information pages sidebox, and use the wordpress pages instead). This way you'll be able to add as many as you like, and benefit from wordpress's built in editor, image uploading etc. etc. The functionality is similar to the current "Latest News" box, although for information pages it wouldn't be embedded along with the other homepage modules, as it is currently. Current work in progress version lives at Wordpress PrestaShop Module Test If the site doesn't display, then call back later, I'm probably testing out new bits of code on there Paul
  2. I've a prototype for doing this, but hit several issues with the images (needed to create a whole new image class and alter tables to get it to work). The way it works is to have a tab in admin where you can insert image/url pairs which are displayed in a sidebox at random as you navigate through your site. I'll have to visit it again, and see if I can't simplify the changes required to use it. It's just another module on my list to finish..... Paul
  3. Ah, no that's common, you clicked the admin button in the xampp control panel didn't you Ignore that or you'll get an access violation error when you click it..... - forgot about that one, sorry :cheese: Just use http://localhost/phpmyadmin from your browser and you'll be fine! All you need to do in the xampp control panel is click "start" each time you want to use the local server after a restart. Paul
  4. It's in fact not US-centric at all! Your problem may be more its European roots, but I sincerely doubt it Paul
  5. Ouch. not lucky are you? Did you install it in the default directory (c:\xampp)? To be honest I've even installed a different MySQL version and run it separately (so just started up apache from the control panel and not MySQL) and it's worked fine for me... Post the error messages and we'll take a look. Paul
  6. I would dump all the current php and mysql stuff first. It'll likely just get in the way. After installing xampp (it's fairly painless) I've found a couple of things that need to be done: 1) From the xampp control panel make sure that the svc boxes are unchecked for both mysql and apache (i've had problems running them as services, but no trouble at all starting and stopping them manually from this applet; best not to run them 24x7 anyway). 2) You'll likely need to edit the apache config file to enable extensions like mod_rewrite (i.e. edit c:\apache\conf\httpd.conf and remove the # from before the module entry) 3) Maybe edit php.ini to enable things like curl if required, although I think it works fairly well out of the box. Apart from that you should be good to go, and just fire up http://localhost/phpmyadmin and import your database, stick the files in htdocs and you're off! Any problems, just shout Paul
  7. Why not install XAMPP or an equivalent? Never has great success using Microsoft web servers with open source shopping carts..... you can get them to work, it's just not worth the hassle. Paul
  8. This is making me wonder if I've messed up the upgrade to my demo store, as the only way I've been able to affect the order of these blocks has been to uninstall them and install in the correct order.... I don't have an option to move them in the positions menu... Paul
  9. Or use NULL instead of a number and just get them all...... $products = $productClass->getProducts($lang, 0, NULL, ‘name’, ‘ASC’, false); Paul
  10. I had a look and the ini_set commands already have the at in front of them (meaning ignore errors). No idea why it doesn't work. Maybe try and locate the error logs? If you also create a file on your server with <?php php_info() ?> in it (call it phpinfo.php) and upload that to your server root and let us know where it is, that might give a clue. Paul
  11. the lines are only in there to help, and they may be hindering! You could prefix them with an at sign (the symbol won't display on the forum, even in a code block!) or just comment the lines out to see if that's causing the error.... Paul
  12. Not sure if I'm getting what you mean. Do you want one at the top of the list as well as the one at the bottom? e.g. http://prestashop.ecartservice.net/category.php?id_category=2 If so just add another line: {include file=$tpl_dir./pagination.tpl} In the listing template file e.g. category.tpl Paul
  13. A module written for the "product footer" hook would be the best way to do this without messing about with the core PrestaShop code. Paul
  14. Just because another piece of software does it doesn't mean it's a good idea. To be honest if you don't like what PayPal charge you for their services then don't use them! If you charge a fee for using PayPal on your site you will invalidate their Seller Protection scheme as a condition of this is that you do not charge additional fees for paying with PayPal. Why not set your pricing so that you cover these costs, and if someone pays by bankwire, then you'll make a little extra? Paul
  15. Well that's not entirely true, since the charges are based on your transaction volume. How do you handle charging the customer your costs for other payment methods? Paul
  16. This has been discussed a few times now; search is your friend :-) There are two issues: 1) If the order never arrives, then there is a problem with the configuration of the server. My patched version ensures that the correct return url is used, but should paypal be unable to execute the validation.php file, or your server be unable to make connections externally (due to firewall restrictions) then the transaction will not be confirmed, nor the order created. Even with the patch you will need to check these two situations out. Paypal module update for Version 1.0 Final 2) If the order appears eventually. PayPal can be slow at times, and the order creation waits for a confirmation from Paypal. The version 2 BETA of the payment module tries to address this, but is still fairly experimental. PrestaShop Paypal Module v2.0 beta 1 Paul
  17. You can currently set the product meta tag in the product screen, but have to do each product manually. To do what you would like, it may be best just to use SQL to populate this field with data from the product description field(s). The only problem is that if you have html in there it won't be valid (the meta tag should contain plain text only). Perhaps a script to get the description, strip out any html and replace invalid characters, then copy the data into the meta_description field? It's all done in the _product_lang table..... Paul
  18. They don't support ini_set() though I don't think. Could just be an error on the page causing it to fail. Have you tried looking in the server error logs? Paul
  19. I apologise for my previous, perhaps overly harsh words. I was having a bad day :cheese: I agree that communication has been a little thin on the ground - but Peter has already put his hand up to that, which I for one give him due credit and respect for. I'm happy to wait for the next release, but like you would like a little clue as to what may or may not be changing (at the very least). Regardless, I'm sure it will be worth the wait - so no pressure guys :-) Paul
  20. This is getting a bit silly. Some of us are talking about having access to the incomplete update so that we can better support our own code when the full release is made. End-users who want things NOW just have to wait I'm afraid. The same folks would probably be the first to complain loudly on the forum about bugs if the next version was released before it was ready.... It takes a lot of time, effort and skill to produce complex quality software such as this. If you want to be able to better control the development timetable, then go and pay to have a shopping cart written for you. Paul
  21. I think that it's probably smarty that has a problem with it. Try using {literal} ... {/literal} wrapped around your code to prevent smarty from trying to parse it. Paul
  22. I'm not sure it's that bad, just needs a little care in implementation. If I understand it correctly, then you only need to worry about getting the tax calculation correct (in terms of rounding) from the perspective of the originating (shop) country, and not the customer's country. Using the scheme in the Google API is probably as good a one as any, given that they've probably done the hard work and worked out the required combinations If my shop in the UK sells something to you in France, then I would charge 17.5% UK VAT and use HALF_UP, PER_LINE rounding. It doesn't matter that the French VAT rate is different, nor that the rounding policy may also differ (although I'm not sure if there's an EU standard). The tax that should be applied (within the EU) is the one for the local country, and the tax rules to follow are the local ones. The implication is that the cart needs to know which country it's in, and from that determine how to round prices. It would still be a pain to implement, since everywhere there's a tax calculation you'll need to call either a Tools or Tax class member function to do the multiplication. Not impossible. But, of course, I could be wrong Paul
  23. There are two main reasons I can think of: 1) PHP4 is now unsupported, so is likely to disappear from most hosting packages (the only reason it's still there is a combination of apathy and backwards-compatibility with some really ancient/poorly written code). 2) The majority of the nice functionality offered by PrestaShop is enabled through the use of new features which were introduced in PHP5. Having to get these same features working in PHP4 (duplicating the work of many others) would slow development down to a crawl. :-) Paul
  24. Rod_ You have to add the form code in sendtoafriend.tpl to capture the data from your customer, which I think you've already done. To include this new field in the email, there's only a couple of additions you'd have to make: 1) In sendtoafriend.php at around line 59 you'll see: $templateVars = array( '{product}' => $product->name, '{product_link}' => 'http://'.htmlspecialchars($_SERVER['HTTP_HOST'], ENT_COMPAT, 'UTF-8').$productLink, '{customer}' => ($cookie->customer_firstname ? $cookie->customer_firstname.' '.$cookie->customer_lastname : $this->l('A friend')), '{name}' => Tools::safeOutput($_POST['name']) ); If you've created a text input field "comments" for example: <input type="text" id="comments" name="comments" value="{if isset($smarty.post.comments)}{$smarty.post.comments|escape:'htmlall'|stripslashes}{/if}" /> You can pass this to the email template by changing the above original code to: $templateVars = array( '{product}' => $product->name, '{product_link}' => 'http://'.htmlspecialchars($_SERVER['HTTP_HOST'], ENT_COMPAT, 'UTF-8').$productLink, '{customer}' => ($cookie->customer_firstname ? $cookie->customer_firstname.' '.$cookie->customer_lastname : $this->l('A friend')), '{name}' => Tools::safeOutput($_POST['name']), '{comments}' => Tools::safeOutput($_POST['comments']) ); It may also be an idea to validate the input, but it isn't necessary if the field is optional. If you format the email to assume it's optional, then it won't look strange if someone doesn't fill in the field. 2) Modify send_to_a_friend.html and send_to_a_friend.txt in the mails directory to include the new field in the email. Hope I've got that right! Paul
×
×
  • Create New...

Important Information

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