Duplicate #39389. Thanks for the report.

@Quy

Duplicate #39389. Thanks for the report.

My issue 39389 handles only the fact that the language string is not translated.

I think the issue here is that the field new_url of db table #___redirect_links doesn't have a default value NULL which looks like an update issue with earlier Joomla 3 versions(????)

I had this isuue already with 1 (not more) migrated Joomla 3 to 4 sites. I've changed the table structure like this.

I'm not saying that this issue here might be a general migration issue that might occur generally in certain circumstances. Maybe @richard67 can have a look on update sqls?

I don't think it's a DB problem, because by operating directly on the database, I can make the desired insertion, consisting of:
old_url / published:0 / header: 301

Also, in the case of redirect with "header" 410, Joomla makes the redirect enter without any "new url" value.
I think the problem is in the joomla functions that prevent manual insertion of a redirect with "301" header, without "new url" and continue to prevent it even in the case of automatic insertion via "Collect URLs"

@ReLater The database column allows null values and so does not need a default value because that is implicit NULL in such case.

See column definition for not having a "NOT NULL" clause: https://github.com/joomla/joomla-cms/blob/4.2-dev/installation/sql/mysql/extensions.sql#L767

See MySQL documentation for implicit default values (just scroll down to the section "Implicit Default Handling") https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html :

If a data type specification includes no explicit DEFAULT value, MySQL determines the default value as follows:

If the column can take NULL as a value, the column is defined with an explicit DEFAULT NULL clause.

So it does not need any update SQL adding a default value NULL.

What could have happened is following:

With Joomla 3.4.0, the "new_url" column has been modified to accept NULL values, see b979c6b . Later there has been made a change on that update SQL, but not on the mentioned change, only the column has been made larger, see #9269 .

So if something had failed with an update to 3.4 or 3.5, it could be that the column still has a "NOT NULL" clause.

But as @Ataru78 reported, this is not the case for him. He can insert values with SQL e.g. in phpMyAdmin without having that column in the insert statement.

@Ataru78 Just to be sure, could you double check e.g. in phpMyAdmin if the "new_url" column allows NULL values and has a default of NULL as shown in @ReLater 's screenshot?

I did not quite understand @ReLater's response and thought it was a stretch.
The DB table was working manually because it was accepting the value (EMPTY) and not (NULL).
I corrected the table and allowed NULL values to be entered, now everything works correctly.
I confirm that it is also an update from J3 to J4 in my case.
Thank you all!

However, I think it may be useful to have a force on the database when updating to J4, to verify that the table field accepts the value NULL.
This is still a Joomla core component.

@richard67

The database column allows null values and so does not need a default value because that is implicit NULL in such case.

That's the reason why I made 2 red arrows in my images. If it doesn't allow NULL you can't magically write NULL. I don't remember exactely which of the 2 red settings I've changed. The other one follows automatically in phpmyadmin.

EDIT: Ah, solved already.

I corrected the table and allowed NULL values to be entered, now everything works correctly.

This is still a Joomla core component.

@Ataru78 What do you mean with that? Sure it's a core component, but that component should have the right table structure since Joomla version 3.4.0.

Updating to 4 has to happen from the latest 3.10 version. On that 3.10 version and the 3.x versions before that since 3.4.0, the database checker should have shown a structure error.

Maybe you have not seen that structure error or ignored it and maybe you have made the update to J4 very early before I have added a check for the database having no structure errors to the pre-update checker, so the pre-update check allowed you to update, and after the update the database checker will not show the error anymore due to the nature how it works (it checks all present update SQL scripts, but those from 3.x are removed with the update).

Or you have also not seen or ignored the structure error and used the upload and update method of the Joomla Update component and not the Live Update method so you could update with having that structure error.

Meanwhile the pre-update checker would block you from getting an update offered when there are database structure errors before the update. Of course you can circumvent that by using the upload and update feature. But then the responsibility for that are on your side.

So or so it is a rare edge case very likely caused by the reported database structure error being ignored before. In my opinion it would not really make sense to add update SQL scripts for that.

@richard67 you're right, in Joomla 3 I had opted for a dedicated SEO system (with its own table) and so I probably never noticed the problem because I wasn't using the native "redirect" system and related table.
So the problem is related to some update between Joomla version 3.4 and 3.5 and not the latest update between 3.10 r 4.2
Now that I have upgraded to J4 version and decided to use the native system, the problem that was "latent" has emerged.

I apologize for opening the report thinking it was a bug in this version.

@Ataru78 No need to apologize. I'm happy we could sort it out. Closing as not an issue with J4.

If it helps, I upgraded from J3.10 to J 4 in October 2022 with online mode.
It's been a long time and I don't remember well, there were definitely various warnings of unverified components, but there was definitely no blocking error for database structure incopatibility.

If it helps, I upgraded from J3.10 to J 4 in October 2022 with online mode. It's been a long time and I don't remember well, there were definitely various warnings of unverified components, but there was definitely no blocking error for database structure incopatibility.

Then I have no idea how it happened-