Requests | Blesta

Requests

Plugin Logging

T. Chance Vecchitto shared this idea 4 months ago

Under Consideration

As a plugin developer we are free to implement our plugins and make them as functional as needed. In many cases, plugins are authored to either enhance, or modify processes. When they modify, it is important that plugins log what they do. Just as important that admins see what these plugins have done. This aids admins with both troubleshooting and verifying a plugin is functioning as it should.

Would be nice to be able to have plugins log activities in Blesta, and have Blesta store those entries in a new log_plugins table much like is done for the tables log_gateways, log_modules, etc. And then admins could visit Tools -> Logs and see another tab titled 'Plugins', which would reference /admin/tools/logs/plugins/. I believe this would be VERY easy and simple to implement.

Plugin developers can choose to log their plugin activities or not. Just as module developers can make that choice. For those that do log, they aid admins in both troubleshooting unexpected behavior and/or allow them to check that things are working as they should.

I like this idea

Comments (2)

Paul Phillips ● 4 months ago

Plugins can create their own tables and log to those. If we implemented this sort of logging in the core, it would force plugins that use it into a particular mold with predetermined limitations. log_gateways and log_modules have unique table structure for those very specific use cases. log_modules for example stores the URL that the module is submitting API requests to, data includes the raw data, group allows multiple requests to be grouped together. It's not likely that a url would be necessary to a plugin log.

In order to consider this, I think we'd need several use cases and example logs that would indicate to us what kind of table structure would be useful to most use cases.

Reply URL

T. Chance Vecchitto ● 4 months ago

Thank you for the feedback Paul. I understand completely. Basically we log the procedural flow.

If Blesta were to create a table for logging plugin activity, I would think it might be structured such that it stores information related to the plugin being invoked and any data relevant (less any secure data like CC/Bank information that might be present). An example table structure might be:

id - primary key

plugin_id - id of plugin

date - date of log entry

invocation - 'event' or 'standard' - plugin was called in response to an 'event' or a 'standard' plugin page load? this could be the event name, or the full URL (less the protocol and server)

params - same as params passed to plugin (either thru event->params) or an array containing the controller, action, portal.

get/post - data that was requested/posted in code (unaltered versions)

result - what did the plugin do with the request? did it redirect? did it modify a var? did it add script? did it alter the default behavior in any way? this field would be a very generic one allowing any type of data to be stored in it.

All plugin developers would be expected to provide log data to match whatever table structure that Blesta sets forth for logging plugin activity. The table structure would NOT be plugin specific. It would conform to a standard set forth by Blesta and the standard would simply be to record a moment in time, and what a plugin did with the information in that moment. If a plugin does nothing, or chooses not to record anything, then no log entry needed.

URL