what do you mean by the title of this PR "creates a false alarm" ?

#17219.

That's a good example why it's sad that pr #17219 never found its way into J!3 in time.

Core extensions shouldn't be uninstallable.

Usually, when an extension is uninstalled, its table is also empty. That's why this message doesn't fit?
Ah, I see new comments. Hv to read it.

That's a good example why it's sad that pr #17219 never found it's way into J!3 in time.

Core extensions shouldn't be uninstallable.

That's right. It is a Core extension.

Indeed this happens because it is a core extension

@infograf768 is this different from 3.x?

I guess not as #17219 was for 3.9

Now, as you are all here.
I get another nice error with the new table (clean install, which means the table IS present)

Table 'dfrvh_webauthn_credentials(' does not exist. (From file 4.0.0-2019-07-02.sql.)

Remark the weird ('

String is
COM_INSTALLER_MSG_DATABASE_CREATE_TABLE="Table %2$s does not exist. (From file %1$s.)"

Just for completion. 3.9.17-dev

Now, as you are all here.
I get another nice error with the new table (clean install, which means the table IS present)

Table 'dfrvh_webauthn_credentials(' does not exist. (From file 4.0.0-2019-07-02.sql.)

Remark the weird ('

String is
COM_INSTALLER_MSG_DATABASE_CREATE_TABLE="Table %2$s does not exist. (From file %1$s.)"

Please test PR #28337.

Thanks @SharkyKZ
I leave this issue open as it concerns the updates

btw, without re-doing @mbabker patch as no one looks like volunteering, we could, for J4, forbid uninstalling core stuff by adding protected for all.

Protected flag also prevents disabling extensions. That's why we need a separate flag. Or maybe we could make use of Joomla\CMS\Extension\ExtensionHelper::checkIfCoreExtension(). The advantage of this is not allowing 3rd party extension to have core status.

@infograf768 > would be a good idea. Volunteering: Could do it, if I would know, how - I'm not programmer etc. :-)
@ReLater > confirm J 3.9.16

Honestly the best would be Michael proposal.
@SharkyKZ if you feel that would do it, why not proposing a PR.

That is, if @wilsonge and @HLeithner agree, to avoid working for nothing.

Core extensions shouldn't be uninstallable.

but should be possible to disable

but should be possible to disable

That's the reason why we linked to #17219

I agree michael's proposal seems sensible to me

Or using the extensionHelper method we have now.

Don’t use the extension helper method. It is crap that there exists code to distinguish first party and third party extensions, and behaviors favoring first party extensions should not be added to the platform without a way for third party to do the same (@Bakual I seem to remember a recent issue/PR where you just had this exact groan, hence the reason the two flags on the database tables are the method Andre then me went with; there is nothing wrong with a third party locking an extension blocking uninstall if for example they aren’t using package extension types and some “sub extension” shouldn’t be uninstalled without removing the parent).

There is a reason none of the flags were called “core”, let’s keep it that way ?

I prefer Michaels proposal. It is clear and flexible.

If we're fine with 3rd party blocking uninstall, then obviously Michaels approach is correct.

for example they aren’t using package extension types and some “sub extension” shouldn’t be uninstalled without removing the parent

That's a bad example since you can already specify that in your XML manifest. It's for example used in the language package. But I get your point.
I'd just hope 3rd party don't misuse that flag ?

Nothing mandates that third parties use package extension types though. If you're using them, you already have that feature available via the package manifest flag. But, there is no requirement (nor should there ever be) that "groups" of extensions can only be installed via packages.

foreach ($packages as $package) {
    // Oversimplified but whatever
    (new JInstaller)->install($package);
}

Doesn't matter whether that snippet runs in the package installer or an extension install script or if some third party creates a new extension type (because one can extend the installer API) with a new extension adapter and has a feature to handle auto-lock/protect there.

That's why I say the database is the better way to do it versus another hardcoded list in core and another capability that only exists to core. Sure, someone is probably going to misuse it, but those are the folks you name and shame for writing bad extensions versus writing core in a way to prevent a feature being possible.

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/28336

Please test PR #28462