Adam

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
 

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

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

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

If your hosting provider does not offer Mailparse, then find a different one. It is standard among good hosting providers. 
-Adam

Blesta aka Phillips Data is the maker for Blesta and minPHP. Please provide documentation to minPHP. If source-docs.blesta.com is not the right place for minPHP then let everyone one where the new place should be.
 

Your not using cPanel/WHM correctly.
Login to WHM Select Module Install Select PHP pecl Then search for mailparse Install  
I highly recommend you use CloudLinux with cPanel/WHM or even cPanel's MulitPHP Manager. 
https://documentation.cpanel.net/display/ALD/MultiPHP+Manager+for+WHM
Either solution allows you have cPanel accounts use different version of PHP. This is great for legacy applications that require specific versions of PHP or specialized setups.
 
-Adam

If your hosting provider does not offer Mailparse, then find a different one. It is standard among good hosting providers. 
-Adam

If your hosting provider does not offer Mailparse, then find a different one. It is standard among good hosting providers. 
-Adam

Hi folks,
Couldn't find this reported, however it seems there's a bit of an issue when attempting to install 4.0.0 using PHP 7.
It appears there's a syntax error when taking into account MySQL Ports
I've configured my development environment to use MySQL on port 13306 and entered the host as 127.0.0.1:13306
Installation works perfectly on PHP 5.6.23 (via FPM & CLI), however via PHP 7.0.18 it throws the following error:
SQLSTATE[HY000] [2002] Failed to parse address "127.0.0.1:13306:3306" Changing config.php to the host as 127.0.0.1 and port 13306 does not remedy this issue, as such it appears that I'm unable to use PHP 7.0 with MySQL from a fresh install.
Oddly enough an upgrade, admittedly on a slightly older php7 version, worked without issue.
Note: it was installed using 127.0.0.1:13306 in the host string, as there was no separate port, despite the configuration having a port option.
The exception is occurring on line 74 of core/ServiceProviders/MinphpBridge.php (the new PDO connection setup).

var_dump($dbInfo); shows the following data:
 
array(10) { ["driver"]=> string(5) "mysql" ["host"]=> string(9) "127.0.0.1" ["port"]=> string(5) "13306" ["database"]=> string(6) "blesta" ["user"]=> string(6) "blesta" ["pass"]=> string(6) "blesta" ["persistent"]=> bool(false) ["charset_query"]=> string(16) "SET NAMES 'utf8'" ["sqlmode_query"]=> string(26) "SET sql_mode='TRADITIONAL'" ["options"]=> array(0) { } } I've confirmed via debug that the data being input to new PDO is:

string(40) "mysql:dbname=blesta;host=127.0.0.1:13306"

Changing lines 64 to 74 from:
$connection = new PDO( $dbInfo['driver'] . ':dbname=' . $dbInfo['database'] . ';host=' . $dbInfo['host'] . ( isset($dbInfo['port']) ? ':' . $dbInfo['port'] : '' ), $dbInfo['user'], $dbInfo['pass'], $options ); to
$connection = new PDO( $dbInfo['driver'] . ':dbname=' . $dbInfo['database'] . ';host=' . $dbInfo['host'] . ( isset($dbInfo['port']) ? ';port=' . $dbInfo['port'] : '' ), $dbInfo['user'], $dbInfo['pass'], $options ); Resolves the issue, and the site is now operational.

This fix obviously relies on the port being explicitly set, so having a field to fill in that port is still required.

Edit: looks like it worked doing the upgrade because my other upgrade was on my other laptop, that runs mysql on 3306...

Any providers whose does not do this properly are garbage or simply "winging" their shared setups. Instead of blaming Blesta blame the incompetence providers whose don't enable it for you.  

Thanks Paul and of course the rest of the Blesta team.

It wasn't scheduled for v4 beta 5, it's just the affected version, likely the task was created during beta 5. It's currently assigned to the "Short Term" bucket, for further review and assignment. I'll consider your comments a +1 for the feature.

