TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692015-09-02T15:33:27ZTYPO3 Forge
Redmine TYPO3 Core - Bug #69476 (Closed): Declaration of TYPO3\CMS\Core\Package\PackageManager::injectCla...http://forge.typo3.org/issues/694762015-09-02T15:33:27ZMartin Helmichm.helmich@mittwald.de
<p>The class <code>TYPO3\CMS\Core\Package\PackageManager</code> overwrites the method <code>injectClassLoader</code> from it's parent class with a different signature (the type hint is <code>TYPO3\CMS\Core\Core\ClassLoader</code> instead of <code>TYPO3\Flow\Core\ClassLoader</code>). This violates the <a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle" class="external">Liskov Substitution Principle</a> and triggers warnings when PHP's error level includes the <code>E_STRICT</code> bit (this single issue fills our error logs with ~140 million lines per day).</p>
<p>Proposed fix on Gerrit will follow shortly.</p> TYPO3 Core - Bug #64508 (Closed): Class cache corruption in chroot environmenthttp://forge.typo3.org/issues/645082015-01-26T14:57:43ZMartin Helmichm.helmich@mittwald.de
<a name="Summary"></a>
<h4 >Summary<a href="#Summary" class="wiki-anchor">¶</a></h4>
<p>This issue occurs in the rare edge case when the TYPO3 cli dispatcher is called in a chroot environment and the site is delivered via a non-chrooted web server.</p>
<p>In this case, all classes in the class cache will be stored with <code>PATH_typo3</code> as base path, except the <code>TYPO3\Flow</code> classes in the <em>core</em> extension. These are based on the <code>__DIR__</code> constant, which according to [1] resolves symlinks that generates directory paths that are invalid outside of the chroot environment.</p>
<a name="Example"></a>
<h4 >Example<a href="#Example" class="wiki-anchor">¶</a></h4>
<p>Consider the following chroot environment directory layout:</p>
<pre>
<root>
\_ html
| \_ typo3
| \_ index.php
| \_ ...
\_ home
\_ www
\_ /p123456 -> ../../
</pre>
<p>Note the backwards-recursive symlink that is required for processes inside the chroot (like a PHP process called from the CLI) to be able to resolve non-chrooted paths.</p>
<p>Now consider that the CLI dispatcher is called with the absolute path:</p>
<pre>
$ php /home/www/p123456/html/typo3/typo3/cli_dispatch.phpsh ...
</pre>
<p>TYPO3 will now build the <code>PATH_site</code> constant from the path of the called file, i.e. <code>/home/www/p123456/html/typo3</code>. This is a valid path both within the chroot environment (thanks to the backward symlink) and system-wide. This path is also used in the <code>cache_classes</code> cache that might be built during the CLI call.</p>
<p>This, however, is not the case for the TYPO3 Flow classes that are included in the <em>core</em> extension. In the <em>core</em> extension's <em>ext_autoload.php</em>, the magic <code>__DIR__</code> constant is used as base path for all TYPO3 Flow class files. Since these paths are absolute, they are used in the <code>cache_classes</code> cache.</p>
<p>However, the <code>__DIR__</code> constant resolves symlinks, and in the chroot environment will resolve to <code>/html/typo3/...</code> instead of <code>/home/www/p123456/html/typo3/...</code>. This results in invalid cache entries when the <code>cache_classes</code> cache is accessed in a non-chrooted context.</p>
<a name="Suggested-solution"></a>
<h4 >Suggested solution<a href="#Suggested-solution" class="wiki-anchor">¶</a></h4>
<p>Use <code>PATH_typo3</code> as base path for the TYPO3 Flow classes. Change request in Gerrit will follow shortly.</p>
<p>[1] <a class="external" href="http://php.net/manual/en/language.constants.predefined.php">http://php.net/manual/en/language.constants.predefined.php</a></p> TYPO3 Core - Bug #63550 (Closed): Menu configuration caching disabled by ineffective type checkshttp://forge.typo3.org/issues/635502014-12-03T18:00:40ZMartin Helmichm.helmich@mittwald.de
<p>We just encountered a bug that under certain circumstances prevented the caching of multi-level menu configurations.</p>
<p>We encountered this issue due to massive performance problems after a TYPO3 6.2 migration. In our case, we have a nested menu with 3 levels; however, only a small subset of menu items actually has a 3rd menu level. For every other 2nd level menu item without sub menu items, the entire menu configuration was completely rebuilt from scratch, because the (empty) menu configuration was not cached by the caching framework.</p>
<p>This is actually due to two issues in the <code>TYPO3\Core\Frontend\ContentObject\Menu\TextMenuContentObject</code> and <code>TYPO3\Core\Frontend\Page\PageRepository</code> class.</p>
<p>First of all, the <code>TextMenuContentObject</code> class generates a <code>NULL</code> menu configuration when no pages are rendered with in the menu. The <code>AbstractMenuContentObject</code> class then tries to cache this <code>NULL</code> value. However, when rendering the NEXT menu item, the menu configuration will be re-built when the cached value is <code>!is_array(...)</code> (i.e. always, when the cached value is <code>NULL</code>).</p>
<p>Secondly, the <code>TYPO3\Core\Frontend\Page\PageRepository</code> class contains a typing error that effectively prevents empty arrays from being cached by the caching framework.</p>
<p>Both of these bugs in conjunction not only effectively disable the caching of the menu configuration, but also put a lot of load on the database, because the <code>AbstractMenuContentObject</code> actually tries to read the cache AND rebuild it for each single menu item.</p>
<p>Proposed solution:</p>
<p>- Store an (empty) array in cache for empty menus instead of <code>NULL</code>.<br />- Allow the <code>TYPO3\Core\Frontend\Page\PageRepository</code> class to cache empty arrays (this class actually wraps TYPO3's caching framework, which in itself handles those values correctly).</p>
<p>Caveats:</p>
<p>- Not sure if the proposed change is backwards-compatible. Comments are welcome.</p>
<p>We propose the following patch as a solution (change request on Gerrit will follow shortly):</p>
<pre>
diff --git a/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php b/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php
index 44098de..779e5ad 100644
--- a/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php
+++ b/typo3/sysext/frontend/Classes/ContentObject/Menu/TextMenuContentObject.php
@@ -33,7 +33,10 @@ class TextMenuContentObject extends \TYPO3\CMS\Frontend\ContentObject\Menu\Abstr
$splitCount = count($this->menuArr);
if ($splitCount) {
list($NOconf) = $this->procesItemStates($splitCount);
+ } else {
+ $NOconf = array();
}
+
if ($this->mconf['debugItemConf']) {
echo '<h3>$NOconf:</h3>';
debug($NOconf);
diff --git a/typo3/sysext/frontend/Classes/Page/PageRepository.php b/typo3/sysext/frontend/Classes/Page/PageRepository.php
index c876d34..beb3f39 100644
--- a/typo3/sysext/frontend/Classes/Page/PageRepository.php
+++ b/typo3/sysext/frontend/Classes/Page/PageRepository.php
@@ -879,7 +879,7 @@ class PageRepository {
$hashContent = NULL;
$contentHashCache = GeneralUtility::makeInstance('TYPO3\\CMS\\Core\\Cache\\CacheManager')->getCache('cache_hash');
$cacheEntry = $contentHashCache->get($hash);
- if ($cacheEntry) {
+ if ($cacheEntry !== FALSE) {
$hashContent = $cacheEntry;
}
return $hashContent;
</pre> TYPO3 Core - Bug #40356 (Closed): Class autoloader fails for non-core extbase extensionshttp://forge.typo3.org/issues/403562012-08-28T21:06:25ZMartin Helmichm.helmich@mittwald.de
<p>When trying to autoload a class named <code>Tx_Foo_Controller_BazController</code>, the TYPO3 class autoloader tries to include the file:</p>
<p><code>typo3conf/ext/foo/Classes/Controller.php</code> instead of<br /><code>typo3conf/ext/foo/Classes/Controller/BazController.php</code></p> TYPO3 Core - Bug #40182 (Closed): Wrong file and class name in index_searchhttp://forge.typo3.org/issues/401822012-08-25T14:43:32ZMartin Helmichm.helmich@mittwald.de
<p>After introducing namespace support, the indexed search fails with an PHP Fatal error:</p>
<blockquote>
<p>Call to a member function split2Words() on a non-object in [...]/typo3_src/typo3/sysext/indexed_search/Classes/Controller/SearchFormController.php on line 440</p>
</blockquote> TYPO3 Core - Bug #40168 (Closed): Uncaught Exception on multi-language sitehttp://forge.typo3.org/issues/401682012-08-25T12:23:47ZMartin Helmichm.helmich@mittwald.de
<p>When using multiple languages, the TYPO3 Frontend crashes with an uncaught Exception (on current master):</p>
<blockquote>
<p>#1283790586: There is no entry in the $TCA array for the table "sys_language_overlay". This means that the function enableFields() is called with an invalid table name as argument.</p>
<p>InvalidArgumentException thrown in file<br />[...]/typo3_src/typo3/sysext/frontend/Classes/Page/PageRepository.php in line 910.</p>
</blockquote> TYPO3 Core - Bug #24279 (Closed): ContentObject is not passed to View in FLUIDTEMPLATEhttp://forge.typo3.org/issues/242792010-12-02T21:02:31ZMartin Helmichm.helmich@mittwald.de
<p>In the FLUIDTEMPLATE cObject, no instance of the tslib_cObj class is passed to the created view. This renders most of the Fluid ViewHelpers that you might want to use (e.g. the ImageViewHelper, or maybe some of the *LinkViewHelpers) useless, causing them to abort with fatal errors:</p>
<p>"Fatal error: Call to a member function getImgResource() on a non-object in /path/to/typo3/sysext/fluid/Classes/ViewHelpers/ImageViewHelper.php on line 107"</p>
<p>The attached patch fixes the problem. However, I am not sure whether my solution is good style. This issue affects both the "cms" and "fluid" system extensions; I hope this is the right place for it.</p>
<p>(issue imported from #M16654)</p>