1.6 Log format: useful or not?

[svasti]

Hi developers:

Log format used to be:

Code: Select all

2010-08-31 11:27:31 from 127.0.0.1 logged_in
2010-09-16 09:36:58 from 127.0.0.1 logged_in
2012-02-03 18:43:38 from 127.0.0.1 logged_in
2014-01-11 18:13:10 from 127.0.0.1 logged_in

Now it has become (taken from our Demo):

Code: Select all

2014-01-10 19:35:43	info	XH	login	login from 92.201.65.143
2014-01-10 20:11:41	info	XH	login	login from 188.181.57.126
2014-01-11 02:55:44	warning	XH	login	login failed from 88.100.41.248
2014-01-11 02:56:11	info	XH	login	login from 88.100.41.248
2014-01-11 17:10:05	info	XH	login	login from 92.201.65.143

For instance in the demo's main template, the login is too wide for the editing area. The login got tabs as dividers, and tabs are converted to 8 spaces in the online view.

What about a slight change for 1.6.1, a new divider.
Instead of tabs ("/t") which use lots of space, we could have middots (·)? or elisions(…)? or underlines(_)? or pipes(|)?
It should be readable.

Code: Select all

2014-01-10 19:35:43…info…XH…login…login from 92.201.65.143
2014-01-10 20:11:41·info·XH·login·login from 188.181.57.126
2014-01-11 02:55:44·warning·XH·login·login failed from 88.100.41.248
2014-01-11 02:56:11|info|XH|login|login from 88.100.41.248
2014-01-11 17:10:05_info_XH_login_login from 92.201.65.143

There are 5 entries in every line.

CSV with the columns "type" (info, warning, error), "timestamp", "module" ("core" resp. the name of the plugin), "category"/"event name" and "description".

Really interesting are only timestamp and description. What about re-ordering:
timestamp…description…type…module…category?

[svasti]

P.S. I just added some definitions to the core.css

Code: Select all

#xh_logfile {
    height: 40em;
    overflow: auto;
    border: 1px solid #888;
    background: white;
    color: black;
    font: 12px/1.6 "Lucida Sans Unicode", "Lucida Grande", monospace;
}

Now it looks much better. Lucida is a little thicker than Courier, so it is readable in small sizes also. I think with this addition, no change in the logfile is necessary.

[cmb]

Related thread: http://cmsimpleforum.com/viewtopic.php?f=29&t=6648.

What about a slight change for 1.6.1, a new divider.
Instead of tabs ("/t") which use lots of space, we could have middots (·)? or elisions(…)? or underlines(_)? or pipes(|)?

Basically, I'm not against changing the separator. We should, however, take care that the separator is not used inside any field value (especially the description might contain almost any character); A tab won't almost certainly not be used, as well as a middle dot. I'm not sure about pipes; broken bars (¦) might be a better alternative. Anyway, using the tab character as field delimiter will result in CSV files which could be imported nearly "everywhere" (though other characters shouldn't be a problem in practice).

Really interesting are only timestamp and description. What about re-ordering:
timestamp…description…type…module…category?

While I do think that other fields may be insteresting, too, I'm not against re-ordering (after all, the order of the columns in a relation shouldn't matter).

Anyway, I think it's important to determine the exact format of the file ASAP, to avoid later incompatibilities. Sticking with the current solution might be best, as it's already in use.

Now it looks much better. Lucida is a little thicker than Courier, so it is readable in small sizes also. I think with this addition, no change in the logfile is necessary.

That's fine by me. However, I believe "Lucida Sans Unicode" and "Lucida Grande" are proportional fonts (with monospaced digits, though), so we may consider to fall back to "sans serif" instead of "monospace".

Another alternative would be to use a TABLE to display the log file, i.e. something like the following (replacement for XH_logFileView() in cmsimple/adminfuncs.php):

Code: Select all

function XH_logFileView()
{
    global $pth, $tx;

    $o = '<h1>' . $tx['title']['log'] . '</h1>'
        // TODO: remove inline styling
        . '<table style="width: 100%"><tbody>';
    $lines = file($pth['file']['log']);
    foreach ($lines as $line) {
        $fields = explode("\t", rtrim($line));
        $o .= '<tr>';
        foreach ($fields as $field) {
            $o .= '<td>' . XH_hsc($field) . '</td>';
        }
        $o .= '</tr>';
    }
    $o .= '</tbody></table>';
    return $o;
}

[svasti]

Something strange:
Go to our demo. login and go to Log file. Takes a loooong time to open, doesn't it? But opening it a second time goes fast. Wonder why that is so.

[cmb]

Go to our demo. login and go to Log file. Takes a loooong time to open, doesn't it? But opening it a second time goes fast. Wonder why that is so.

Me too. Indeed on my first request to view the log file it took several seconds; afterwards it was pretty fast, even after logging out and in again, and logging in on another browser. It may be reasonable to compare the performance with other CMSimple_XH installations.

BTW: while having a look at the code for writing to the log file (XH_logMessage()), I noticed that it is locked during the operation, but the code that reads the file (XH_logFileView()) doesn't take that into account. We should replace file_get_contents() with XH_readFile() there (resp. if we're going to use the code I've posted above, we would have to replace file() with something that puts a shared lock on the file).

[cmb]

Go to our demo. login and go to Log file. Takes a loooong time to open, doesn't it? But opening it a second time goes fast. Wonder why that is so.

Me too. Indeed on my first request to view the log file it took several seconds; afterwards it was pretty fast, even after logging out and in again, and logging in on another browser. It may be reasonable to compare the performance with other CMSimple_XH installations.

I've just tested again, and the log file was displayed very fast -- I suppose it was just a temporary hiccup of the server.