Joomla! Documentation™

I find the terms "frontend" and "backend" confusing when applied in this context.

also, links to the standard parameter types would be extremely useful. http://docs.joomla.org/Standard_parameter_types

Overall, I found the article extremely useful.

Commercemeister, thanks for your comments. Could you please explain what you find confusing about frontend and backend? They are commonly used to refer to the main site and the administration parts of a Joomla! website, respectively. It would be helpful to know how you think they should be clarified (or you could even just do it yourself - that's the beauty of a wiki!). Thanks too for the note about parameter types - the article did originally link to a page with this information, but then that page was changed. I will update it.

One final point - please sign your comments using the four tildes at the end (~~~~). Thanks, Mike 16:18, 3 September 2008 (EDT)

I'm confused about the differences between the types of parameters. So you've got Parameters (Basic), (Advanced), (Component) and (System).

Now what kind of parameters would you put in (basic) and what in (component) if both can be overriden in the menu you create for the component ? I just don't see the distinction between the two... Alfred 14:12, 25 September 2008 (EDT)

Alfred, 'Basic' and 'Advanced' parameters are just 'article-specific' parameters - the only difference between 'basic' and 'advanced' is in how they are displayed in the back end. 'Article-specific' parameters are those that are only ever going to apply to that article, whereas 'Component' parameters are set for the component as a whole. As you point out, both types can be overridden for a particular menu link; administrators using your component will thank you if such overrides are the exception rather than the rule!

So, in the screenshot shown, there is the basic parameter 'Description text' field which (IIRC) provides a description of the article. It would make no sense to have this as a component parameter, since you would need to override it almost every time you use it. Note that there is no 'right' or 'wrong' here, just common sense. If a parameter is likely to be the same across the site (e.g. choosing whether or not to display the name of the author, which is likely to be fixed to maintain a consistent feel to a site), then put it in the component params. If it's likely to change in each case, make it an article param. If both would be useful, then use both. (Just make sure that you give the article param a 'Use global' (i.e. empty string) option as default, so that the component parameter works as expected.) Mike 18:23, 28 October 2008 (EDT)

Component level params must be saved before they show up

I've seen this effect in several extensions, and it was very confusing and not obvious at first. Perhaps a note can be added. The issue is that the default params for the component, usually accessed by "Preferences" may not have been actually entered into the database.

It would be nice to just have a note, especially in the overrides section, that you need to make sure the component params are actually saved. It would also be nice if 3rd party components that use these config params either place a notice to the user that params must be saved, or make sure that the default params are entered into the database during the installation process, if these params do not yet exist.

Hope this makes some sense. I'm not really sure the best solution to this problem, but more documentation about this potential pitfall I'm sure would be helpful.

Snellcode, good point. Tbh, I think the whole parameters subject is a little difficult to get hold of - my main reason for writing this was so that I could get everything straight in my own head. The way it should work is that the COMPONENT_NAME.xml installation file creates the parameters in the database, so that the component defaults are already set. If this is not done, then you are right - it is necessary to open the 'parameters' window, choose the values, and save, so that the parameters are created. The wrong way to do things, which may be what is going on, is to try to combine both steps (ignoring the installation file) and give the <param /> elements in the config.xml file default values. These will show up in the parameters window, but do not appear in the database until they are saved. The article does kind of refer to this, but I will think about how to make it more explicit.

You could try point the 3PDs to this article, or simply vote with your feet and use a different extension! Mike 21:36, 17 February 2009 (UTC)

Referencing the parameters XML file in the install file

I have deleted Jmgonet's paragraph about adding a reference to the install file, as I think it is outside the scope of this article (which tbh is already complicated enough!) The article is aimed at those developing components, who should be aware of the need to ensure that all necessary files are installed (covered adequately elsewhere). In any case, the best option is to use a <folder /> tag in the install file, rather than lots of <filename /> tags; that way, there is no need to list every single file, and less risk of a file being missed. Hope that's ok! Mike 21:54, 17 February 2009 (UTC)