All plugin are stored in a « pluginext » folder (defined in config.php file)
Each plugin are the same folder structure :

• config
  • <plugin>.json
• controllers
  • <plugin>.php (controller class file)
• language
  • (list of language folder)
  • <lang>/
    • <plugin> _lang.php (like in cloudlog core)
• migrations
  • (like in cloudlog core, but not implemented for the moment)
• model
  • PE_ <plugin> _model.php
• views
  • cl_pluginsext_edit.php --> used for configured the plugin (global param of plugin) ;
  • cl_pluginsext_javascript.php --> file include in footer.php core (only javascript function in this file)
  • cl_pluginsext_menu.php --> used for create some interface/method for the plugin
  • <plugin> (folder)
    • (add some view php file for the plugin ; this file is adding if cl_pluginsext_menu.php, if it not enough)

The main controller in cloudlog is « pluginsext »
3 main methods exists :

• /menu/
  • Used for load the plugin like an other cloudlog controller
  • You can see the plugin in the specifiq menu
  • Authentification is obligatory
• /ws/
  • Used like a webservice exchange ; return a structured json data
  • Authentification is obligatory
• /ex/
  • Used for call a plugin method without authentification (but user param is obligatory)
• Structure of pluginsext URI
  • /cloudlog/index.php/pluginsext/<method>/<plugin>/pluginmethod…

When I started this project, I couldn't keep up with the pace of development of Cloudlog's output.
I therefore decided (as for other products) to develop external "functionalities" which do not impact the existing core code.
The implementation of functionality allowing easy integration and independent of the Cloudlog core came to my mind (like a marketplace).