1118 Error on CBSubs

I get the following errors on our plugin check for CB on one site:
CB plugin "CB Paid Subscriptions" database structure differences:
Table #__cbsubs_plans Column cond_1_plans_required type is varchar(1024) instead of text
Table #__cbsubs_plans Column cond_1_subscription_conditions does not exist
Table #__cbsubs_plans Column cond_1_subscription_autorecurring does not exist
Table #__cbsubs_plans Column cond_1_subscription_regular_recurrings_used_min does not exist
Table #__cbsubs_plans Column cond_1_subscription_regular_recurrings_used_max does not exist
Table #__cbsubs_plans Column cond_1_basket_conditions does not exist
Table #__cbsubs_plans Column cond_1_basket_currencies does not exist
Table #__cbsubs_plans Column cond_1_basket_gatewayaccounts does not exist
Table #__cbsubs_plans Column cond_1_basket_payment_methods does not exist
Table #__cbsubs_plans Column cond_1_basket_payment_types does not exist
Table #__cbsubs_plans Column cond_1_basket_autorecurring does not exist
Table #__cbsubs_plans Column cond_1_basket_taxed does not exist
Table #__cbsubs_plans Column cond_1_basket_address_country_codes does not exist
Table #__cbsubs_plans Column cond_1_value_1 type is varchar(1024) instead of text
Table #__cbsubs_plans Column cond_1_value_2 type is varchar(1024) instead of text
Table #__cbsubs_plans Column cond_2_plans_required type is varchar(1024) instead of text
Table #__cbsubs_plans Column cond_2_subscription_conditions does not exist
Table #__cbsubs_plans Column cond_2_subscription_autorecurring does not exist
Table #__cbsubs_plans Column cond_2_subscription_regular_recurrings_used_min does not exist
Table #__cbsubs_plans Column cond_2_subscription_regular_recurrings_used_max does not exist
Table #__cbsubs_plans Column cond_2_basket_conditions does not exist
Table #__cbsubs_plans Column cond_2_basket_currencies does not exist
Table #__cbsubs_plans Column cond_2_basket_gatewayaccounts does not exist
Table #__cbsubs_plans Column cond_2_basket_payment_methods does not exist
Table #__cbsubs_plans Column cond_2_basket_payment_types does not exist
Table #__cbsubs_plans Column cond_2_basket_autorecurring does not exist
Table #__cbsubs_plans Column cond_2_basket_taxed does not exist
Table #__cbsubs_plans Column cond_2_basket_address_country_codes does not exist
Table #__cbsubs_plans Column cond_2_value_1 type is varchar(1024) instead of text
Table #__cbsubs_plans Column cond_2_value_2 type is varchar(1024) instead of text

When I try to fix the errors, I get the following message:
1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

When I try to change the cbsubs_plans table structure in phpmyadmin on the mentioned rows from varchar to text or blob, I get the same error.

Please ensure CBSubs is completely up to date and confirm if issue persists. It is also possible your Innodb database configuration is not correct and is using significantly out of date default values resulting in an unrealistic environment. See the below topics regarding similar issues and solutions to fix the configuration.

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

CB Subs is updated to the current version:
4.4.0+build.2020.06.30.14.24.19.5641cd5f6

The problem persists, despite the fact that I have several other web sites on this exact same server running CB Subs without any issues, one of which has been there for well over ten years. All of them are kept up to date with the current version at pretty much all times. Same goes for all the plugins and Joomla itself, in general.

So, this cannot be a server environment problem.

Edit the _cbsubs_plans database table using phpmyadmin and under Operations ensure the following are set.

Storage Engine: InnoDB
ROW_FORMAT: DYNAMIC

Aside from that try comparing _cbsubs_plans to a sites database that works. Seams strange only 1 database would be impacted like this, which should be fixed by adjusting the above settings.

Those were the settings on that table, so that checked out.

However, when I checked another site's _cbsubs_plans database table, the storage engine was actually set to MyISAM. That site is functioning well, and I'm not sure why its CB plugins database checked out, whereas the other site's did not.

So, I simply changed the storage engine on the problem site to MyISAM instead of InnoDB. I went back into the admin area, ran the CB plugins database check, where it again found the errors. I clicked to fix the errors, and voila! it worked. So, now the big question is why?

I'm pretty sure I don't want to go changing the storage engine on working database tables of other sites because of the problems exhibited on this one.

Your old site is still on the old database engine that Joomla used to use. Your new site is using InnoDB, but your host did not configure it correctly causing you to hit a row limit of 8126. The only real fix for this is to have InnoDB configured correctly with the below database settings.

innodb_large_prefix = 1
innodb_file_per_table = 1
innodb_file_format = Barracuda

Aside from that you can try deleting a few columns from _cbsubs_plans that are not being used and change varchar columns to text columns once the error stops and allows you to do so. Once those have been changed from varchar to text you can rerun the tools check to recreate the deleted columns.

In short due to server configuration your row size limit is half of what it should be. Also if your host is using MariaDB instead of MySQL then see the below for configuration settings.

www.joomlapolis.com/forum/153-professional-member-support/242484-installation-cb-connect-failed?start=12#318734

This often happens when a host does not maintain database configuration and ends up having default values from over 4 years ago or they're intentionally trying to limit row sizes to reduce storage space. Using such settings however puts the database out of default spec making it impossible to develop for as we have to develop for defaults.