Error log function

[squirll]

Hi, here is some idea to use

in index.php line 1130

public function logger($log) {
    if ($log != '') {
        $fh = fopen($this->base() . '/log/log.log', "a");
        if (is_array($log)) {
            fwrite($fh, date('Y-m-d H:i:s') . "\n");
            foreach ($log as $key => $value) {
                fwrite($fh, $value . "\n");
            }
            fwrite($fh, "\n\n");
        } else {
            fwrite($fh, date('Y-m-d H:i:s') . "\n" . $log . "\n\n");
        }
        fclose($fh);
    }
}

make /log/log.log directory and file in root of framework and call it $this->core->logger('whatever'); and now is easy to make any log ;)
i hope that i help someone ;)

[volomike]

Usually on Ubuntu Linux I just do "tail -f /var/log/apache2/error.log". However, I do see the added benefit you offer here because error_log() alone won't give you a date and line wraps by default. And, for that matter, throw in a unique session ID so that people can track errors grouped together by session ID.

I do like the idea of tacking it onto the core.

I would like to suggest we add input parameters to flip on some booleans for things like date, script name, and session ID, and have these on by default. Please consider and let me know if you agree.

[squirll]

Yeah i know for apache error log but for clients and someone who don't know good system administrator its much easy to check scripts error log, and sometimes apache not making error log... this way (by me) is easy...just set 777 chmod on this and no worries :)
I get new idea to improve this... To call log.log file by date.. so date('Y-m-d').log everyday will have new file and you will avoid one big file.

Session ID is very good idea i agree, and maybe some more details like browser info...

P.S i start working with your FW and i love it, small/simple/clean ... and i will probably have some new ideas so sorry if i'm pain in ass :)

[volomike]

Some may prefer separation by date, while others may prefer one log file.

Have you ever wondered why many frameworks end their log files in .php? It's the same reason why, early on, people wanted me to change site.conf to config.php in the early revs of Faster MVC framework -- it's all about prying eyes and not trusting that someone junior in skills would setup their .htaccess file properly to block access to .conf or .log. So, for this reason, you may want to default to storing the log data in a file ending in .php, and using a die() statement at the top, unless someone flips a boolean parameter from the default to use .log. However, in my case, I'm a whiz with .htaccess files and blocking things from prying eyes -- so I would probably use .log instead of .php when I used it on a server.

///

Love to see the framework get traction. Yeah, I had a much larger framework called ObviousMVC, but then realized I should just pair it down and use best-of-breed components because that's what I do, anyway. I mean, do-all frameworks just can't keep up with the rapid change going on. Now this Faster framework is so simple and so zero-config, almost every project can use it unless you are handing off to a client who doesn't know what the heck a controllers folder is for and why it would be necessary. (Many Internet Marketer type clients don't know what a controllers folder is or why it's useful to use MVC. Often they are thinking short-term, not long-term, and I have to adjust and deliver results to suit their expectations.)

Keep the suggestions coming, but note that I work out of my house and often have 2 clients at any given moment, working very hard, so I have to batch up suggestions and tackle them.

///

Keep honing your idea here on the logger class method of the core class and we'll interact a bit more until we finalize it into the framework.

[squirll]

About extension, you are right... everybody have other request. But i think that MVC script usual puted on server by programmer and he know to block files from direct access. If that problem you can put in config file what extension to be log file, so it will be easy for change.

But about separated by date i dont agree... i have some situation that learn me to keep separated.
My client have script who saves all error logs in one file, sites get all day some errors but not so important that owner/user can see so sites works normal, one day he get problem and site stops work , i was need to check error log file, that file was big around 8GB.
So i need to check log file... who is big 8gb , you cant delete it because maybe you lose some important error log...and if someone(some other programmer) have slow collection he need to download 8gb big file, and if you have some slow connection(mobile connection or 512K) thats take a time, alot.. all that you need to download just to check what error you have today...
If you keep separated, you just open log for that day... OR to say client to clear log file every day, but thats not so good :)

///
I don't like big FW like Zend, because its too heavy and alot functions that maybe i will not use + half of that you didn't wrote so almost script is not write by you :) i love to write, but i need something to setup fast, thats why is Faster good for me :)
And i also work from home and have clients, and i just start to make some script for newsletter sending(you wrote about that problem on your blog few weeks ago), and i say "lets try faster", so its my first time with this framework, and i have future plans with him, so i will get some more ideas probably (i get one new but, i will first think about it)

[volomike]

Consider the error_log() function instead of file write APIs. Saves you a few lines of code in your logger() class method.

[squirll]

error_log() function request some system changes and have some restrictions.
Multiple sharing same file, size limit, on some server by default is not set error_log in php.ini ..etc..
Not good to client to hire System Administrator just to make log file work.
Thats my opinion

P.s i close by mistake, sorry

[volomike]

Ah, but you can use error_log() and direct it to a custom log file, and that, for me at least in testing with various hosts, seems to be enabled. I would think file write APIs would be disabled by a harsh web host before error_log() would be.

And there's a size limit? And may have collisions when attempting the file writes from more than one session? I guess I need to study error_log() more to see the issues with using it.

[squirll]

If i saw good, 2GB limit(by default) and some user have problem when few scripts use same file..

if error_log() and and my function do same thing (writing one txt file) i don't see reason why will this disable and error_log not...
Don't know why will someone disable that kind of function, it not sending emails so it can be mark like spam script.

[volomike]

Okay, we'll go with fwrite API instead of error_log.

I am inclined now to agree to a logger() API in the core. I think $this->core->logger() is good, but makes some assumptions. You might want to use parameters (with defaults) to get around that. And I think it may need us to add a default config.php entry for the log file path.

For instance -- I may prefer gmtdate() on some servers, and date() on others. And we've already mentioned script name, and session ID. Perhaps we should add call stack into the mix too for those who want to go all out. And then there are people who may simply want the errors, or simply want the dates + errors, and so we'll want to let them turn these on and off but have some assumed defaults.

My preference on defaults would be:

(all on one line for one error)

• Session ID - on by default
• Script Name - off by default
• Date/Timestamp - use date('Y-m-d H:i:s') instead of gmdate('Y-m-d H:i:s')
• Error

(on lines following the error, separated by a single line with '---')

• Call Stack -- of by default

As for the file path, we can add a new default config.php option 'ERROR_LOG' which defaults to app/logs/log.php. And I only say log.php because otherwise it makes many of this framework's followers nervous about it being opened if the .htaccess file is askew by someone who doesn't know their way around .htaccess. (This is the same reason why they asked me to change site.conf to config.php, which I did. It is also the reason why Kohana's error log is a PHP file.)

What is your opinion?

TO ALL READERS OF THIS COMMENT - please provide your opinion about the logger() API. Should we use it even though we can use error_log, ini_set('error_log',$sLogPath), and user_error() in standard PHP? Does it add significant value and save enough time to make it worth it to add to the framework?