Leaderboard

You can use the router to add backwards compatibility with the CE IPN URL Add in your config/routes.php Router::route("^my/old/callback.php", "callback"); replacing my/old/callback.php with your old CE url. This only works if your Blesta installation is installed exactly in the same domain/subdomain that your old CE installation.

Not sure if this will help. Try this: Log into PayPal and update your IPN URL (I am assuming you have not): Profile -> Profile and Settings -> My Selling Tools -> Instant payment notifications change the URL to the gateway callback. -Adam

Yes, WHM API 1 (not 0). cPanel has a few SDKs. Their official one is only for XML responses https://github.com/CpanelInc/publicapi-php But they also support JSON. All API functions support XML and JSON. If you look at their confluence page for all SDKs, they provide sample Perl and JSON code. Example: https://documentation.cpanel.net/display/SDK/Guide+to+API+Authentication+-+API+Tokens Here a list of 3rd party cPanel libraries. PHP is included. https://documentation.cpanel.net/display/SDK/Quickstart+Development+Guide+-+Libraries -Adam

Have you added a redirect in your .htaccess file? Redirect 301 /modules/gateways/callback/paypal.php /callback/gw/1/paypal_payments_standard/ Replace the first path to that which your CE install uses, and the second is the one for Blesta. The "1" in the path denotes company ID 1. If you don't have any addon companies, then it's just 1. Assumes you have Blesta installed in the doc root / so if you have it in a sub-directory like /billing/, then prepend that to the path. Blesta will try to apply the payment by matching the email address to an account. If the email address does not match, it will not be able to apply the payment.

Yup. Its in the core of Blesta: app/app_model.php. Alternatively, do not use date('c') but perhaps a timestamp (UNIX/epoch, etc.). One could make the argument to the Blesta guys that they should be checking the errorCode of a PDOStatement->execute within minPHP either in Records class of their PdoConnection class. http://php.net/manual/en/pdostatement.errorinfo.php#refsect1-pdostatement.errorinfo-examples -Adam

Thats because all the core code uses the dateToUtc function: http://source-docs.blesta.com/class-AppModel.html#_dateToUtc The function basically converts: 2017-04-25T14:43:00+00:00 which as you know is ISO 8601 format (date('c')) to something MySQL understands as explained in their documentation: 2017-04-25 14:43:00 -Adam

Catched, has ben fixed for the next release .

Sorry for the spam, but I am pretty sure I know what is going on. The issue was right in front of us -- the datetime is invalid . You should really be using a timestamp (UNIX/epoch as an example). Blesta uses PDO statements to insert into the database. When you create a PDO connection, you get to set the 'sql_mode'. Blesta's minPHP framework uses the system's default settings. It appears your system does NOT have the following enabled (system wide): SET SQL_MODE='ALLOW_INVALID_DATES'; As mentioned earlier, when Blesta creates a PDO connection, it uses system defaults and not override anything for that session. Why is this important, because PHP's date('c') produces invalid datetime for MySQL. Its explained fairly well in their documentation: https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_allow_invalid_dates You can see it live from a system I created to reproduce the issue: MariaDB [datetest]> select @@sql_mode; +----------------------------------------------------------------+ | @@sql_mode | +----------------------------------------------------------------+ | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | +----------------------------------------------------------------+ 1 row in set (0.00 sec) MariaDB [datetest]> INSERT INTO test (id, col1) VALUES (NULL, '2017-04-25T05:04:57+00:00'); ERROR 1292 (22007): Incorrect datetime value: '2017-04-25T05:04:57+00:00' for column 'col1' at row 1 MariaDB [datetest]> set @@sql_mode='ALLOW_INVALID_DATES'; Query OK, 0 rows affected (0.00 sec) MariaDB [datetest]> INSERT INTO test (id, col1) VALUES (NULL, '2017-04-25T05:04:57+00:00'); Query OK, 1 row affected, 1 warning (0.01 sec) MariaDB [datetest]> show warnings; +---------+------+-------------------------------------------+ | Level | Code | Message | +---------+------+-------------------------------------------+ | Warning | 1265 | Data truncated for column 'col1' at row 1 | +---------+------+-------------------------------------------+ 1 row in set (0.00 sec) MariaDB [datetest]> select * from test; +----+---------------------+ | id | col1 | +----+---------------------+ | 10 | 2017-04-25 05:04:57 | +----+---------------------+ 1 row in set (0.01 sec) MariaDB [datetest]> You will notice that datetime format is different then what we inserted because date('c') from PHP is not accepted by MySQL. Again, issue is with your environment. Tricky to find if you do not have experience. -Adam

I fixed the problem with the CMS only adding "is_null" to the date_updated field, and works. I detected this problem only in PHP 7.0+ with MariaDB (With Percona or MySQL works fine) I guess that my solution probably will not work for you. But in fact IDK what is causing this problem. I found this problem in another plugins too. ->setField('date_updated', ['type' => 'datetime', 'is_null' => true, 'default' => null])

addy has changed the format fo date posted in database from $vars['date_added'] = date('c'); to $vars['date_added'] = date('Y-m-d H:i:s'); when we use the same date value, it work. the insertion is working ..... this is something totally strange ....

I think we have a bug with root directory, all the links are without separation for default language. We love the knowledge base article patch you have made, users can switch language and the KB article are switched with them . I think this should be default in support manager .