to be honest i am not surprised. the core extensions are not designed to be uninstalled and will come back when you do an update anyway. what i always do in this case is just to disabled (not uninstall) the component

Any extensions in the core package shouldn't be removed and #17219 helps keep this from happening in the future.

Thanks to @brianteeman and @mbabker for clarifying the intended behavior. Given this, it seems then that the Banners component and module need to be appropriately protected per #17219.

May I propose that in the 4.0 branch that we look closely at which extensions should truly be protected in the core package? In 12 years of developing Joomla sites, I've never once used Banners, News Feeds, or Multi-lingual Associations. Only rarely have I used Messaging, Search, and Smart Search as we use other solutions in place of these features.

If certain protected extensions can be disabled without repercussion, then why not allow them to be uninstalled? They don't take up lots of space individually, but when our multi-site servers are backing up dozens of Joomla sites daily, that adds up to a lot of redundant storage locally and redundant bandwidth to transmit those backups offsite. (My very back-of-the-envelope calculation is that just these extensions require an extra 2 GB of backup storage and transmission over the course of a year just for our operation.)

Yes, we could create exceptions for these particular directories but that will of course create problems if we need to restore a backup and the extensions are missing.

If they are uninstalled then how do you propose managing the update process to prevent them being reinstalled

As long as core updates itself in the way it does, it is infeasible to try and perform "selective" updates. The extraction process is a very basic "unzip package" command. To do what you're suggesting adds more resource use to updates because we would have to extract the package to a temporary directory (essentially creating two copies of the core file architecture in the process) and have a very resource heavy stage two where files are moved from that temporary directory only if the corresponding extension is still installed (which means some database queries and a lot of is_dir() checks along the way). The SQL processing would have to be wrapped into some kind of IF TABLE EXISTS ALTER TABLE type deal. All in all it is not a very efficient process to try and make core selectively upgradeable based on a user having removed core extensions. The best option is what #17219 proposes, prevent things from being uninstalled to not break the system in the first place.

@brianteeman, that's a great question and from it I will try to refine my proposal. Thank you!

Perhaps in the 4.0 branch we can examine which extensions should be in the core project and are absolutely required for Joomla to function versus which component should be part of the Joomla project but not in the core.

Let's set up this discussion with a comparison: Google produces the source which underlies Android, which has many required components such as those that interface with hardware, draw the GUI, etc. Google also produces the Android Messages app, which is extremely useful and closely integrated with Android, but is functionally independent and not required for Android to run. In fact, other apps can replace Messages, such as Signal.

In the Joomla context, we can see that the Joomla Update and Cache components, as well as the various Authentication plugins would clearly be core components. Joomla cannot operate without them.

However, Banners and Newsfeeds are clearly not essential, as they can be completely disabled without detriment. As such, perhaps they should not be included as core components. They could still be installed with the core as optional during initial deployment, and then updated through the normal extension update routines instead of through Joomla Update. (This would address the update problems raised by @mbabker by simply eliminating them: After initial deployment, they would just be extensions and not need special exceptions in Joomla Update.)

Now, even though these components are clearly non-essential, there may be good reason for the Joomla Project to continue to develop them to assure close interoperability with the Joomla core. As such, perhaps these non-essential-yet-closely-maintained components can be called project compenents or non-core components.

Of course, if we decided that Banners -- as an example -- was neither critical nor desirable to continue to maintain, we could just separate it from the core project altogether and let some third party develop it. There are so many third-party solutions to running advertising on a Joomla site that it probably wouldn't be missed.

Finally, now that we've identified examples of components that are clearly critical to Joomla and some that are clearly not, there are a slew that we would have to figure out which camp they fit into. For instance, are Articles and the rest of the content-related components strictly necessary? Arguably, they are, as Joomla is a CMS and that's what it's designed to do. Also arguably, one can deploy a Joomla site using K2 or other components without using Articles at all -- completely replacing that functionality. Or, one could use Joomla with some other non-content component entirely, such as to create a reservation booking site. I don't know the inner workings of the Joomla content components to know what would happen if we just disabled Joomla's content components entirely. Would Joomla break? If these components can be disabled without ill effect, then how are Joomla's content components interfaced with the fundamental Joomla framework differently than third-party content components like K2? If they are fundamentally just extensions, then why aren't they just installed as extensions and updated through the extension updater? (And there are probably excellent answers for these questions, which I why I'm asking!)

Thank you!

Being blunt, the odds of anything else being decoupled from the core project are slim to none. Just look at what happened after weblinks was decoupled (when's that 3.7 stable release coming, beta was tagged a year ago). At this point, it's better to just say we're killing the code off in full than the false promise of decoupling and maintained.

Joomla is a monolithic package. Even if the entirety of the core isn't used, because of the project's distribution mechanisms and the technical challenges to doing partial upgrades, it's either an all or nothing thing. It's also why you'll never see alternative runtime methods supported by the project (we won't ever support a Composer based project approach, we won't ever support a pipeline where you can version control the code and deploy updates through a CI pipeline because we lack the tooling to do updates of core or extensions outside the existing UI workflows or writing in place as those workflows do now, etc.).

I appreciate bluntness, @mbabker. It saves a lot of time.

For what its worth, until you mentioned Weblinks was removed, I had forgotten about it ever existing. That's another one I never used and always wished I could get rid of. (Belated thanks for retiring it!)

Therefore I put in a vote to eventually drop Banners and Newsfeeds as core components that are no longer necessary: Their functionality is extensively replicated by free third-party options that are more configurable. In Joomla 1, they were features, but now they're... there.

Closed as answered by @mbabker

How does one go about reinstalling the com_banners component? I tried reinstalling Joomla, but it hasn't reinstalled Banners, and I am still experiencing the issue with the ghost menu item. When I click on the menu item I get a 404 component not found error. I would like to reinstall and then just disable the component if possible. I'm running Joomla 3.9.5.

@steve-genilogic Please ask on Forum as this Repo is for Coding.

@franz-wohlkoenig many thanks!

UPDATE: I managed to fix without needing to post in the forums.

@steve-genilogic please share how did you fix it, since I have the same problem