Skip to content
This repository has been archived by the owner on Nov 26, 2017. It is now read-only.

Fix Inconsistent refreshManifestCache and missed manifest file for modules, component and plugins #1524

Closed
wants to merge 1 commit into from

Conversation

andergmartins
Copy link

It was looking for a fixed file name for manifest, instead of use the installation behavior, to use the first valid manifest file found.

If someone install an extension with a manifest.xml instead of mod_myext.xml, it's ok, until the user refresh the manifest cache or try to add a module (joomla will not find the right manifest file).

For modules, components and plugins.

@pasamio
Copy link
Contributor

pasamio commented Sep 17, 2012

Apart from a bad side effect of the installer not really caring what the file name you've used is, I'm not sure we've ever documented support for a 'manifest.xml' file.

@mahagr
Copy link
Contributor

mahagr commented Sep 18, 2012

It happens on every non-standard file name. They are perfectly accepted during the installation, but Joomla fails to find them during uninstall. It's a bit annoying as many extension developers end up thinking that their extension works even if it doesn't.

I would either force everyone to use fixed file or fix the code to work with any file name.

@andergmartins
Copy link
Author

Yeah... Agree!! As it is now is an error... it must be consistent. Or accept that fix (or another one) or force a fixed manifest file name.

I know that some extensions developers (including me into JoomlaBamboo) are using the possibility to use different file names for manifest files, as a way to target different versions of joomla in the same package... So they can build an unified package to all joomla versions...

@mahagr
Copy link
Contributor

mahagr commented Sep 21, 2012

We are doing the same, but we are renaming (moving) the manifest file on postFlight() to match the Joomla naming.

@pasamio
Copy link
Contributor

pasamio commented Sep 23, 2012

Wouldn't forcing naming then break your ability to do what you're aiming to achieve?

@andergmartins
Copy link
Author

Yeah, would break... what we do with the manifest file is a quick fix... For example, we are almost releasing the ZenGridFramework 3 (JoomlaBamboo) and we are forced to use a build script to separate packages for J < 2.5 and 3.0... Because it will install but after we will have problem with cache and uninstall...

I would love a native Joomla solution for unique packages, the ability to create a package with different manifest files for different j versions, so we could copy during installation just the specific files to each version... I saw a project for that, but I think it was not popular... but without that, as extension developer are forced to make some workarounds...
Joomla has a nice idea to maintain backwards compatibility in some codes, extensions whenever is possible... so why not support that into installation files? They are the front port for any extension...

@andergmartins
Copy link
Author

With this fix, we can at least explore the ability to set filenames in specific alphabetical order so a valid manifest file will be found in the right time for each J Version...

If you and the community like, I can work on a formal solution for support unique packages... I will not use my time in a feature that I "know" will not be accepted...

@pasamio
Copy link
Contributor

pasamio commented Sep 25, 2012

Well if you updated the extension adapter copying the manifest file and forcing a particular file name at the destination and then just added checks for files at a minimum depth (so as to not break extensions with sub-extensions in their package) you could just looked at the version attribute for the latest of the file then use that version of the file and the adapter would put the correct file in the correct place.

As an aside, this particular package is in the process of migrating to the CMS.

@andergmartins
Copy link
Author

Actually that fix, just remove duplicated code to get a manifest file, what fix the inconsistence. It reuse the logical inside installation class, so it is just using a OOP concept... Installing, uninstalling and updating the cache for manifest, should always use just one common method to find and return a manifest file... This fix is all about that, not really to be able to build "unique packages"...

Reusing that way, if the installation method to find manifest need to be changed, we just need to make in one place... I think that it is the right way to code... what can avoid inconsistencies...

@andergmartins
Copy link
Author

Without that, installer allow to install a manifest.xml, but fails uninstalling or updating the cache... this is the real issue here.

@pasamio
Copy link
Contributor

pasamio commented Sep 25, 2012

There is more than just the installer that looks for files in certain locations.

@ianmacl
Copy link
Contributor

ianmacl commented Oct 31, 2012

Closing this issue as it no longer merges. Also, these classes have been moved to the legacy tree so it is up to the CMS to decide whether they want this change or not.

@ianmacl ianmacl closed this Oct 31, 2012
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants