TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692017-09-14T11:02:31ZTYPO3 Forge
Redmine TYPO3 Core - Feature #82483 (Closed): Introduce FingersCrossed LogWriterhttp://forge.typo3.org/issues/824832017-09-14T11:02:31ZArtur Cichoszartur2000@gmx.de
<p>I am just confused about this statement from the official logger documentation:</p>
<p>"An early return in the log() method prevents unneeded computation work to be done. So you are safe to call $logger->debug() frequently without slowing down your code too much. The Logger will know by its configuration, what the most explicit severity level is." <a class="external" href="https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Logging/Logger/Index.html">https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Logging/Logger/Index.html</a></p>
<p>Reading this I assumed, that the logger can get configured for a "log verbosity level", e.g. by means of $GLOBALS["TYPO3_CONF_VARS"]['SYS']['systemLogLevel']. <br />This way I would be able to put 1000 ->debug() calls in my code "without slowing down my code too much", because all records for records above this setting would get skipped. But this is clearly not the case. The default log writer (typo3temp/logs/typo3.log) which logs all the log entries no matter what log level they are.</p>
<p>But e.g. on production it clearly isn't necessary, so how should we understand the cited statement from documentation above?<br />I know I can explicitely disable the default logger probably by means of TYPO3 environment/context etc. but stil, it is confusing and not documented.</p>
<p>I work on a project using TYPO3 6.2 LTS now, so maybe there is some undocumented imporvements in later versions, I do not know.</p>
<p>So I got inspired by symfonys/monologs "fingers_crossed" handler/writer and added this (class file attached to this issue) alternative for the default FileWriter to a project, which stores all records in memory first and writes them to the file only then, when at least some verbosity threshold (e.g. ERROR) has been hit during the entire request. This threshold could be set explicitely to a higher level by means of e.g. $GLOBALS["TYPO3_CONF_VARS"]['SYS']['systemLogLevel'].</p>
<p>May be somethig like this may be worth putting it into core?</p>
<p>To overwrite the default handler config I used this then:</p>
<pre>
/**
* Reconfigure the default log writer to use our own log file writer which stores all recieved log records
* and writes them to a file only if a certain severity level record has been hit during this request.
* The maximum severity log level can be set using $GLOBALS["TYPO3_CONF_VARS"]['SYS']['systemLogLevel']
*/
$GLOBALS['TYPO3_CONF_VARS']['LOG']['writerConfiguration'] = array(
\TYPO3\CMS\Core\Log\LogLevel::DEBUG => array(
// add a FileWriter
'Q3i\\T3Local\\Core\\Log\\Writer\\FingersCrossedFileWriter' => array(
// configuration for the writer
'logFile' => 'typo3temp/logs/typo3.log'
)
)
);
</pre> TYPO3 Core - Feature #80289 (Closed): Alow to globally disable devLog http://forge.typo3.org/issues/802892017-03-15T15:13:31ZArtur Cichoszartur2000@gmx.de
<p>Somehow I always assumed that <code>$GLOBALS["TYPO3_CONF_VARS"]['SYS']['enable_DLOG'] = 0</code> globally disables devLog.<br />Since today I know I was wrong after we discovered, that the database of one project grew up to 25GB in just few weeks.<br />So I tried to investigate why devLog is stil writing data even though I have seen 'enable_DLOG' = 0.<br />I see now that the API method GeneralUtility::devLog() dos not care about that setting at all. It is up to the devLog extension developer to check if he actually can call this method.</p>
<p>This is not very fortunate in my opinion. A developer can forget to check for <code>TYPO3_DLOG==1</code> and the user of such extension is fully unaware of the implications.</p>
<p>I find it much more consistent and clear, if the setting ['enable_DLOG'] = 0 globaly disables any devLog possibilities.</p> TYPO3 Core - Bug #68494 (Closed): Workspaces, move-placeholder for table "pages_language_overlay"...http://forge.typo3.org/issues/684942015-07-23T20:00:38ZArtur Cichoszartur2000@gmx.de
<p>Debugging SQL errors in frontend (Unknown column 't3ver_move_id' in 'where clause') I discovered that the reason is inside the class TYPO3\CMS\Extbase\Persistence\Generic\Storage\Typo3DbBackend.</p>
<p>In line 782++, there is the following consition</p>
<pre>
if (!empty($pageRepository->versioningWorkspaceId)
&& !empty($GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'])
&& $GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'] >= 2
&& count($rows) === 1
) {
[...]
}
</pre>
<p>The problem is, that this condition is TRUE for the table "pages_language_overlay" while it probably shouldn't (there is no field t3ver_move_id in TCA).<br />This condition is TRUE because of the test <code>$GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'] >= 2</code>.</p>
<p>For table "pages_language_overlay" the value $GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'] is a boolean and TRUE, so the check is <code>TRUE >= 2</code> which is TRUE.</p>
<p>I suppose the code should get corrected to the following version:</p>
<pre>
if (!empty($pageRepository->versioningWorkspaceId)
&& !empty($GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'])
&& (is_int($GLOBALS['TCA'][$tableName]['ctrl']['versioningWS']) && $GLOBALS['TCA'][$tableName]['ctrl']['versioningWS'] >= 2)
&& count($rows) === 1
) {
[...]
}
</pre> TYPO3 Core - Bug #58528 (Rejected): config.prefixLocalAnchors causes GET parameters to be prepend...http://forge.typo3.org/issues/585282014-05-05T17:24:26ZArtur Cichoszartur2000@gmx.de
<p>Hi,</p>
<p>I understand why the TS option config.prefixLocalAnchors is useful to prefix all local anchors with the relative path, but all GET parameters are prepended as well.</p>
<p>I do not think this is desired so it might be a bug.</p>
<p>Example:</p>
<p>Calling e.g. <a class="external" href="http://somehost.org/?test=abc">http://somehost.org/?test=abc</a> results in local anchors like <a href="?test=abc#some_anchor">...</a></p> TYPO3 Core - Bug #53123 (Closed): Is compressing external JS and CSS files necessary by default? http://forge.typo3.org/issues/531232013-10-25T12:14:11ZArtur Cichoszartur2000@gmx.de
<p>I didn't make use of JS / CSS compressor to much, so I didn't notice the problem until now, where I have some external CSS/JS files included and compressor activated at the same time.</p>
<p>The compressor tries to compress the external file and store it locally but fails to do so properly.<br />I get the following Error in the frontend:</p>
<pre>
Warning: filemtime(): stat failed for /srv/.../trunk/typo3/http://netdna.bootstrapcdn.com/font-awesome/3.2.1/css/font-awesome.min.css in /srv/www/htdocs/typo3_src/6.0.10/typo3/sysext/core/Classes/Resource/ResourceCompressor.php on line 367
</pre>
<p>Anyway I do not think it's necessary to compress external files at all, since it is against the general idea of using CDN networks.</p>
<p>Of course there is the possibility to switch off compression for a file explicitly using includeJS.[key].disableCompression. <br />But I think it would be better to make "not compressing" external files the default behavior and to give the posibility to enable it explicitly if desired.</p>
<p>In my case I extended the class \TYPO3\CMS\Frontend\Page\PageGenerator and made some changes, where includeJS, includeCSS, includeJSFooter, includeJSLibs and includeJSLibsFooter are processed, making each time a change similar to the following:</p>
<pre>
/**
* Modified by Quintinity - Start
* prevent from compressing external files
*/
$pageRenderer->addCssFile($ss, $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['alternate'] ? 'alternate stylesheet' : 'stylesheet', $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['media'] ? $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['media'] : 'all', $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['title'] ? $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['title'] : '', empty($GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['disableCompression']) && empty($GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['external']), $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['forceOnTop'] ? TRUE : FALSE, $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['allWrap'], $GLOBALS['TSFE']->pSetup['includeCSS.'][$key . '.']['excludeFromConcatenation'] ? TRUE : FALSE);
// Modified By Quintinity - Stop
</pre> TYPO3 Core - Bug #23285 (Closed): PATH_site not defined in typo3/thumbs.phphttp://forge.typo3.org/issues/232852010-07-28T11:40:15ZArtur Cichoszartur2000@gmx.de
<p>We have used an include like this in one of the classes of an extension</p>
<p>require_once(PATH_tslib.'class.tslib_pibase.php');</p>
<p>This class was included inside the temporary config-cache files too. In general it worked fine but for the thumbs.php. During thumbnail generation the config-cache is loaded to. It failed because of the missng PATH_tslib constant.</p>
<p>I think it does no harm to define this constant inside thumbs.php even if it isn't needed there. It avoids such problems like ours.</p>
<p>(issue imported from #M15259)</p> TYPO3 Core - Bug #22792 (Closed): Install Tool seems to rely on the "autostart session" option fr...http://forge.typo3.org/issues/227922010-06-02T22:20:07ZArtur Cichoszartur2000@gmx.de
<p>Although cookies were activated, I tried to login into the install tool without success. The javascript popup message has been coming up over and over again.</p>
<p>simple "session_register();" at the begining of the following file fixed the issue</p>
<p>typo3/install/index.php</p>
<p>(issue imported from #M14596)</p>