Posts: 25
Threads: 5
Joined: Oct 2014
Reputation:
2
04-07-2015, 01:28 AM
(This post was last modified: 04-07-2015, 06:34 AM by ciadmin.)
CodeIgniter should have a better error logging system.
I suggest that error logging should have some options:
1- send error to email (I would like SMTP)
2- save POST, GET, SESSION variables.
3- save URL
4- save user IP address
I think improving error logging is something that should not affect the CodeIgniter performance.
My experience:
Excepting option 2, I used that for better understanding the error.
Because "Trying to get property of non-object ..." does tell me where the error occurred, but it doesn't tell me:
- what user saw that error(maybe the error was in a middle of a function and half a function has run). (option 4)
- maybe that function is used in multiple places (option 3)
- option 1 is to monitor error in real time, and resolving them fast.
Posts: 25
Threads: 5
Joined: Oct 2014
Reputation:
2
On logging I don't think that are everyone has his own requirements, despite on auth library where everyone would have own requirements.
For exemple on most servers the mail() function is disabled to avoid spam, so you must send through smtp which you must use a library for that.
I couldn't make Email class(from CodeIgniter) to work from Log class and I couldn't extend Log class to intercept all php&db errors.
All I mentioned should be optional, so each user should choose.
Improving error logging is something small and usefull.
I don't like ideas about CodeIgniter having auth library or template library or using composer.
Posts: 185
Threads: 7
Joined: Oct 2014
Reputation:
23
If anything I think we should have the default "ci logger" and a simple way to bootstrap something like monolog (or any PSR3 interface compatible logger) would be best.
I have already extended log (MY_Log.php) to do this.
When simple logging is needed the standard CI version fine for my work.
Then simply by composering in monolog I can setup a log.php config file switch a setting in config.php and start using it.
Having the CI team write and support 10 different logging methods I feel is overkill.
I would rather have them focus on something else.
I do think we should support all the PSR3 levels in the built in package thou. This way dropping in a PSR3 logger the level would map directly.
DMyers
Posts: 477
Threads: 18
Joined: Oct 2014
Reputation:
21
A stack trace would be nice with the errors.
Posts: 1
Threads: 0
Joined: Apr 2015
Reputation:
0
actually it needs a better logging system supports multi output driver(file_system, raven, logstash, xhprof, etc...)
Posts: 1,101
Threads: 4
Joined: Nov 2014
Reputation:
95
I think a PSR-3 compatible logger (with an easy way to replace/extend the logger) and some improvements to what is logged internally would be enough. Once you can use any PSR3 logger, you don't really need to worry about supporting all of the different output types, since there are likely already loggers available which do so (or it's relatively simple to develop one if there is not).
Posts: 2
Threads: 0
Joined: Apr 2015
Reputation:
0
I would like some way to override the default logging with external tools like log4php, pear Log or wathever with the ability to keep CI related traces.