The purpose of the plugin is to prevent your site being disabled due to incompatible extensions. Therefore if you disable it and have incompatible extensions then your site will obviously have issues. You can re-enable the plugin directly in the database by locating the tnry for the plugin in the #__extensions table and setting the value of the enabled field to 1 from 0

If you review my "actual result" (perhaps you didn't see my edited version), that is exactly what I did. I wanted to report this because with the params field being empty, simply making it enabled again left the site broken.

no i didnt see the edited version

Hmm, for a new installation the parameters are set right, see https://github.com/joomla/joomla-cms/blob/5.4-dev/installation/sql/mysql/base.sql#L265 .

So the question is how they got removed.

Hmm, I just see the SQL is missing the "removed_asset" parameter in the JSON. I think that causes the problem for a new installation where the parameters of the compat plugin have never been touched and there is an extension which needs exactly that feature (removed assets). I will prepare a PR to fix that.

Update: I've prepared a PR, but I'm not sure if that missing "removed_asset" parameter can really cause that issue. I have to test.

I've closed by PR as that missing parameter is not really a problem. The plugin handles it well by using the right default value.

@ConfidantCommunications Which 3rd party extensions do you have on the site where you had the problem?

That not really what we can fix.

For example, there may be system plugin that do not work without plg_behaviour_compat plugin, and disabling plg_behaviour_compat will crash that plugin with PHP fatal error which make backend inaccessible.

It kind of expected behavior, Users should not do such tests on production sites.

I cannot reproduce the issue here, neither with the "classes_aliases" nor the "removed_asset" option being needed.

When I set the params to an empty string '' or to an empy JSON {} or to a valid JSON where just the required parameter is missing, in all these cases the compat plugin works and uses the default = 1.

Only when I set the params column to allow NULL values (which it doesn't on a clean database) and set it to NULL, I get the issue.

For example, there may be system plugin that do not work without plg_behaviour_compat plugin, and disabling plg_behaviour_compat will crash that plugin with PHP fatal error which make backend inaccessible.

@Fedik Hmm, but enable the compat plugin in database should fix that, or not?

@ConfidantCommunications Could you check the structure of the #__extensions table in the database of the site which had the problem if the params column allows NULLvalues? You can do that e.g. in phpMyadmin with the following SQL statement:

SHOW CREATE TABLE `#__extensions`;

Replace the #__ by your actual table prefix.

Then in phpMyAdmin you might have to select the additional option to show the full text result to see the full create table statemment.

Could you do that and report back the result?

Thanks in advance.

Hmm, but enable the compat plugin in database should fix that, or not?

yeah, but that not on our side 😉

Hmm, but enable the compat plugin in database should fix that, or not?

yeah, but that not on our side 😉

@Fedik Yes, but that's the issue here, that setting it to enabled in database has not helped on that particular site.

After point when User start editing database manually many things can go wrong.

Could you check the structure of the #__extensions table in the database of the site which had the problem if the params column allows NULLvalues?

@richard67 The params column has "No" in the Null column, thanks.

Which 3rd party extensions do you have on the site where you had the problem?

The plugins which seemed to be broken with the compat plugin disabled were dropfiles, linkymap, mymaplocations, SP PageBuilder.