@fontanil Can you check if the issue happens also with MariaDB 10.5.11? The release notes of current 10.5.11 mention 2 regressions of which one could cause the problem here, I think: https://jira.mariadb.org/browse/MDEV-25672 .

I just tried with MariaDB 10.5.11 and 10.6.3 (on PHP 8.0.8): same issue.

@fontanil And you are getting exactly the same errors as with 10.5.10? Or are you getting different ones? The one you describe for MySQLi I would have expected to come from https://jira.mariadb.org/browse/MDEV-25672 , which has been fixed with 10.5.11.

Yes, I have the same messages with MariaDB 10.5.11 and 10.6.3 on Wampserver 64.

New test with 10.6.3

With MySQL(DBO) type:

42000, 1118, Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

42S02, 1146, La table 'j4rc5dev.ru3b1_tags' n'existe pas

With MySQLi type only

Error

La table 'j4rc5dev.ru3b1_tags' n'existe pas

as per https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/

can you run before to install

SET GLOBAL innodb_default_row_format='dynamic';
SET SESSION innodb_strict_mode=OFF;

Sorry, I don’t know how to do this on WampServer for Windows!

Sorry, I'm not comfortable with server management and didn't know there was a MariaDB console to enter these lines.

Indeed, after their entry, the installation could well be done on the version 1.5.10

But how to do if these versions are installed on a shared server?

i've runned all the install sql on 10.5.11-MariaDB without issue
https://dbfiddle.uk/?rdbms=mariadb_10.5&fiddle=17a8cb6934ddb2647c42200d02aae363
maybe some wampserver misconfiguration

4.0-dev...feature/mariadb-system-test

https://ci.joomla.org/joomla/joomla-cms/45970

@richard67 system tests running - shouldn't be a hard requirement to run it locally

These system tests pass with that mariadb version. So we're going to need to spend some more time figuring out exactly where the differences are between the wamp setup and the official docker setup. Official docker image is out the box 10.5.11 install. Unfortunately I don't have a windows machine to validate wamp...

@richard67 system tests running - shouldn't be a hard requirement to run it locally

Yes ... if I had the right MariaDB version locally.

On mariadb.log last try yesterday with MariaDB 10.6.3:
Version: '10.6.3-MariaDB' socket: '' port: 3306 mariadb.org binary distribution 2021-07-21 8:39:41 5 [ERROR] InnoDB: Cannot add field imagesin tablej4rc5dev.rfmsc_tags because after adding it, the row size is 8761 which is greater than maximum allowed size (8126 bytes) for a record on index leaf page.

@alikon
You are right, its a Wampserver misconfiguration.
As said in the MariaDB page https://mariadb.com/kb/en/troubleshooting-row-size-too-large-errors-with-innodb/ (Solving the problem)

In MariaDB 10.2 and later, the DYNAMIC row format is the default row format. If your tables were originally created on one of these newer versions, then they may already be using this row format. In that case, you may need to try the next solution.

So I uninstalled Wampserver, installed the full version 3.2.3 with MariaDB 10.5.4 and its update 3.2.5 and tried to install the last RC5-dev: no problem.

But if I add MariaDB 10.6.3 an try to install, the previous error is displayed. So I think that the MariaDB addon versions don't set the DYNAMIC row format.

PS: SET GLOBAL innodb_default_row_format='dynamic'; added in the MariaDB console is sufficient to correct this error

page_size is 16K but in 10.5.11 and 10.6.3:

innodb-default-row-format=compact

De : Nicola Galgano @.>
Envoyé : jeudi 22 juillet 2021 09:56
À : joomla/joomla-cms @.>
Cc : fontanil @.>; Mention @.>
Objet : Re: [joomla/joomla-cms] Joomla! 4.0 can't be installed on MariaDB 10.5.10 (#34847)

@wilsonge https://github.com/wilsonge what is the value for innodb_page_size in 4.0-dev...feature/mariadb-system-test ?
i suspect 16K = 16384, should be possible to run the system test with innodb_page_size = 8K ?

i also suspect that @fontanil https://github.com/fontanil setting is innodb_page_size = 8K = 8192

finally able to replicate

with this settings in my.cnf

