[#8089] - Allow folders in packages to be uninstalled like zips
- Closed
- 25 Oct 2015
- Medium
- Build: staging
- Easy Test
- # 8089
- Diff
- Bakual:FixPackageUninstall
- Success Human Test Results: 2 Successful 0 Failed. Details
User tests: Successful: Unsuccessful:
Issue
The package installer allows to include the contained packages either as zip files or as plain folder.
All works fine when the extensions are contained as zips, but when you have them included as unpacked folders it installs fine, but doesn't get uninstalled together with the package.
For regular extensions, that isn't as much as an issue as you can still uninstall the extensions manually. However in the case of language packs, we have a special check there which enforces that language packs can only be uninstalled as package (don't ask me why). And thus when you uninstall a language package which contains admin and site as folders you will not be able to uninstall them.
So the following works both with install and uninstall:
<files>
<file type="language" client="site" id="id-ID">site_id-ID.zip</file>
<file type="language" client="administrator" id="id-ID">admin_id-ID.zip</file>
</files>
while this only works for install:
<files>
<folder type="language" client="site" id="id-ID">site_id-ID</folder>
<folder type="language" client="administrator" id="id-ID">admin_id-ID</folder>
</files>
Solution
This PR just adds folder tags to the "filelist" array in the package manifest builder. From there everything works again.
Testing
We found this issue while testing out Crowdin for creating the core language packages. Thus you can try one of the completed packages from there. Eg:
Indonesian: https://crowdin.com/download/project/joomla-cms/id.zip
Bulgarian: https://crowdin.com/download/project/joomla-cms/bg.zip
They should install fine, but when trying to uninstall the package, the actual language packs for site and admins aren't uninstalled.
After the PR is applied, they will be uninstalled together with the package as expected.
Obviously also try with a regular package that this still installs and uninstalls fine. You can use any of the official language packages (using the language manager) or a 3rd party extension package to test that.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
|
||
It's out of the scope of this PR as this is only about a bug in the uninstaller. The language packs generated by Crowdin are only how I detected it and the simplest way to test it. I could instead have written a custom package for a regular extension instead, but why do when I already have an example at hand 
The names of the .zips proposed above (id.zip, bg.zip) do not follow the format used to pick them in the http://update.joomla.org/language/translationlist_3.xml for Extensions=>Updates proposed as well as install from Extensions=>Manage=>Install Languages.
They are not meant to be picked up by that. The download location for the files currently still is JC, and it will be an own server in the future (the same as for Joomla packages).
(I wonder what would happen if en-US and en-GB both get a en.zip)
You can have a look at https://crowdin.com/page/api/language-codes and see that they have en-US and en-GB there. That's what the names will be for the generated zips in those cases.The package name should be of the type:
xx-XX_joomla_lang_full_3.4.4v2.zip
The pkg_xx-XX.xml above have a wrong version as well as other xmls:
we use for example: 3.4.4.1, 3.4.4.2 etc. for users to know which version is installed on their site.
It is specially important in the pkg xml for updates to function properly.
It's not about if the language packs are named correctly or if the XMLs are written properly. That's a different topic and something the translators have (and will) fix before releasing any pack.
These linked packs currently are only meant for testing purposes, not for a productive use.
I have tested this item 
successfully on 2c7ce58
This is what I said when I wrote:
unrelated to the possibility or not to include folders instead of .zip for admin and site
Anyway, this patch works, for the packs you posted as well as former format.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8089.
| Category | ⇒ | Libraries |
| Easy | No | ⇒ | Yes |
I have tested this item 
unsuccessfully on 2c7ce58
Before applying the patch I get the following error messages when I try to install the provied bg.zip:
Local environment:
Fatal error: Maximum function nesting level of '256' reached, aborting! in C:\xampp\htdocs\patchtester\libraries\joomla\table\table.php on line 136
http://de.joomlapbf.com Installation:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /home/eabbcbdv/public_html/de/joomla1/libraries/joomla/database/driver/mysqli.php on line 567
Indonesian package:
Local environment:
Error
There was an error uploading this file to the server.
Unable to find install package
http://de.joomlapbf.com Installation:
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 64 bytes) in /home/eabbcbdv/public_html/de/joomla1/libraries/joomla/database/driver/mysqli.php on line 567
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8089.
@matrikular I see where that comes from. I have recently updated the source package file on Crowdin and the packages aren't upated yet to reflect that change. Thus the generated zips are broken as of now.
I will try to see if I can get a working zip uploaded somewhere else later this day for the tests.
...following for testing with another zip
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8089.
@designbengel @matrikular You can try with this zip: www.bakual.ch/images/pr8089/bg.zip
I have tested this item successfully on 2c7ce58
Tested on localhost.
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/8089.
| Milestone |
Added: |
||
| Milestone |
Added: |
||
| Status | Pending | ⇒ | Ready to Commit |
| Labels |
Added:
?
|
||
rdeutz
- | Status | Ready to Commit | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-10-25 10:26:05 |
| Closed_By | ⇒ | rdeutz |
| Labels |
Removed:
?
|
||
| Milestone | |||
| Milestone |
Added: |
||
| Milestone |
Added: |
||
| Milestone | |||
Some comments (unrelated to the possibility or not to include folders instead of .zip for admin and site):
The names of the .zips proposed above (id.zip, bg.zip) do not follow the format used to pick them in the http://update.joomla.org/language/translationlist_3.xml for Extensions=>Updates proposed as well as install from Extensions=>Manage=>Install Languages.
(I wonder what would happen if en-US and en-GB both get a en.zip)
The package name should be of the type:
xx-XX_joomla_lang_full_3.4.4v2.zip
The pkg_xx-XX.xml above have a wrong version as well as other xmls:
we use for example: 3.4.4.1, 3.4.4.2 etc. for users to know which version is installed on their site.
It is specially important in the pkg xml for updates to function properly.
Concerning:
The manifest is a package and as such, has to be uninstalled as a package. If a part of the package (site or admin) is uninstalled we get errors.
Also as many plugins (admin) need their ini files in frontend, we anyway should never install a pack without at least some admin inis, see:
https://docs.joomla.org/J3.x:Making_a_Language_Pack_for_Joomla#The_Site-only_pack
A third party extension lang zip is not usually a package type manifest but a file type manifest. See
https://docs.joomla.org/J2.5:Making_non-core_language_packs
https://docs.joomla.org/Creating_language_packs_for_extensions_in_Joomla_2.5
Hope it helps