By creating FLEXIcontent, one of my aim was to make it the more extensible as I could trough the Joomla! plugin system (which is according to my opinion one of the most powerful system in Joomla 1.5). Thus, each field type is a standard Joomla plugin, allowing third party developers to easily create their own according to their needs. If professional Joomla developers rely on this system, we should see very soon a series of plugins that will significantly increase the scope of the software.
There are four types of plugins within FLEXIcontent:
It has mainly two functions: it prevents backend users using the standard sections/categories/articles (except for Super administrators). Thus, the links to the standard article manager are automatically redirected to their counterparts in FLEXIcontent. This avoids loosing fields or extended data when modifying content outside FLEXIcontent.
The second function is roughly the same, but this time for the frontend. All link com_content links are automatically redirected to their counterparts in FLEXIcontent
This allows, for example, to use the modules designed for com_content without having to change them.
Since the beta4 release you can configure backend redirections in the plugin configuration.
It works like traditional search plugins, except it’s able performs full text searches with Boolean operators - AND: + sign, OR: nothing, NOT: - sign and WILCARD: * sign (see also contents chapter). To avoid duplicate content in the search results, it is strongly recommended to unpublish the Joomla! search plugin (search.content).
These are the famous plugins that allow third party developers to design their own field types. In the example of the existing plugins, the logic is fairly simple to understand. The observed events are:
onDisplayField: It renders the field form element to be displayed in the item form
onDisplayFieldValue: It renders the field to be displayed in the website
onDisplayFilter: It renders the filter dropdowns in category views. I’ve arbitrarily chosen dropdowns, but after all, everyone is free to design them otherwise ;-)
onBeforeSaveField: It processes data before saving the field values. This allows for example to handle uploaded files or to reformat the $_POST data.
onAfterSaveField: It processes data after the storage of the field values. This event is not used in the standard fields but it will be soon. Its aim is to allow the connection or integration with third party components. We could imagine the automatic creation of a product in Virtuemart, or a Joomla! user, a.s.o. …universal plugin support in this article. The only event currently triggered is "onPrepareContent”. Beware, however: all plugins are not necessarily designed to run outside com_content! They may need small modifications.