innodb_page_size=8K
innodb_default_row_format=compact

@alikon What happens if you add a ROW_FORMAT=DYNAMIC to the end of the create table statement for the extensions table? Does the "Table '..._extensions' doesn't exist" disappear? And what do you think, should we try to fix our SQL scripts in such a way, or should we note required configuration details in our requirements on environment in the docs?

Or maybe nicer not at the end but after the engine:

CREATE TABLE IF NOT EXISTS `#__extensions` (
  `extension_id` int NOT NULL AUTO_INCREMENT,
  `package_id` int NOT NULL DEFAULT 0 COMMENT 'Parent package ID for extensions installed as a package.',
  `name` varchar(100) NOT NULL,
...
  `state` int DEFAULT 0,
  `note` varchar(255),
  PRIMARY KEY (`extension_id`),
  KEY `element_clientid` (`element`,`client_id`),
  KEY `element_folder_clientid` (`element`,`folder`,`client_id`),
  KEY `extension` (`type`,`element`,`folder`,`client_id`)
) ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT CHARSET=utf8mb4 DEFAULT COLLATE=utf8mb4_unicode_ci;

Adding ROW_FORMAT=DYNAMIC (in CREATE TABLE for extensions or tags) doesn't work for me

so under 10.5.8-MariaDB-1:10.5.8+maria~focal-log
with in my.cnf

innodb_page_size=8K
innodb_default_row_format=compact

i've setted ENGINE=InnoDB ROW_FORMAT=DYNAMIC for all tables

and i was able to install.... but dunno at moment what can be the best way to do it in a way that all mysql supported version and mariaDB works ....

i've setted ENGINE=InnoDB ROW_FORMAT=DYNAMIC for all tables

and i was able to install....

@fontanil For @alikon it worked. Why not for you? Can you check if you maybe made something wrong or if you missed the error having change to another table? Can you check if you can install when adding it for all tables like @alikon did?

I replaced "ENGINE=InnoDB DEFAULT" with "ENGINE=InnoDB ROW_FORMAT=DYNAMIC DEFAULT" for all tables of the three installation sql files and it works now.

But I have same error with Event Gallery and Appointmentbooking Pro (extensions I am using on personal websites) and also with Community Builder.
I therefore suspect that the installation of other extensions will fail for the same reasons.

But I have same error with Event Gallery and Appointmentbooking Pro (extensions I am using on personal websites) and also with Community Builder.
I therefore suspect that the installation of other extensions will fail for the same reasons.

@fontanil Yes, that's right. So the right solution might be that we have to update our docs about requirements by the necessary server settings. But at least we know now more about what the problem is and what could be possible solutions.

i would say...
check

show variables like 'innodb_default_row_format;'

if compact set

SET GLOBAL innodb_default_row_format='dynamic';

On shared servers I think we can't modify the "my.ini" with this code.

I tried to install the same sql (with ROW_FORMAT=DYNAMIC for each table) on MySQL 8 and I had no error.

I made the same changes for AppointmentBooking Pro and had no more errors on MariaDB.

What confused me was that using "ROW_FORMAT=COMPACT" did not cause the error on MySQL 8 when I tested.

On shared servers I think we can't modify the "my.ini" with this code.

@fontanil If a shared hosting provider doesn't provide an environment when you can run a CMS on, you should chose a different one. I'm pretty sure other CMS will fail, too, on that environment. It's the same if they have not sufficient PHP settings and not allow you to change that. The important thing is that we clearly identify and document the requirements.

Because I did not get the error when using "ROW_FORMAT=COMPACT" on my MySQL environment, I think it might be connected to other settings, too, if the error happens or not, e.g. to the innodb_page_size.

Same problem with a 3.9.29 dev version and a 3.9.28 stable on MariaDB 10.5.11 and 10.6.3 (and PHP 8.0.8 or 7.4.9):
Error
La table 'j39dev.#__tags' n'existe pas
Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

As described here, the default row format on MySQL 5.6 and earlier was "compact", too: https://tonnygaric.com/blog/difference-in-innodb-s-default-row-format-between-mysql-5-6-and-5-7 . Joomla 3 and 4 run with MySQL 5.6 and J3 with older versions without problems, J3 since ages. So it must be some other server setting in addition which makes the problems.

