Jump to content

Different logging providers


Recommended Posts

Since I'm doing a lot of detailed logging in our internal PW-based systems, that has become a bit of a bottleneck under heavy load and I was missing a centralized view with the growing number of separate PW instances. So I dug into the core a bit, namely WireLog.php and FileLog.php as well as ProcessWire.php. I managed to whip up my own WireLogDatabase and DbLog classes mimicking the behaviour of the regular logging classes, but not without a little bit of tweaking to the ProcessWire class itself to replace the regular logger. Now I'm logging to a MySQL server instead of plain files and ProcessLogger works smoothly with it without tweaking.

I thought it would be shame to keep this all to myself, but a release-worthy version would need or could benefit from:

  • a bit of polishing in regards to error handling and proper treatment of conflicting concurrent operations without too much lock overhead (drop table vs. insert especially)
  • more source code documentation
  • a little more abstraction so all csv operations are deprecated in favor of database columns where avaible
  • last but not least, an approved way to configure the substitute logger and load it early on, which means touching the core ProcessWire class

Before I invest too much into that, I'd love to hear all thoughts on this, especially if you think such a module may fit your requirements, and I would be especially happy to hear from @ryan - could you see such a mechanism in the core?

  • Like 15
Link to comment
Share on other sites

2 hours ago, LostKobrakai said:

The most flexible version would probably be a monolog (or compatible) implementation, just because how ubiquitous it's in the php community and all it's adapters to various logging backends.

There is a monolog plugin for Tracy: https://componette.com/nextras/tracy-monolog-adapter/ so if you're already using Tracy for logging errors in production mode (no debug bar), this might be an option.

If people are interested in that approach, I'd be willing to add.

PS - @BitPoet - not meaning to take away from your approach - just throwing another option out there.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...
  • 3 years later...
On 1/22/2021 at 12:26 PM, salmiak said:

Did you make any progress since you posted this?

Unfortunately not. There were changes in the core that broke my own changes, and I simply didn't have the time (a recurring topic, lately...) to fix that at that time, so I switched back to regular logging.

Link to comment
Share on other sites

  • 2 weeks later...


On 3/17/2017 at 1:26 PM, LostKobrakai said:

The most flexible version would probably be a monolog (or compatible) implementation, just because how ubiquitous it's in the php community and all it's adapters to various logging backends.

I'm working making a module integrating monolog into processwire now. When hooking into WireLog I can intercept most logs. Except for fatal errors. These dont go through WireLog but are sent from WireShutdown to FileLog directly. 

I don't really know if there is a way to intercept these without hacking the core.

Does anyone have an idea?

Link to comment
Share on other sites

1 hour ago, salmiak said:

I don't really know if there is a way to intercept these without hacking the core.

Does anyone have an idea?

Sorry I'm short in time ATM, but I think in general this is handled by PHP https://www.php.net/manual/en/function.set-error-handler.php

You will find such function calls in pws wire directories, for example in WireHttp.php and other files. As far as I remember right, it is possible to define multiple handlers in PHP that you can use by "bubbling" (or cascading) and maybe conditionally exit that at any point.

You definetly dont't need to hack the core. Maybe the PHP manual is a good starting point. Next would be to find where PW handles it and how to set you above this, do your logging and after that pass the event through to PWs handler where needed.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By prestoav
      Hi all,
      I could have sworn I used to be able to use the site generic 'title' field as a sub field of a repeater field. However I've tried to do this on two 3.0.165 sites recently and, while it will add the title field in the repeater field setup, it wont save the repeater title sub field's content when the repeater is used in a page template and edited.
      It;'s not a big issue but I wondered if this was a known restriction?
    • By picarica
      so this is really weird issue i am so confused about this, so i have setup 'images' field where i put images and the include them in CKeditor, should work right? well it works on some sites, i use it nearly in every page but at one page, the images included in that CKeditor only show up, when i am logged into processwire, when i turn on incognito mode the images dissapear, but only on this specific page, everywhere else it works perfectly, has anyone came across this issue? i have nowhere in the site login checker, i have no idea what is going on
    • By Guy Incognito
      I seem to be running into a repeated fatal error in a fresh PW install version 3.0.148. I can't quite put my finger on the pattern but it seems to be around deleting image fields or removing images from certain image fields.
      This is the trace from the log generated by trying to save a page and delete an image from an image field:
      Fatal Error: Uncaught Error: Cannot access protected property Pageimage::$original in /wire/core/PageimageVariations.php:256 Stack trace: 1. /wire/core/Pageimage.php(1327): PageimageVariations->getInfo() 2. /wire/core/Wire.php(386): Pageimage->___isVariation() 3. /wire/core/WireHooks.php(823): Wire->_callMethod() 4. /wire/core/Wire.php(450): WireHooks->runHooks() 5. /wire/core/Pageimage.php(1369): Wire->__call() 6. /wire/core/Pageimage.php(399): Pageimage->getOriginal() 7. /wire/core/WireData.php(333): Pageimage->get() 8. /wire/core/PageimageVariations.php(256): Pro Line 256 of /wire/core/PageimageVariations.php Earlier in the day I was experimenting with custom fields for images for the first time and kept running into this error, thinking it was me using this feature wrong and not having time to read up I deleted the custom image fields template and went about my business. So now I don't know if I triggered an issue or whether it was never related to the custom image fields in the first place?
      Any ideas?
    • By chrizz
      Usually I write modules just for me and my projects because they are more or less individual. Mail Debugger is the first module which might be interested for someone else as well. 
      Basically it covers two use cases: 
      1) Log outgoing emails
      2) In debug mode mails are send to a specified email address instead of the original recipient(s)
      I checked the compatibility for PW 3+ because unfortunately I don't have any other version for testing currently. Feel free to drop me a comment if the module works also for older PW versions. 
    • By workdreamer
      I am starting to use ProcessWire.
      So, i need to extend the ProcessTemplate Module. I need to add a required field to the templates into the Advanced Tab (for personal purposes)
      I already added the field, but inside the core folder, but this is a very bad practice.
      The best would be add the modifications inside the site folder.
      How could i extend the core module ProcessTemplate in order to not affect the core, and the processwire read my extended modifications.
      Thank you very much everyone.
  • Create New...