Feature #15040
closed
Logging with class.tslib_fe.php + awstats + realurl
Added by Thomas Janke about 19 years ago.
Updated over 14 years ago.
Description
is it possible to write the realurl-paths in the typo3 logfile?
with config.stats.xyz i can configure different layouts of log-file entries, but it is not possible to log the paths generated by realurl.
it seems that the file /tslib/class.tslib_fe.php on lines 1427 and prior is responsible for logging. perhaps there is a simple solution to log realurl-path at this line if realurl is installed.
there are several patches to solve problems with e.g. german special chars but the smartest solution would be to integrate realurl.
class.tslib_fe.php line 1427 an prior on typo3.7.0
realurl 0.2.0
awstats 0.10.0
(issue imported from #M1585)
Files
The easiest and best solution is to simply use the logging provided by your webserver. :)
// gk@plan2.net - modification for RealUrl compatible logs - using REQUEST_URI instead of $this->config['stat_vars']['pageName']
// this should better be configuratable via TCA.
// $LogLine = ((t3lib_div::getIndpEnv('REMOTE_HOST') && !$this->config['config']['stat_apache_noHost']) ? t3lib_div::getIndpEnv('REMOTE_HOST') : t3lib_div::getIndpEnv('REMOTE_ADDR')).' - - '.Date('[d/M/Y:H:i:s +0000]',$GLOBALS['EXEC_TIME']).' "GET '.$this->config['stat_vars']['pageName'].' HTTP/1.1" 200 '.strlen($this->content);
$LogLine = ((t3lib_div::getIndpEnv('REMOTE_HOST') && !$this->config['config']['stat_apache_noHost']) ? t3lib_div::getIndpEnv('REMOTE_HOST') : t3lib_div::getIndpEnv('REMOTE_ADDR')).' - - '.Date('[d/M/Y:H:i:s +0000]',$GLOBALS['EXEC_TIME']).' "GET '.t3lib_div::getIndpEnv('REQUEST_URI').' HTTP/1.1" 200 '.strlen($this->content);
What is the point of using REQUEST_URI? As Karsten noted this is the same as using the webserver log.
Karsten is more than right, in case access to the real apache logs is provided;
In case not, you might wanna use REQUEST_URI
Is it a bug at all? I'd rather say a missing feaure of RealUrl.
Why is it missing in RealURL? RealURL would have to provide it's own logging.
I see two solutions:
- add the config option to use REQUEST_URI
- add a hook to allow setting of the path for logging
Hm... seems that this has been forgotten somehow.
I attached a patch against TYPO3 4.1.1 that adds the config option to use REQUEST_URI, similar to the solution which has been proposed at http://www.typo3.net/forum/list/list_post//21411/
Logging of REQUEST_URI is configured by
config.stat_apache_pagenames = [realurl]
Maybe an option for the next release.
I'm sorry for hijacking this report, but the topic is so very similar to the following feature request that it seems plausible to leave it here:
I would suggest to have a configuration option for enabling TYPO3 to log requests with an empty referer as if they were direct address hits (that is '-'). Until now, those requests are simply logged as blank and awstats (probably other tools as well) will therefore count them as unknown origin. I don't see a simple way to differentiate those requests by environment vars and subsequently allow TYPO3 to log as exact as Apache would.
From my experience and comparing logs based on the original webserver's log files, there are generally by far more hits that are considered to be direct address hits than unknown origin, so having the option to assume empty referers to be direct address hits seems reasonable.
The patch 1585_hijacked.diff allows TYPO3 to log '-' for empty referers by setting TS property
config.stat_apache_assumeDirectAddressOnEmptyReferer = 1
Afterwards, TYPO3 and awstats will count those as direct address hits.
Could someone please commit patch 1585.diff to core?
It simply adds a config option to use REQUEST_URI as Martin proposed.
In addition to this it would make sense to me to add a hook for generating the whole LogLine, added patch logline_hook.diff, created against T3 4.1.1 core.
I would think it is long enough since this was a patch, too ;)
I filed a RFC at the core list, bundling 1585.diff, 1585_hijacked.diff and logline_hook.diff (see 1585_trunk.patch)
Fixed in RC1. Thanks to Steffen Kamper for taking care of this fix.
Also available in: Atom
PDF