In the my.ini files of MySQL up to 5.7 and MariaBD up to 10.4, there is no line
innodb-default-row-format
It is only found starting with MySQL 8 and MariaDB 10.5
I compared the my.ini files of MariaDB 10.6 and MySQL 8 and I could not find what difference in settings could explain this behaviour of MariaDB and this size error

Is this something that should be marked as a release blocker or should it just be documented as a known issue with wamp

I’d say the latter.

This error will occur on all servers that use a version >=10.5 of MariaDB with row format = compact. You will need to be able to change to row format = dynamic. In Wampserver it is easy to modify my.ini or use the console. As I said, the problem will arise on shared servers if you can't change this format.

@richard67 was this documented? If so then this can be closed?

I don’t know of this being documented somewhere.

I would write it myself but I dont fully understand it.

Hi,
Use a server with MariaDB 10.5 or 10.6 (I tried this morning with MariaDB 10.6.5 and Joomla! 4.0.4 on Wampserver), install Joomla!, you will get this message "La table 'getjmdb106.jfspi_tags' n'existe pas" (The table 'getjmdb106.jfspi_tags' does not exist).
As we said, it's a problem with the row format and need to add ROW_FORMAT=DYNAMIC for each table creation in the SQL files.
A lot of shared servers are using MariaDB only and if this problem in not solved before they change their version from 10.3 or 10.4 we will have many failed installations and probably users who will not know how to modify the installation SQL themselves and may abandon Joomla!
This problem will also affect third party extensions.
Can't anyone work with the MariaDB team to find a solution to this problem?

despite i still think that's a server mis-configuration issue
we need to start to think at MariaDB as 1st citizen DB

i mean MariaDB it's STILL not mentioned on https://docs.joomla.org/Special:MyLanguage/J4.x:Optional_Technical_Requirements
it should be

I just tried a vanilla install of the latest Wampserver x64 and Joomla builds and had zero problems installing Joomla on the Wampserver with MariaDB 10.5.4.

My two VPS servers use MariaDB 10.3 and since this version's EOL is in a year or so, I thought of upgrading them (through the WHM control panel) to MariaDB version 10.5.
In the process, I got three warnings, requiring my express authorization before proceeding, which stopped me in my tracks. One of the warnings concerns a third party database monitoring software which I don't use, therefore it's irrelevant for me.
The other two put me into scratching my head because of my ignorance of what they say and whether they may impact negatively on my Joomla websites totaly/partially immediately or sometime later down the road.
Those two warnings are copied below. Can somebody with experience tell me whether a Joomla 3 or 4 website may somehow be negatively affected?

Thank you.

Severity: Critical
Message: In MariaDB 10.4 and later, the mysql.global_priv table has replaced the mysql.user table. The mysql.user table is converted into a view of the mysql.global_priv table during the database upgrade. The dedicated mariadb.sys user is created as the definer of the new mysql.user view.

Severity: Normal
Message: All binaries previously beginning with mysql now begin with mariadb. Symlinks are created for the corresponding mysql commands to ensure backwards compatibility. Usually that should not cause any changed behavior, but when starting the MariaDB server via systemd, or via the mysqld_safe script symlink, the server process will now always be started as mariadbd, not mysqld. Any 3rd party software or scripts looking for the mysqld name in the system process list must now look for mariadbd instead.

@stavroszach Both messages have nothing to do and no effect on Joomla CMS, they are related to the database server setup and configuration. Note that this here is an issue tracker for the CMS and not a support forum for hosting questions.

i mean MariaDB it's STILL not mentioned on https://docs.joomla.org/Special:MyLanguage/J4.x:Optional_Technical_Requirements it should be

I'm totally agree, hoping that there will soon be news about it...

I have just spend hours on trying to install Joomla! 4.4.5 on my hosting provider, then i have found this issue. I have just figured out that he is using MariaDB 10.6.18. I can only install a backup with Akeeba, then i can't log on the backend it says that the page isn't redirected correctly

Hi,

I think the problem was resolved as I have on a local server (MariaDb 11.2.2) many sites, some are from Akeeba backups, other were installe as new sites.

Try to rename the .htaccess and test the administrator access.