If you install a language using the discover method then it can never be uninstalled because the discover method doesnt not install the package and we have something to prevent you uninstalling a language
A language should always have been installed as a package.
To uninstall a language, filter type by package and uninstall the package.
I never understood why language packs should only be able to be uninstalled as a package. Imho they should behave the same as other packages do.
Or https://developer.joomla.org/joomlacode-archive/issue-29604.html if you're trying to avoid a hunk of crap software package
The issue there is a legitimate one, but the fix needs improvement to work for all package extensions. You are correct in that the distributed language packages are always package extensions composing of the individual language extensions. However, if those individual language extensions are installed separate from the complete package, it still needs to be possible to uninstall those.
So as I said, we need to improve the relationship tracking of package extensions instead of just treating it as a glorified collection. Not just for languages, everything that uses the package type. This way a developer can toggle via the API whether an individual extension installed as part of a package can be uninstalled separately or if removal requires the full package to be uninstalled (which the current code does for language extensions).
I knew where it comes from, but still never understood it
The issue there is a legitimate one
Yes, but it was fixed the wrong way. Because currently when you accidentally delete the language files, you can't reinstall the language from the manager since Joomla thinks it still is installed. You also can't uninstall it since the package manifest is missing.
A better fix would be to allow installing languages even if they are already installed. In the manager, you could mark them as installed, but still offer to (re)install.
Folks, any solution you code correctly is fine for me.
At the time, nobody objected to the solution proposed.
Status | New | ⇒ | Confirmed |
So long and farewell
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-12-09 15:34:23 |
Closed_By | ⇒ | brianteeman |
So long and farewell
How do we take that? No fix in the making? I guess, since the same problem is still alive and kicking 4 years later.
How do we take that? No fix in the making? I guess, since the same problem is still alive and kicking 4 years later.
Well that issue was closed in 2016 when this is still an issue please open a new issue with the steps to reproduce it now so we can keep track of that. Thanks.
it is still an issue
Well that is the problem - it is not reproducible, it just happens every now and then to arbitrary languages.
Afaik you can now at least reinstall the language pack and then properly uninstall it. At the time of this issue, this wasn't possible.
This whole process is flawed. If we really want to block uninstalling individual extensions that are part of a package, we need to add data to the extension records indicating this parent/child relationship and have this be a configurable behavior via the API.