Jump to content

darvidc

Members
  • Posts

    47
  • Joined

  • Last visited

Profile Information

  • Activity
    Agency

darvidc's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. Ok thanks, I'll try a test shop and look at the mysql query cache solution as well. Any tips on how I can test performance?
  2. Hi, I'm getting the following errors in my php "error.log" using PS 1.6.1.10 (was the same for 1.6.1.8). [08-Jan-2017 09:18:09 Europe/Stockholm] PHP Notice: Undefined offset: 62376 in /var/www/html/ps16/classes/PaymentModule.php on line 233 [08-Jan-2017 09:18:09 Europe/Stockholm] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/ps16/classes/PaymentModule.php on line 233 [08-Jan-2017 09:19:59 Europe/Stockholm] PHP Notice: Trying to get property of non-object in /var/www/html/ps16/classes/module/Module.php on line 2284 The first one seems to have something to do with carriers, in PaymentModule.php: foreach ($cart_delivery_option as $id_address => $key_carriers) { foreach ($delivery_option_list[$id_address][$key_carriers]['carrier_list'] as $id_carrier => $data) { foreach ($data['package_list'] as $id_package) { The second one seems to have something to do with currency, in Module.php: if (Currency::isMultiCurrencyActivated()) { $cache_array[] = (int)$this->context->currency->id; } They mostly appear with a purchase, although not always with the same payment module? The BO logs also gives the error: 4910 -- 1 Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart Cart 100021 0x0 2017-01-08 09:18:12 My shop has only English & Swedish installed and activated, but Swedish is the only language seen by the customer, there is no language block activated for such a selection! On the other hand, a Currency block is activated for the customer to choose between Kroner & Euro. All of my carriers have been added manually (and checked), no carrier modules are in use. I have not activated the main file Cache, although Smarty & CCC are activated. Can anybody help, any idea please? Thanks in advance. David C
  3. Thanks, but I'm running "Live" and I don't know how to do a debug without affecting the shop? I've know turned off the "FS Cache" and the above error and a couple of others seemed to have disappeared from the php "error.log". (I have one remaining error "PHP Notice: Trying to get property of non-object in /var/www/html/ps16/classes/module/Module.php on line 2284" which seems to have something to do with currencies, which if I can't sort it out today, I'll start a new thread for. I can't see any performance difference after turning off the FS Cache (I don't know how to check that either, if I could) but which of the other Cache methods would be recommended to try on my single Debian VPS?
  4. Hi Bellini13 I have created all of the carriers manually in my store. I havn't used any Carrier modules. David C
  5. Hi, I'm running PS1.6.1.10 (after updating recently from PS1.6.1.8) and during some payments I'm getting the following entries in the php error.log? [06-Jan-2017 13:54:23 Europe/Stockholm] PHP Notice: Undefined offset: 62345 in /var/www/html/ps16/classes/PaymentModule.php on line 233 [06-Jan-2017 13:54:23 Europe/Stockholm] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/ps16/classes/PaymentModule.php on line 233 If I then look at my "PaymentModule.php" (not Overridden in any way) it seems to be something to do with delivery and carrier data! See below Line 233 in red: foreach ($cart_delivery_option as $id_address => $key_carriers) { foreach ($delivery_option_list[$id_address][$key_carriers]['carrier_list'] as $id_carrier => $data) { foreach ($data['package_list'] as $id_package) { // Rewrite the id_warehouse $package_list[$id_address][$id_package]['id_warehouse'] = (int)$this->context->cart->getPackageIdWarehouse($package_list[$id_address][$id_package], (int)$id_carrier); $package_list[$id_address][$id_package]['id_carrier'] = $id_carrier; } } } Has anybody got any idea about this problem and how to fix it, please? Thanks, In Advance David C
  6. Hi, I'm having the exact same problem, in the log, "Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart" with every order and even when people have been in the cart and for some reason haven't gone through, which I don't know if it's because of the fault or not! There must be some one "out there" that knows the answer to this, looking at the forum it's been going on for several years now without a clear answer. I'm using PS1.6.1.8. I've regenerated .htacess, cleared cache etc. etc. ANYBODY !!! David C
  7. Hi, We've just updated to v1.6.1.8 and are experiencing exactly the same thing. Updating/changing of Product texts, pictures even moving products between categories dosen't work well. We've tried different browsers (with Ctrl +F5/Emptying Cookies), Switched off all CCC. Cache and Forced Complering etc. etc. it just won't work properly?? Do you mean "endriu107" that we have to change all the files from the link to Github to FIX this problem, or is an official fix coming out from PrestaShop soon? Thank for your time David C
  8. HELP, I'm going mad over this!! I'm testing an upgrading (a manual upgrade) from 1.4.11.1 to 1.6.1.5 and am getting the same "28" xml error (<action result="fail" error="28"/> and I KNOW its meant to mean that I'm trying to upgrade to the version that is already installed BUT that is not the case! Each time I run the upgrade, I delete everything and use an original 1.4 backup of the DataBase and files again. The important config file ("settings.inc.php") is then copied over with the other necessary 1.4 files again to the new upgrade folder holding the new 1.6 files, where it is then edited to point to the new test DataBase, disable cache, set base url and theme name etc. I don't touch the version setting "define('_PS_VERSION_', '1.4.11.1');", so it should reconise its an older/not the same version, during the upgrade! So why DOSN'T IT, why do I get error 28 when its not true!!! ??? Any ideas anybody? Things to note: Running on a Debian 8, VPS Permissions & Ownership on Files(644) & Dirs(755) are correct. A completly new DataBase, with new name, is created with phpmyadmin, everytime I try. These settings are put directly into the DB by an SQL statment, after import: PS_SHOP_DOMAIN "XX.YY.ZZ.SS" (not my real address ) PS_SHOP_DOMAIN_SSL "" PS_SHOP_ENABLE "0" PS_SSL_ENABLED "0" _PS_BASE_URL_ "/" I've also included my test "setting.inc.php" file as it is, placed in the upgrade folder, just before running the upgrade script. define('__PS_BASE_URI__', '/'); define('_MEDIA_SERVER_1_', ''); define('_MEDIA_SERVER_2_', ''); define('_MEDIA_SERVER_3_', ''); define('_PS_CACHING_SYSTEM_', 'MCached'); define('_PS_CACHE_ENABLED_', '0'); define('_THEME_NAME_', 'prestashop'); define('_DB_NAME_', 'ps1615'); define('_MYSQL_ENGINE_', 'MyISAM'); define('_DB_SERVER_', 'localhost'); define('_DB_USER_', 'root'); define('_DB_PREFIX_', 'amu_'); define('_DB_PASSWD_', 'XXXXXXXXXXX'); define('_DB_TYPE_', 'MySQL'); define('_COOKIE_KEY_', 'GA5tRnRO0ZbMmHdEIDkKQZwHLfQhHems0YrP71mnwII0EKFVmQSU1Aop'); define('_COOKIE_IV_', 'JQsZgUs1'); define('_PS_CREATION_DATE_', '2013-03-22'); define('_RIJNDAEL_KEY_', 'BS4ZBH5Y3DtEmJrQvUMIOdfP0xeP4dv9'); define('_RIJNDAEL_IV_', 'TkBqjTkzrvv7LGn6b653Cw=='); define('_PS_VERSION_', '1.4.11.1'); 4 Days of trying now ... help would be really apprecated. Thanks in advance David C settings.inc.php
  9. Hi, We've been running a shop now the last 8 years that allows both guest or registered customer purchases with the result we now have a customer base of over 30,000 customers on the books. Over those years the one big customer support question/problem, we've had to face time and time again is this with returning customers being confused by/the difficulty of purchasing again as a guest or a registered customer. If they've purchased as a guest before they can't become a registered guest (without contacting us). If they been a registered customer but now (for various reasons) just want to go through as a guest, they can't do that, they have to remember/find their old password (or ask for a new)! Both scenarios defiantly don't make a customer happy! So I ask the Questions: Why do we have to make it so confusing/difficult for the customer (if 1 person contacts us, I can guess 10 have given up)! Why then can we just not have a option in PS to have the choice of a "Guests Only" Cart also ???? I personally think the advantages outweigh the disadvantages. Do any of you know of a good, tried module that can achieve this? David C
  10. El, The situation is that we have a live site, with around 3000 articles (inc. variations) and over 20,000 customers registered, so as you understand I have to get this right :-) . I'm doing all of my testing on a VPS, in fact the server will most properly be the server we move to when it's time (by re-pointing the DNS to their name servers etc.) so your suggestions of using a test server before are really what I am doing all the time now ;-) What I will do tomorrow, is try, on the test server to upgrade from 10 to 11 and if it looks good, to save time, (I'll do backups first) do the same minor upgrade on the Live site! If it works on the test site, can you see any risk in that? (I have done minor upgrades before and they seem to have worked Ok) If that then works I'm left with a 11 ready for the major upgrade to 1.6.x. when its time. :-) The main thing here is to get a so clean major upgrade as possible (free from all the accumulated custom changes that have been made and modules that will no longer be used) that's why I've chosen the manual upgrade over the automatic "1-click Upgrade" I can keep it cleaner and then later remove unnecessary tables from the database. I must admit I'm still indecisive about whether to use an upgrade or a clean install of v1.6.x and then csv. import all the necessary order, product, customer info. etc? The only reason I haven't tested that yet is because I haven't found any good modules or good instructions to do that way! If you know of such a solution I would appreciate it, if you could point me in the right direction too. Thanks David C
  11. Ok, thanks for your reply. Where aiming to upgrade the "live" shop soon, so "downtime" is important and I would like to avoid adding more downtime by waiting for an extra step to complete but as you say maybe to get a clean upgrade I would have to upgrade to 1.4.1.11 first. This is why I asked if the error above is significant, as is seems to overwrite/correct itself and we aren't using multi-shops anyway, which I presume is what that particular DB table is for. Correct me if I'm wrong but I've a feeling, as the shops seems to work correctly after the manual upgrade, I think I can ignore the error, or am I wrong? BTW. Why is 1.4.1.11 so much better than 1.4.1.10, I've heard this from some where before? Can an "1-click Upgrade" to 1.4.1.11 be done with the minimal of worry then? David C
  12. Hi, I'm testing an manuall upgrade from v1.4.10.0 to v1.6.1.4 (because I want a cleaner install afterwards) by following the recommended upgrade instructions given in PSs documentation. The upgrade script (upgrade.php) works fine, with the except of 1 error (indicated by an error 34 at the top of the returned XML text). Ive isolated the error in the returned XML text, se below (in red). It seems to be a SQL call to ALTER and DROP a KEY "id_shop_group" in the newly created table "shop" that gives the error, that it can't be found ??? The strange thing also is that the next call the very same table is adressed again, this time to ADD the same KEY, without an error (in green) ? <request result="fail" sqlfile="1.6.1.0"> <sqlQuery> <![CDATA[ ALTER TABLE `amu_shop` DROP KEY `id_shop_group` ]]> </sqlQuery> <sqlMsgError> <![CDATA[ Can't DROP 'id_shop_group'; check that column/key exists]]> </sqlMsgError> <sqlNumberError> <![CDATA[ 1091 ]]> </sqlNumberError> </request> <request result="ok" sqlfile="1.6.1.0"> <sqlQuery> <![CDATA[ ALTER TABLE `amu_shop` ADD KEY `id_shop_group` (`id_shop_group`, `deleted`)]]> </sqlQuery> </request> I should say the shop seem to work perfectly after the upgrade ... Any ideas anybody? Is this a bug? Can this be found and corrected in the script somewhere? Do I even need to worry about it? Thanks in advance. David C
  13. Ok thanks Nemo and Vekia. I prefer not to change/override a core class, especially if it likely to "cause problems". I think I'll just have to go back to Klarnas own "Very Buggy" v2.1.2 module that still does every thing in English as well as have the ability to change my shops tax rules very time I configure it , plus I have to do a bit of a code change in their Core file ... Hard work!!!!
  14. Is there a work around, is the method needed in 1.4 or can it be added to the code?
  15. The PS Klarna module from Prestashops own marketplace says, I qoute " Compatibility PrestaShop v1.4.0.0 - v1.5.4.0" and to quote again further down in the text "By PrestaShop The module Klarna for PrestaShop has been developed by the PrestaShop team, guaranteeing full compatibility with PrestaShop's e-commerce software".
×
×
  • Create New...