Jump to content

omine

Members
  • Posts

    122
  • Joined

  • Last visited

Everything posted by omine

  1. yep! No problem Actually there's no files into "mails" folder. The email files are created within PrestaShop template system, on Back Office. by the way, you can create manually.
  2. No problem! Is named as beta version however is stable and safe. Currently, around 150 stores are using. I'm busy with many projects. I will try to upgrade epsilon modules this year.
  3. Hi Steve Joms! Glad to know you solved the first issue. At the field "オーダー情報発信元ホスト情報" just add the name of your host or the IP address. All others fields just leave empty. They are not necessary. The files epsilon.txt or epsilon.html do not exists and aren't needed. Example, the fields bellow, leave all empty: 決済完了後のリダイレクト 戻るボタンの戻り先URL エラー発生時の戻り先URL タイムアウト情報発送先URL
  4. Yes! There's a special version available for PS1.7 Still in beta version but fully functional. Currently, over 150 stores are using.
  5. I don't remember. My comment has 5 years ago and a lot of thing changed here in this forum. The position of posts and the layout... About 1 year later had the same problem as related here in August 29, 2014. After Since of then i never more found this problem again. Now i am using PS 1.7 Give a look on this thread: https://www.prestashop.com/forums/topic/320083-000-prices-problem-at-homepage-and-categories-page/
  6. 3 years later i have the same problem and found my own solution here.. PS 1.6.1.17 -> 1.6.1.20
  7. @DiverseSolution, just press F5 on your brower. Did you tried the solutions above? Clear the browser cache, normally solve this issue.
  8. Same problem here. PS 1.6.1.17 The problem happened before, randomly but the changed data has been saved. Now, do not save nothing and displays BackOffice: Property Address->date_add is not valid FrontOffice: 500 Server Error Oops, something went wrong. Try to refresh this page or feel free to contact us if the problem persists.
  9. I found the sql files into upgrade/sql folder This folder is inside a folder named "autoupg-inst-58e507769c2d0" After execute some obvious SQL files, i've entered on BackOffice. However, of course, nothing is working and have millions of errors, things not loaded, missing files, etc. I give up.. this version is too far to be reliable.
  10. Upgrading from 1.6.1.12 to 1.7.1.0 stuck on "Disabling modules now..." Before the "Database upgrade" action, 2 errors are displayed: Error while loading SQL upgrade file "index.php.sql". Error while loading SQL upgrade file "index.php.sql". (see attached file) Despite the error, i tried to access other pages but the authentication automatically redirects to BackOffice login page. I can see the version was changed to 1.7.0.1 but cannot enter . The login seems authenticating but something forcing back to login page again. When enabling the debug mode: PrestaShopDatabaseException in Db.php line 744:Table 'pe_jp_db.ps_authorization_role' doesn't exist<br /><br /><pre> SELECT `slug`, `slug` LIKE "%CREATE" as "add", `slug` LIKE "%READ" as "view", `slug` LIKE "%UPDATE" as "edit", `slug` LIKE "%DELETE" as "delete" FROM `ps_authorization_role` a LEFT JOIN `ps_access` j ON j.id_authorization_role = a.id_authorization_role WHERE j.`id_profile` = 0</pre>
  11. Got it! Edit the file "AdminSelfUpgrade.php" Original code (line 292): public static $skipAction = array(); Changed to this: public static $skipAction = array( 'backupFiles' => 'backupDb', 'backupDb' => 'upgradeFiles' ); On BackOffice page, will be displayed the notice:
  12. I'm trying to upgrade from 1.6.1.12 to 1.7.1.0 following this article: http://build.prestashop.com/news/prestashop-1-7-1-0-available/ Everything ok, but is not possible to change the backup options. I want disable them but the module do not permit. So, i started the upgrade anyway. The problem is, the backup process is terribly slow. Started has 2 hours and still saving the database data. The data, in text plain have about 1.2GB only. The backup is generating little splitted rar files Why so slow? I don't need the backup process. I always do the full backup in 10 minutes using some tools i developed. How can i skip the backup process?
  13. This error is caused by PHP execution time limit. Increase the time limit On php.ini (sample) max_execution_time = 600 (10 minutes) I also recommend to change others settings: max_input_time = 180 memory_limit = 300M max_input_vars = 20000 Of course, adjust the values according to your environment. If you are running under FCGI, checkout this topic: https://www.prestashop.com/forums/topic/498947-backoffice-displays-php-code/
  14. NemoPS, i have this module instaled and active Data mining for statistics v1.5.0 - by PrestaShop But yesterday i noticed the last log was in 2016 February. I have no idea why not saving the logs. I never turned off this module. My specific problem is about 1 customer making fraudulent orders with stolen credit cards. I need to send some details to local police department. I need more details like IP address, proxy, etc.. But as i said before, the PS native modules are not working.. And, even if was working, the log information is so poor .. not enough.. For example, saving only IP address and HTTP_REFERRER is not enough. The module datastats is not reliable. I'm building myself a new module.
  15. Same here. PS 1.6.1.6 I ckecked the tables connections and connections_source. The latest registry was done in 2016 February. Seems stopped to log on this table. The order details page do not show the source. Surprised to see there are no native modules for such very basic tool. BTW, we have a third party option: https://www.prestashop.com/forums/topic/303230-free-module-order-ip-address-verification-avoid-fraud-chargebacks-unhappy-customers/
  16. I upgraded from 1.6.1.4 to 1.6.1.5 today. The error happened again but this time i mitigated and found the causes. In my case, the specific website is running under apache mod_fcgi + CPanel. The error log was accusing "fcgid timeout". This error is simple to solve but the website is controlled by CPanel. So, is better make the changes within CPanel tools. STEPS 1. Login to WHM 2. Go to Service Configuration -> Apache Configuration 3. Select Include Editor 4. At PreVirtualHost Include select “All Versions” 5. At the text field write (you can change the timeout value with anything that suits your needs) <IfModule mod_fcgid.c> FcgidIOTimeout 360 </IfModule> 6. Save 7.Restart Apache from Restart Services menu Credits: http://dev-alert.com/how-to-deal-with-mod_fcgid-timeout-in-whmcpanel/
  17. Christian, i don't remember how was solved. Maybe after some PS upgrades fixed the problem.. i'm not sure. Currently, the problem do not happens to me. however, what you described sounds confused. What do you mean with "I've just imported my database from an old PS to a newer version" Did you imported an old database directly to the new PS version? Normally, this will cause many bugs and errors because the database must be upgraded too. The safest way to upgrade is by using the module 1ClickUpgrade (autoupgrade).
  18. I was having problem to upgrade PrestaShop since 1.6.1.1. The upgrade process was being interrupted with message 'Invalid database configuration.' Mitigating the problem, i found the reson on this file: /modules/autoupgrade/AdminSelfUpgrade.php The original code with my personal comments: //check DB access $this->db; // <-- this should be here? seems a mistyping. error_reporting(E_ALL); $resultDB = Db::checkConnection(_DB_SERVER_, _DB_USER_, _DB_PASSWD_, _DB_NAME_); /** Disabled to avoid the "Invalid database configuration" error while upgrading the PrestaShop. The variable $resultDB always returning 1 or different of 0. */ /** if ($resultDB !== 0) { // $logger->logError('Invalid database configuration.'); $this->next = 'error'; $this->nextQuickInfo[] = $this->l('Invalid database configuration'); $this->nextErrors[] = $this->l('Invalid database configuration'); return false; } */ After disable this code, the upgrade process finished successful. More detailed information I did search over all PrestaShop files, searching for "Db::checkConnection". The only file using this function is "AdminSelfUpgrade.php". I think this should be removed or fixed for next releases. Db::checkConnection invokes call_user_func_array() which in turn, calls the database library dynamically. public static function checkConnection($server, $user, $pwd, $db, $new_db_link = true, $engine = null, $timeout = 5) { return call_user_func_array(array(Db::getClass(), 'tryToConnect'), array($server, $user, $pwd, $db, $new_db_link, $engine, $timeout)); } The library is returned by Db::getClass() public static function getClass() { $class = 'MySQL'; if (PHP_VERSION_ID >= 50200 && extension_loaded('pdo_mysql')) { $class = 'DbPDO'; } elseif (extension_loaded('mysqli')) { $class = 'DbMySQLi'; } return $class; } This code returns different value on this same server. From BackOffice, returns DbMySQLi However, running the same script outside PrestaShop, on same server, returns DbPDO The PHP_VERSION_ID is 50528 and extension_loaded('pdo_mysql') returns boolean true. So, i don't understand why within PrestaShop BackOffice returning DbMySQLi. By the way, DbMySQLi::tryToConnect() code is: public static function tryToConnect($server, $user, $pwd, $db, $new_db_link = true, $engine = null, $timeout = 5) { $link = mysqli_init(); if (!$link) { return -1; } if (!$link->options(MYSQLI_OPT_CONNECT_TIMEOUT, $timeout)) { return 1; } // There is an @ because mysqli throw a warning when the database does not exists if ([email protected]$link->real_connect($server, $user, $pwd, $db)) { return (mysqli_connect_errno() == 1049) ? 2 : 1; } $link->close(); return 0; } The problem may be something on this method. Whatever, the simplest way was skip the $resultDB = Db::checkConnection to complete the upgrade. If someone face the same issue, this information can be useful.
  19. Found the the reason! The website is running under cgi mode. The default fcgi timeout was configured to 20 seconds. I just increased the timeout by adding this code on httpd.conf: FcgidIOTimeout 300
  20. The problem is intermittent. If has an PHP sintax error, the problem should be continuous.
  21. Some times, when i enter on BackOffice login page, the page displays a blank page with this: * @copyright 2007-2011 PrestaShop SA * @version Release: $Revision: 1.4 $ * @license http://opensource.org/licenses/osl-3.0.php Open Software License (OSL 3.0) * International Registered Trademark & Property of PrestaShop SA */ /* Send the proper status code in HTTP headers */ header('HTTP/1.1 404 Not Found'); header('Status: 404 Not Found'); if (in_array(substr($_SERVER['REQUEST_URI'], -3), array('png', 'jpg', 'gif'))) { require_once(dirname(__FILE__).'/config/settings.inc.php'); header('Location: '.__PS_BASE_URI__.'img/404.gif'); exit; } require_once(dirname(__FILE__).'/config/config.inc.php'); ControllerFactory::getController('PageNotFoundController')->run(); Normally, i "solve" by refreshing the browser F5, then, the login page reload and is rendered correctly. Sporadically, while navigating inside BackOffice pages, the same happens and i solve with F5 (refresh). The server is not running any cache system like opcache, memcache or apc. PS 1.6.1.1 OS: Linux CentOS 7 PHP 5.5.28 Cache options: File System (Recompile templates if the files have been updated) Apache/2.2.31 Interesting note, this always happened with PrestaShop on all versions. I'm using PrestaShop since version 4. But i never give importance. But now i would like to know if this is a bug or some misconfiguration. This happens not only on specific environment. Happens on any environment, any version.. Maybe some bug from PrestaShop compile cache system.
  22. Besides of this error, the order status was changed correctly. So, i noticed my configuration was running on debug mode. I changed back to define('_PS_MODE_DEV_', false); and the error do not displays.
  23. PrestaShop displays this error when try to change the order status: You can't specify target table 'ps_order_invoice' for update in FROM clause UPDATE `ps_order_invoice` SET number =(SELECT new_number FROM (SELECT (MAX(`number`) + 1) AS new_number FROM `ps_order_invoice`) AS result) WHERE `id_order_invoice` = 1 PS 1.6.1.3 MySQL 5.7 I think is the same problem described on this topic: https://www.prestashop.com/forums/topic/493398-mysql-57-causes-error-when-ps-try-to-insert-date-as-0000-00-00-000000/
  24. Found solution MySQL 5.7 default settings, sql-mode is sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" On MySQL settings file, add the line or edit if exists: sql-mode="NO_ENGINE_SUBSTITUTION,ERROR_FOR_DIVISION_BY_ZERO" Linux: > vi /etc/my.cnf > service mysqld restart
  25. I'm testing current PRestaShop version, 1.6.1.3, under MySQL 5.7 I found a bug on order confirmation page: "500 server error" After enable the debug mode, i could see the problem: Incorrect datetime value: '0000-00-00 00:00:00' for column 'invoice_date' at row 1 INSERT INTO `ps_orders` (`id_address_delivery`, `id_address_invoice`, `id_cart`, `id_currency`, `id_shop_group`, `id_shop`, `id_lang`, `id_customer`, `id_carrier`, `current_state`, `secure_key`, `payment`, `module`, `recyclable`, `gift`, `gift_message`, `mobile_theme`, `total_discounts`, `total_discounts_tax_incl`, `total_discounts_tax_excl`, `total_paid`, `total_paid_tax_incl`, `total_paid_tax_excl`, `total_paid_real`, `total_products`, `total_products_wt`, `total_shipping`, `total_shipping_tax_incl`, `total_shipping_tax_excl`, `carrier_tax_rate`, `total_wrapping`, `total_wrapping_tax_incl`, `total_wrapping_tax_excl`, `round_mode`, `round_type`, `shipping_number`, `conversion_rate`, `invoice_number`, `delivery_number`, `invoice_date`, `delivery_date`, `valid`, `reference`, `date_add`, `date_upd`) VALUES ('5', '5', '6', '1', '1', '1', '1', '2', '3', '0', 'af2c4771ba022eb69f1898c79858707a', 'Bank wire', 'bankwire', '0', '0', NULL, '0', '0', '0', '0', '5541.52', '5541.52', '5277.63', '0', '5270.63', '5534.17', '7.35', '7.35', '7', '5', '0', '0', '0', '2', '2', NULL, '1', '0', '0', '0000-00-00 00:00:00', '0000-00-00 00:00:00', '0', 'IRUIKTIKL', '2015-12-23 20:52:51', '2015-12-23 20:52:51') The test is running from fresh PrestaShop installation. No overrides, no third-party modules. All default settings. I found something regarding this issue with MySQL5.7 https://www.digitalocean.com/community/tutorials/how-to-prepare-for-your-mysql-5-7-upgrade Seems the 5.7 did some changes that may cause many bugs like this. How to solve or prevents?
×
×
  • Create New...

Important Information

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