Jump to content

Paul C

Members
  • Posts

    801
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Paul C

  1. I could do it, but it means modifying the core prestashop files, which doesn't seem wise given that upgrades will no doubt be coming thick and fast over the next few months. Perhaps this is more a feature request to improve the "pretty url" function? Paul
  2. Again not solved, just working for the OP. I've done some digging and updated the "Solved" Bug in the bugtracker. http://www.prestashop.com/bug_tracker/view/225/ It also appears that the "upgrade" is responsible for the missing field in the table, rather than it being caused by users deleting bits of their database, as is suggested in the bug report.... Paul
  3. Your backup is trying to create the database again then, which it shouldn't when you're in a shared hosting environment. Now, it will depend on which version of phpmyadmin you have, but when you go to create the export, do the following: 1) Select the database you want from the dropdown list in the far left column 2) Click the ""Export" tab in the main right-hand pane. 3) In the export dialog all the tables should be selected in the list (make sure they are) and check the following (and only these) 3.1 Structure 3.1.1 Add AUTO_INCREMENT value 3.1.2 Enclose table and field names with backquotes 3.2 Data 3.2.1 Complete inserts 3.2.2 Extended Inserts 3.2.3 Use hexadecimal for BLOB 3.3 Export Type : INSERT (Note that You'll need to check "Save to File too") An alternative would be to load up the SQL you've already exported in a plain text editor and remove the section that has the CREATE DATABASE statement block in it. You're trying to import the tables but NOT re-create the database, if you get what I mean. Paul
  4. I'm not sure why you're trying to create another database if all you're trying to do is upgrade? There's no need. If you want to make another copy, then usually on shared hosting accounts you create the database via your cpanel (and not in phpMyAdmin). So the steps to make a duplicate database would be: 1) in cPanel (or your equivalent) create the new database 2) in phpMyAdmin select the old database and click export, then check the box at the bottom that says "Save to File" 3) Go to the new database (the one created in step 1) and click import, then upload the file saved in step 2 Done. If you just want to upgrade, then perform step 2 above to make a backup, and follow the upgrade instructions detailed here: http://www.prestashop.com/wiki/Getting_Started/#Update_PrestaShop Paul
  5. Actually you could try doing: INSERT INTO ps_employee (id_employee, lastname, firstname, email, passwd, active, id_profile) VALUES (NULL, 'YOURLASTNAME', 'yourfirstname', '[email protected]', md5('letmein99'), 1, 1); INSERT INTO ps_contact (id_contact, email) VALUES (NULL, '[email protected]'); you'll need to replace with the long alphanumeric string (without quotes) that you'll get from a line similar to: define('_COOKIE_KEY_', 'DweKR6zKDfXq5oiqrKk63MX4VGDyi8FKXKHMTUk2pwp6eoRYkwi6By9j'); That you'll find in /config/settings.inc.php Paul
  6. Right there's a problem with the above, because I forgot about the shop cookie factor! The code with your email in it would be (stil need to change your name though): INSERT INTO ps_employee (id_employee, lastname, firstname, email, passwd, active, id_profile) VALUES (NULL, 'YOURLASTNAME', 'yourfirstname', '[email protected]', '0325c2ca24927160580c625cb01dd596', 1, 1); INSERT INTO ps_contact (id_contact, email) VALUES (NULL, '[email protected]'); Now that won't let you in as the encrypted password won't be right. Once the above is complete though, you should be able to change the password using the details here: http://www.prestashop.com/forums/viewthread/4843/installation_configuration___upgrade/lost_password_the_solution_is_in_the_forum_but_in_french Paul
  7. You also need to change the Class defiinition in the file, in order to create your unique module.... If you were to take the blockadvertising one as an example, at thetop of the file blockadvertising.php you'll find: class BlockAdvertising extends Module { function __construct() { $this->name = 'blockadvertising'; $this->tab = 'Blocks'; $this->version = 0.1; parent::__construct(); // The parent construct is required for translations $this->page = basename(__FILE__, '.php'); $this->displayName = $this->l('Block advertising'); $this->description = $this->l('Adds a block to display an advertising'); } You need to create a new class (a new module), so you'll have to change the first line at the very least. In order to prevent confusion I suggest you change the other values too, as these are what people will see in their Back Office Example: class MyBrilliantModule extends Module { function __construct() { $this->name = 'mybrilliantmodule'; $this->tab = 'Blocks'; $this->version = 0.1; parent::__construct(); // The parent construct is required for translations $this->page = basename(__FILE__, '.php'); $this->displayName = $this->l('My Brilliant Module'); $this->description = $this->l('This is a brilliant module'); } You'll also need to replace any other references to 'BlockAdvertising' in the original module files. Paul
  8. You shouldn't need anything in there - unless you have to use smtp to send mails. You should have entered the admin email address and password during the installation, and it should have been stored in there.... I'm guessing but it may be that the installer checked the admin email and there was a format problem with it. Instead of creating an error, it just didn't create the database record. Go to phpMyAdmin, select the database and try the following sql: INSERT INTO ps_employee (id_employee, lastname, firstname, email, passwd, active, id_profile) VALUES (NULL, 'YOURLASTNAME', 'yourfirstname', '[email protected]', '0325c2ca24927160580c625cb01dd596', 1, 1); INSERT INTO ps_contact (id_contact, email) VALUES (NULL, '[email protected]'); replace YOURLASTNAME, yourfirstname and [email protected] with suitable values (YOURLASTNAME is in upper case). Password will be: letmein99 Paul
  9. I'm trying not to give the obvious answer here You can go into phpmyAdmin and browse the 'ps_employee' table - just make sure that the email address in there matches the one you think you should be using.... Paul
  10. Hmm I think we're talking about different things. Before running the installer, there are two things you need to do. 1) Copy the files to your server (usually via ftp) 2) Ensure that the following directory permissions are set: Only then should you run the installer. The full installation instructions are here: http://www.prestashop.com/wiki/Getting_Started/#Install_PrestaShop Paul
  11. Did you set the permissions on the specified directories as per the installation instructions (they're on the download page)? Paul
  12. A blank page is exactly what you want! If you do a test purchase now, then it should work fine (although the order may take a little while to appear, as I indicated earlier). Paul
  13. As per the previous post, the module directories should be 755 (rwxr-xr-x) and all module files should be 644 (rw-r--r--). If that doesn't work, then there's another (server configuration) reason for it not liking that page, which is strange. Are you using the "friendly urls" option? Paul
  14. Or try raising them :-) It depends on semantics! 755 for directories /modules and /modules/paypal and 644 for validation.php should work. Setting the execute bit on files can cause server 500 errors. Paul
  15. Can you access the following page in your browser? http://www.example.com/modules/paypal/validation.php If so then the last thing to check is whether your hosting company firewall is blocking outgoing connections. To test, create a file called "paypal_test.php" containing the following: <?php /* Paypal connection test script for paypal payment module Author: P. Campbell Version: 1.0 ; August 2008 */ $fsocket = false; $curl = false; $result = false; $cURL_connect = false; // Test for curl support on the server if (function_exists('curl_exec')) { $curl = true; } // Try a secure fsockopen connection and if not, then the worst case insecure fsockopen // only use the insecure method if nothing else (secure fsockopen or cURL) works! // The insecure sock should be removed for production servers. if ( (PHP_VERSION >= 4.3) && ($fp = fsockopen('ssl://www.paypal.com', 443, $errno, $errstr, 30)) ) { $fsocket = true; } elseif ( ($fp = fsockopen('http://www.paypal.com', 80, $errno, $errstr, 30)) && (!$curl) ) { $fsocket = true; } elseif (!$curl) { echo 'Can\'t make external connections to paypal using any method.'; } // ***************To test curl when fsockopen works, uncomment the two lines below //$fsocket=false; //if ($fp) fclose($fp); if (($curl) AND (!$fsocket)) { $ch = curl_init('https://www.paypal.com/cgi-bin/webscr'); // If the above fails, then try the url with a trailing slash (fixes problems on some servers) if (!$ch) $ch = curl_init('https://www.paypal.com/cgi-bin/webscr/'); // Error checking if ($ch) { $cURL_connect=true; curl_close($ch); } else { $cURL_connect=false; echo 'Failed to connect to paypal'; } } if (($fsocket) || ($cURL_connect)) { echo 'Connection to PayPal OK'; } else { echo 'Connection to PayPal Failed'; } ?> Place the resulting file in the root of your server, then go to the following: http://www.example.com/paypal_test.php If your server communications with Paypal is working the above should print the message: 'Connection to PayPal OK' otherwise it will display 'Connection to PayPal Failed', or 'Can't make external connections to paypal using any method'. Let us know how you get on Paul
  16. Howdy there, I suspect what you'll find is that the purchases DO eventually appear, just not immediately when the customer returns to your store from paypal? I've been working on a much enhanced paypal module that should address this issue too, although it's slightly more complex, and I'm still testing the combinations. This problem is particularly severe when payments are made via eCheck or when the paypal payment is pending for another reason (e.g. if you haven't set it to automatically convert currencies in paypal and the customer pays in a currency other than your default). The way paypal works is asynchronously (it goes off and authorises the payment out-with the PrestaShop payment execution path). PrestaShop is synchronous in nature, so expects paypal to get there at the same time your customer does. The way the default paypal module works is that it creates the order when it receives the "Payment Complete" IPN, but it ignores all the other IPN messages..... It also doesn't even create the order until it receives this one single valid IPN. Even for instant payments straight from a paypal account this can be 30seconds or a few hours, depending on how busy the paypal service is! I'm attempting to get around this by creating a "Paypal Processing" status message and creating the order at the same time your customer leaves to pay with paypal. That way, you'll at least see that the order has been placed, and is awaiting authorised payment. I've also implemented the other IPN messages to update the order as it progresses through paypal. I hope to get at least a BETA version of this out this week. If you fancy testing it out to check that it's addressing the problem you have, then drop me a PM. Paul
  17. You can edit your robots.txt file (in the root of your site) and include the line: Disallow: /shop (Assuming that shop is the name of the directory you've used to put your work in progress PrestaShop installation). That will make sure NONE of your test shop will be included in the google (and most other significant) indexes. Paul
  18. To be honest I wouldn't use Word. I would suggest looking at a wysiwyg html editor like CoffeeCup instead. The html that word produces is, well quite frankly - rubbish ! There are several html editors out there at low cost (some even free) that are better for this job. Paul
  19. It does seem a bit "hidden" but language translations are a key design element in PrestaShop which I think gives it a great competitive edge. US projects tend to have such features as a "bolt-on-later" and they rarely work properly because of it! Many changing the name of the menu to better guide people to it would be a good idea. On the list of "Urgent New Features for PrestaShop" - Documentation is #1 I'm hoping to develop some nice guides from the information we're (still slowly guys!) collecting on the club forum. These can then be posted here too (in the Wiki?) for everyone to enjoy :-) Paul
  20. CJ you could do it that way, but I suggest you don't! In the Back Office (or Admin) you can enter this information by going to Tools-->Translations. Select your language by clicking the flag in the top section and you'll get a list of all the text items in the store with fields for you to paste YOUR version. The default contents are shown to the left of the input boxes. If you scroll down you'll see a section headed "conditions". You can change the title (e.g. to "Terms & Conditions"), the actual terms (default [Your conditions]) and a box called "Home" which allows you to change the link text at the bottom that users use to return to your home page. In the theme directory, where you see something like: {l s='Conditions'} That means that there's a substitution in the back office under translations (in this example it's the text "Conditions" as described above). Paul
  21. The tpl files in the theme directory can be edited at will, as they're expected to be different. The "standard" modules CAN be changed, but you do so at your own peril The template files use a library called "smarty" which separates your presentation (html) from your code (php). Information is passed to the template via variables (you'll see them in the .tpl files as {$Variable}. These variables can contain just text or a whole block of html. They can also be an array of items that can be listed out using smarty's macro language. This is quite handy if you're in to template design: http://hasin.wordpress.com/2006/06/10/smarty-cheat-sheet-version-20/ Any "text" you use for your conditions etc. (which will be inserted into the page via the template) should be able to support html formatting tags, but you don't create an entire html page, jus the bit to be "inserted". There's no need for <html> <body> or <head> tags, as that's all handled by the overall template page structure. Paul
  22. It's more that if you change the template files in the blocks, then your changes have to be made again every time you upgrade (potentially, it depends if there have been any changes to the blocks you've modified). Apart from a couple of specialised blocks that keep data within their directories (and probably shouldn't), most of the same changes can be made through the theme and css. If you want to display additional data, then a new block is the way to go. All mothods work, it's just a case of avoiding problems/work in the future! Paul
  23. I wouldn't do that. It makes it a pain to upgrade. Change the copy of the default theme you made instead..... you DID make a copy of the theme before you started changing it didn't you...... Paul
  24. I was having a look through, and this bit in validation.php puzzled me: $googlecheckout->validateOrder($cart->id, _PS_OS_PAYMENT_, $total, $googlecheckout->displayName, null, $currency->id); The member function in the PaymentModule class is defined as: function validateOrder($id_cart, $id_order_state, $amountPaid, $paymentMethod = 'Unknown', $message = NULL, $extraVars = array(), $currency_special = NULL) It looks like the currency object is getting passed via $extraVars to be included in the customer order confirmation email? Should it be passed as $currency_special instead? I'm still trying to get my head around the PrestaShop architecture.... documentation would sure be handy Paul
  25. Do you think it's a "new feature"? :bug: Why have a status of refunded, and then show the (now outdated) invoice in the orders history? I would say either update the invoice to show the refund, or kill it (in the case of a complete refund). Coding the payment module isn't the problem. Any code I (or anyone else) puts in the payment module will just be a kludge, which would have to be repeated in every payment module. The whole point of an object model is that you DON'T do daft things like that, surely? Cancelling an order correctly removes the invoice...... now where's the difference? :roll: Partial refunds (not currently supported in the core anyway) would be implemented no doubt as a new feature (which they are). Tey're probably a mundane but fairly essential new feature at that. I think I'll take a look at the credit slip things, and see what effect they have. May be possible to use these for full/partial refunds. Paul
×
×
  • Create New...

Important Information

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