Actually, only components can use the config.xml file (and have to). From what I can tell, components would actually be the extension with the inconsistent behavior; modules, plugins, and templates all have a single manifest file and config. I'm not sure I'd personally add in this mixed behavior for plugins.

Hi,

Thanks, I'm just starting to contribute again, so I'm trying to understand how, or why, somethings are intended to be, or have different behaviour. I just would like to understand…

As components, plugins, templates and models are all extensions, I can't see why they have different rules for the same "information", the config data. It is nothing than a form file (the config.xml), so why should it be inside the manifest file for some types of extensions and not for the other? Shouldn't we always work to add consistency? So, if the use, meaning and behaviour are the same (the config descriptions), why force different ways to specify that?

The main reason to have a manifest file is for installation purposes and to describe the extension's meta data. So why add a kind of information that will not be used during the installation process, or even will be not cached with the rest of the manifest data? So if we tell that the manifest data is cached, but the config data is not, we have inconsistency since that tags are inside the manifest file…

And it is not forcing to use a separated config file, it only allows to use that, if I want… Less files in the extension folder is clean, nice, but using different files to store different kinds of information, sounds more organised, for me… For example, I don't think that is a good practice to write more than one class on a unique PHP file, so for the same reason, we shouldn't mix installation data with a form data (the config)

You can see on this doc page: http://docs.joomla.org/Manifest_files on the "Configuration" subtitle:

...The element, a child of the root, describes the configuration options for the extension. If applicable, the options will be shown by the appropriate Manager (Plugin Manager, Module Manager or Template Manager). Configuration options can also be defined in a separate file named config.xml. Its root element should be …

That documentation is not only for components, it only warnings about that is the standard behaviour for components, but the idea of to use a different file for configuration is clean on that paragraph…

Actually I still couldn't test it for modules or templates… But I think that all extensions should support, or even force, to use a separated config file, like components...

@andergmartins The main reason probably is that while they are all extensions, they are not the same and it's different components dealing with its settings in each case.
Modules and plugins usually have only a few settings and it works well to have those settings in the manifest file. Components tend to have much more options, so it made sense to have them all in a separate file.

I agree with Michael here that if we want to have consistency, we would have to change the component behavior :)
But then I'd rather change the doc and say that the components behaves differently here.

I would not add a second alternative option to look for config stuff. It only makes code more complicated than it already is and doesn't add any real value.

Ok, got it, thanks. But I still think that one "if" statement is not actually a complicated code… I agree with you about components are usually more complex than modules or plugins, but some modules are really full of params, more than many components… so if Joomla guys decided to change this behaviour for component some time ago, I think it should be replicated to the other extensions… I know that each extension is handled by different components, but since all that components are native, from the same framework, all of them should have the same rules for the same kind of information… so instead of add a second alternative, lets change that to mirror the components rules for config, using a separated file…

Consistency, for itself is not a real value? I can make the changes and update this pull request, for the components, modules, plugins, according what will be better for Joomla… if you agree.

I'd say update the PR to offer the same function across components, modules, plugins and templates (so it's really consistent).
If enough testers test it (usually two), it will be considered for inclusion.

Right, working on that ;)

I can see the value of adding this behavior, not only for the sake of consistency, but especially if it is not mandatory. I have seen use cases where a plugin or module could benefit from this separation of code.

@test successful

This PR can only be accepted if you provide the same consistent behavior for all types of extensions (missing here: modules and templates). Please update the PR, so we can take another look on it.

Thank you!

Ok, thanks. I will work on that.

Also, please create a new PullRequest targeted at the staging branch then and close this one. Thanks.

@andergmartins It has been 4 months since the last comment from you. Are you still planning to contribute code for this or shall I close this issue

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/2660.

Hi @brianteeman, yes, I will contribute, please keep it open.

Thanks

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/2660.

I'm working on these fixes, and closing this PR to create a new one...

Just created a new PR, as requested: http://issues.joomla.org/tracker/joomla-cms/5342

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/2660.