Not sure it is the same bug, but we get and admin menu for a core pack when updating at the same time one of the Akeeba comps and a core language.

Looks like the PR includes some stuff unrelated

Looks like the PR includes some stuff unrelated
Yes, the two commits merged into one PR, though tried to send them individually. Commit bda9ec5 to this PR does not apply

Please update this PR to only take care of the issue at stake

Yes! I did it! :)

One code style more to correct
FILE: ...s/build/joomla/joomla-cms/libraries/cms/installer/adapter/component.php

FOUND 1 ERROR(S) AFFECTING 1 LINE(S)

1252 | ERROR | Whitespace found at end of line

Fixed.

@test
I tested the issue we have when updating Akeeba back-up AND a language pack at the same time.
This PR does not solve that issue.

And with them what's the problem?

@infograf768

I tested the issue we have when updating Akeeba back-up AND a language pack at the same time.

Can you clarify what is the problem you are talking about? Thanks!

As written above: when updating at the same time one of Akeeba comps (backup or admin tools) AND a lang pack, it creates an admin menu for the lang pack.
Below the Persian language pack.

Please create a separate issue/pr for something that is NOT solved by this PR. This PR is about missing a menu item in components by mistake. It fixes the mistake!

@test Ok, issue confirmed, PR fixes the issue.

I confirm the issue with updating Akeeba Backup + Dutch Language pack on Joomla 3.3.6, which adds a menu item in the Components menu: pkg-nl-nl.
Patch #4499 does not fix that issue.

@sovainfo
sure.

Merging this one now.

Concerning the issue with Akeeba components, I guess
@nikosdion
may have to look at it

@infograf768 It's not a bug with the Akeeba components. It is a bug in Joomla!. I have reported it 3 years ago with a proposed fix which was never accepted. At that time Sam said he was working (or planning on working) on an improved installer which would do away with these issues. Nothing happened. About 6 months ago I wrote a whitepaper on how to build a reliable extensions installer. Nothing happened. After all this work I made to fix this issue seeing it being blamed on me is, well, frustrating.

Not blaming on you, @nikosdion
I was not aware about the story behind this bug

Can we still do something about it?

Hm, good question. We can't do much with the current code. It wasn't really designed to work with package type extensions or updating multiple extensions at once. I've written the whitepaper on building a new installer but a developer can't spend the enormous amount of time required to write it without knowing what is the time frame or if it's going to even be accepted. Not to mention that it's such a massive task that no single person can volunteer for it. Working full time for 2-3 months without payment doesn't quite put any food on the table. Stretching it to a side project will probably take the development effort past Joomla! 4.0, making it a wasted effort: a new installer can only be included in a new major version of the CMS. If it doesn't cut it for 4.0 it will have to wait another 2-4 years for 5.0 and by that time the code will be outdated and will need to be rewritten. In this case maybe being stuck with a bad installer makes most business sense :(

I guess we could therefore forbid updating multiple extensions at the same time.
What do you think?

I have a better idea! Right now we are trying to download, extract and install the updates of every single extension in the same page load. Not only does this cause the interesting issues with menu items, it's also prone to PHP timeout and the more serious issues arising from partial updates when PHP dies while the update is in progress. Instead we can push the IDs of the extensions to be updated into the session, then run one extension's update at a time until the queue is empty. This should be almost trivial to implement. I have already written the very short code to do that for the Akeeba Backup SRP plugin, see https://github.com/akeeba/backup-core/blob/development/plugins/system/srp/srp.php#L340 up to line 382. If anyone's interested in adapting it for com_installer I am willing to relicense that file under GPLv2 or later to make it possible.

Something Ajax based would have been my first thought as well. Sounds like a good plan to me.

@Bakual
Can you take care of that, Thomas?

@Bakual You don't even need AJAX :) If you store the IDs in the session you can use simple redirections. Of course an AJAX solution would be much more desirable since you get the all important feedback from the operations performed. And if you go AJAX you can split the download, extraction, installation and cleanup stage of each update, leading to a far more stable update experience even on low end hosting. That's pretty much in line with what I had written in the whitepaper. If you want help on implementing this idea give me a holler.

Can you take care of that, Thomas?

I probably can't due to lack of time and also bit lack of knowledge in this particular case.

That's pretty much in line with what I had written in the whitepaper. If you want help on implementing this idea give me a holler.

Since I have read the whitepaper before, it very well may be your idea that came up in my mind again
If we can start simple, I can certainly help. But I don't have much spare time currently due to work and family.