https://dev.blesta.com/browse/CORE-2364

I see that CORE-2338 was scheduled for blesta v4 beta 5, but the resolution is still unresolved. Did this not make in? 
As a developer, I hate modifying modules like the Universal Module (fork'ing it) for each custom feature tab/page we need for all our services. The idea of another module or even a plugin extending functionality, or implementation callbacks for this would be extremely valuable.
-Adam

Blesta aka Phillips Data is the maker for Blesta and minPHP. Please provide documentation to minPHP. If source-docs.blesta.com is not the right place for minPHP then let everyone one where the new place should be.
 

Blesta aka Phillips Data is the maker for Blesta and minPHP. Please provide documentation to minPHP. If source-docs.blesta.com is not the right place for minPHP then let everyone one where the new place should be.
 

I see that CORE-2338 was scheduled for blesta v4 beta 5, but the resolution is still unresolved. Did this not make in? 
As a developer, I hate modifying modules like the Universal Module (fork'ing it) for each custom feature tab/page we need for all our services. The idea of another module or even a plugin extending functionality, or implementation callbacks for this would be extremely valuable.
-Adam

Follow the instructions in README when you downloaded Blesta. For PHP 7 support, you have to patch the app_controller.php file. Its in the top level folder.
 
 
-Adam
 

CORE-2338

Your not using cPanel/WHM correctly.
Login to WHM Select Module Install Select PHP pecl Then search for mailparse Install  
I highly recommend you use CloudLinux with cPanel/WHM or even cPanel's MulitPHP Manager. 
https://documentation.cpanel.net/display/ALD/MultiPHP+Manager+for+WHM
Either solution allows you have cPanel accounts use different version of PHP. This is great for legacy applications that require specific versions of PHP or specialized setups.
 
-Adam

Your not using cPanel/WHM correctly.
Login to WHM Select Module Install Select PHP pecl Then search for mailparse Install  
I highly recommend you use CloudLinux with cPanel/WHM or even cPanel's MulitPHP Manager. 
https://documentation.cpanel.net/display/ALD/MultiPHP+Manager+for+WHM
Either solution allows you have cPanel accounts use different version of PHP. This is great for legacy applications that require specific versions of PHP or specialized setups.
 
-Adam

Your not using cPanel/WHM correctly.
Login to WHM Select Module Install Select PHP pecl Then search for mailparse Install  
I highly recommend you use CloudLinux with cPanel/WHM or even cPanel's MulitPHP Manager. 
https://documentation.cpanel.net/display/ALD/MultiPHP+Manager+for+WHM
Either solution allows you have cPanel accounts use different version of PHP. This is great for legacy applications that require specific versions of PHP or specialized setups.
 
-Adam

Doh!
 
Apply this patch file. It should work. It will attempt to load from config/blesta.php if a key named 'Session.ttl' exists. Otherwise, defaults to 30 minutes.
diff --git a/core/ServiceProviders/MinphpBridge.php b/core/ServiceProviders/MinphpBridge.php index ccefd20..9367ff4 100644 --- a/core/ServiceProviders/MinphpBridge.php +++ b/core/ServiceProviders/MinphpBridge.php @@ -197,9 +197,10 @@ class MinphpBridge implements ServiceProviderInterface { $this->container->set('minphp.session', function ($c) { // Determine the TTLs and which to set for the database session + Configure::load('blesta'); $cookieName = 'csid'; $ttls = [ - 'ttl' => 1800, // 30 mins + 'ttl' => (Configure::exists('Session.ttl')) ? Configure::get('Session.ttl') : 1800, // 30 minutes 'cookie_ttl' => 604800, // 7 days ]; $dbTtl = (isset($_COOKIE[$cookieName]) ? $ttls['cookie_ttl'] : $ttls['ttl']);  
-Adam