The pull request you've linked (and commented on) is completely unrelated to this proposed change. Please describe why you think this change is necessary.

yes, and add test instructions too (the test instructions header is there when you create a pull request for a reason ...)

@mbabker @andrepereiradasilva description update with test instructions

Can you ever have an extension in the database that does not have a status of 0
From what I can guess you are trying to exclude extensions that are not installed - so therefore they are not in the database at all and they wont get returned by the existing query either

(I could be completely missing the point and you description has been lost in translation)

When you discover extensions, all found extensions are loaded into the database with state = -1. They remain in that state until they are fully installed or the records purged.

Yes @mbabker , extension with state = -1 (discover) are considered as installed.

As I said the description and test instructions were incomplete and misleading. There is NO mention of doing a discover at all. Only to create the files

@brianteeman description update

Alright, it looks like this change only affects on discovered components. It really should also prevent disabled components (enabled != 1) from messing up the site.

See the linked issue from above.

Yes @mahagr , adding request condition for prevent disabled extensions.

I'd only add it to the load method. Adding the enabled condition on the isInstalled method makes that method report invalid results (it's possible to have an extension installed and disabled).

ok @mbabker

I agree that it should be only on load() method.

BTW, this pull request will change how component helper works and may have some visible side effects on peoples sites. This is because of both getComponent() and getComponents() calls will not anymore return component that exists in the database, but isn't either installed or enabled.

After running some tests with J!3.6.3, it looks like disabling extension makes it to stop to work from frontend and hidden in backend, though in backed you can still access the extension by typing the option manually (a bug?). On the other hand discovered component seems to be fully working as long as it has been enabled (another bug?).

I need to test the same with the patch applied; I'll find some time for that.

I just tested all the combinations with the patch (disabled, discovered | enabled, discovered, disabled, installed | enabled, installed) and it looks like that it doesn't change much in the admin -- except that discovered/enabled component is shown in the admin menu, but you cannot access it. You cannot access disabled component either.

This is an improvement over discovered or disabled component being fully accessible in admin, but it would be nice to have another patch hiding the admin menu items in that case (I've seen sites with discovered but enabled components before -- not sure how you end up getting them, maybe failed install?)

I have tested this item ✅ successfully on 4d3775f

test von Christianboulbi

I have tested this item ✅ successfully on 4d3775f

RTC after two successful tests.

Merge conflict needs to be addressed.

@vinespie can you please resolve conflicting Files?

Replaced by #21010 with merge conflicts resolved.