Installation CB Connect failed

Hi, I have contacted my host provider to discuss mod_security. They told me that mod_security is not active at their shared hosting.

They suggested me to try PHP 7.3 (instead of 7.2), but that did not make any difference. Also some changes in other settings (max execution time) did not make any difference.

I don't know what to do now.

Enable debug mode and maximum error reporting in Joomla global configuration. Once both are configured attempt to install CB Connect again and see if the Log at the bottom shows an error after clicking "show" next to the failed install. If not contact your host and have them check error logs if you're unsure how. This should guarantee a log of some kind exists. There's nothing I can do with strictly "500 - " as the error message should follow it. Something else you can try to expose the error is unzip the package then install CB Connect directly in CB > Plugin Management > Install New Plugin. You should find CB Connect in /extensions/cb_plugins folder of the zip.

I found CB Connect in /extensions/cb_plugins folder of the zip and installed it. And yes, this gave immediately an error report. See appendix. I hope this information is useful for you.

Your Innodb database configuration isn't correct. See the below topics regarding such an issue with possible fixes depending on your hosting environment and database engine.

www.joomlapolis.com/forum/255-developer-members-support/239751-solved-problem-row-size-too-large?start=6#307225
www.joomlapolis.com/forum/153-professional-member-support/242003-error-when-making-a-field?limitstart=0

In short you've hit the limits of your database for the _comprofiler table. It can't have anymore columns added meaning you can't have anymore fields, which CB Connect creates for storing the provider ids and is why it's failing.

I have contacted my host provider again. I have got the following reaction:

"The error is possible, because the developers [of CB Connect] did not take into account the MySQL standards, as described here: bugs.mysql.com/bug.php?id=69336 .

One of the developers of MySQL has explained why "The "Row size too large (> 8126)" error is not a bug. "This behavior is expected because inoodb design
requires the record to fit in the B-tree leaf page and if unsuccessful we return error. During the creation of BLOB or TEXT field we allocate 41 Bytes (dynamic or compressed row format) for the field which is considered for row size calculation. During insertion if the BLOB or TEXT is less than 40 Bytes we store it internally with in these 41 bytes and if it is more than 40 bytes, we store it off page and store 20 Bytes reference to the page.""

I hope this information is useful for you.

Those are MySQL standards from 5+ years ago. So no we don't take them into account anymore. Back then InnoDB was not the default storage engine and had bad default values for its settings since it was new and no one used it. This was when we all used MySIAM as it was the default storage engine, which supported far larger tables as well by default.

InnoDB became the default storage engine in MySQL 5.6, but quickly determined the settings were bad with release of MySQL 5.7. In MySQL 5.7 you are forced to use the below settings because most of them are deprecated and completely removed in a later MySQL 5.7 releases. This all happened 5 years ago. If your host has not corrected those settings then they've effectively done nothing with their hosting platform for years and you're probably stuck on MySQL 5.6, which is end-of-life next year, and unable to even move to MySQL 5.7.

Below are the settings they should be using with InnoDB otherwise there's no point to use InnoDB.

innodb_large_prefix = 1
innodb_file_per_table = 1
innodb_file_format = Barracuda

There's nothing we can really do about this. Our implementation was designed around MySIAM limitations, which are basically the same as correctly configured InnoDB. MySQL 5.6 initial InnoDB settings are half of those limitations and were not taken into the design (I don't see how we could; you effectively have lost half of your row size limit).