logger: Refactor logger to DB based implementation

[sinukaarel]

The file based implementation for the log storage has a flaw - the plugin folders are deleted when upgraded, so using them to store any data is problematic. Instead of using a file for storage we should use some other solution. One possible solution for this is having a separate table for our logs. This PR implements the database based solution.

[sinukaarel]

@kaittodesk I need a second opinion.

We have encountered errors that are replicable only in the client environment. The error log has been a great resource for tracking possible errors, however, we must implement a change. The error log should not live in the plugin directory as it gets deleted between version upgrades.

The official recommended way is to use the upload directory:

We recommend using the uploads directory, creating a folder there with the slug of your plugin as name, as that will make your plugin compatible with multisite and other one-off configurations.

So we have three options to migrate the logger storage:

1. use the error_log function and if the user has enabled the WP_DEBUG and WP_DEBUG_LOG then logs will be appended to the official log file.
2. use the DB solution where we store our logs in a DB. We already use the abandoned_carts table so the setup/teardown logic can be similar.
3. use the upload directory but restrict access (.htaccess) from the browser.

The number 1 solution has a caveat that when the User has not enabled logging errors we don't receive any helpful debugging information.

The second option allows us to better manage log lifetime and we don't have to think about polluting the global log file with information only useful for our plugin context. I would also like to add a "download logs" functionality to the settings page that users could send us when experiencing problems. Allows to show errors in UI, but is more complex.

The third option has all of the benefits of the second option but needs access control.

I kind of went with the second option first, but I don't think the added DB complexity is justified. So I eventually went with the third option and moved the log storage to the uploads folder. I feel like the client probably has some browser-based FTP solution in their hosting provider and can send us the log when required.

As we have our own log file then I would keep this out of the WP_DEBUG and WP_DEBUG_LOG option configuration. Then we can still view the logs when the user is not enabled the global logging.

[kaittodesk]

This relates to issue I created for Smaily for WooCommerce plugin - sendsmaily/smaily-woocommerce-plugin#142.

Under the linked issue I suggest the correct approach would be to use error_log callback and I think the same approach should be used in this instance.

I think using error_log has multiple benefits - self-managing, secure, flexible and compliant.

• Vast majority of servers have some sort of basic log rotation set up, which means log file size is kept automatically under control by the server.
• Security is increased, because log files are not kept in a public site directory where configuration error can lead to potential data leak.
• Flexibility is introduced, because PHP's error logging could be configured to forward logs to centralized service.
• Compliancy is achieved, because the organization could define their own time period for keeping log files, which will align better with organization's existing log management policies.

The downside of using error_log is accessibility, like you describe. However I think this shouldn't be an issue as hosting service providers usually grant users access to server error log files through webFTP or admin panels.