TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692019-06-14T09:54:52ZTYPO3 Forge
Redmine TYPO3 Core - Bug #88562 (Rejected): Calling setEnableFieldsToBeIgnored is ignored, when called in...http://forge.typo3.org/issues/885622019-06-14T09:54:52ZTimo Hund
<p>The QuerySettingsInterface provides a method "setEnableFieldsToBeIgnored". This provides the functionality to explicitly ignore a list of enabled fields and requires to can setIgnoreEnableFields(TRUE) before.</p>
<p>The logic is evaluated in the frontend context (see. Typo3DbQueryParser::getVisibilityConstraintStatement) but it is not evaluated for the backend. The variable $enableFieldsToBeIgnored is even not passed to the method getBackendConstraintStatement.</p> TYPO3 Core - Bug #87753 (Closed): BackendUtility::firstDomainRecord returns hidden domainshttp://forge.typo3.org/issues/877532019-02-20T18:00:26ZTimo Hund
<p>The function BackendUtitlity::firstDomainRecord returns domains even when they are hidden. Looks to me that the LegacyDomainResolver retrieves them. Previously the function excluded hidden records.</p> TYPO3 Core - Bug #86150 (Closed): Problem when page tree for site is deleted and site configurati...http://forge.typo3.org/issues/861502018-09-05T10:52:03ZTimo Hund
<p>I think that there is a problem when the site configuration remains in /config/sitename, but the site in the page tree is deleted.</p>
<p>I did the following steps:</p>
<ul>
<li>Created page structure for site A (site with site root)</li>
<li>Created site configuration for that site in sites module</li>
</ul>
<p>After that i wanted to recreate the page structure in a second tree (but with the goal to use the same domain as for site A because i want to replace that later).</p>
<ul>
<li>Created page structure for site B</li>
<li>Deleted page structure for site A (because i did't not need it anymore)</li>
<li>Created site configuration for site B</li>
</ul>
<p>In the end i got a page not found error in the frontend, but the configuration in the backend looked correct (page structure for page B and site configuration for siteB). In the end i recognized, that the pagetree for page A was deleted, but the site configuration in the config folder still exists. But the site configuration for siteA was not visible anymore in the backend.</p>
<p>I think it would be good if the unused site configurations are somehow visible in the backend, or the site configuration is deleted when the tree for that site get's deleted.</p> TYPO3 Core - Bug #84785 (Closed): Execution order of hooks ['tslib/index_ts.php']['preprocessRequ...http://forge.typo3.org/issues/847852018-04-18T16:53:01ZTimo Hund
<p>Between 8 LTS and 9.2 the order of the execution of the following hooks was changed:</p>
<p>8.7</p>
<p>- First: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/index_ts.php']['preprocessRequest']<br />- Second: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']</p>
<p>9.2</p>
<p>- First: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_fe.php']['pageIndexing']<br />- Second: $GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/index_ts.php']['preprocessRequest']</p>
<p>I could fix that by changing the order of the RequestMiddlewares in (sysext/frontend/Configuration/RequestMiddlewares.php)</p>
<p>from </p>
<pre>
'typo3/cms-frontend/tsfe' => [
'target' => \TYPO3\CMS\Frontend\Middleware\TypoScriptFrontendInitialization::class,
'after' => [
'typo3/cms-core/normalized-params-attribute',
]
],
</pre><br />to
<pre>
'typo3/cms-frontend/tsfe' => [
'target' => \TYPO3\CMS\Frontend\Middleware\TypoScriptFrontendInitialization::class,
'after' => [
'typo3/cms-frontend/eid',
]
],
</pre>
<p>but since i do not know if this is intended or if this break the order for other hooks it would be nice when somebody with a deeper knowledge of TypoScriptFontendController can have a look on it</p> TYPO3 Core - Bug #79692 (Closed): Error when "Edit the whole template record"http://forge.typo3.org/issues/796922017-02-08T16:52:19ZTimo Hund
<p>When i click on "Edit the whole Template Record" in the backend, i currently get the following error:</p>
<p>Core: Exception handler (WEB): Uncaught TYPO3 Exception: strtoupper() expects parameter 1 to be string, integer given | TypeError thrown in file /app/htdocs/typo3_src/typo3/sysext/backend/Classes/Form/FormDataProvider/EvaluateDisplayConditions.php in line 205. Requested URL</p>
<p>I guess that this happens because of the strict type check:</p>
<p>declare(strict_types=1);</p>
<p>...</p>
<pre><code>$logicalOperator = strtoupper($logicalOperator);<br /> if (($logicalOperator !== 'AND' && $logicalOperator !== 'OR') || !is_array($groupedDisplayConditions)) {<br /> throw new \RuntimeException(<br /> 'Multiple conditions must have boolean operator "OR" or "AND", "' . $logicalOperator . '" given.',<br /> 1481380393<br /> );<br /> }<br />...</code></pre>
<p>I think the value should be casted to string before passing it to strtoupper.</p> TYPO3 Core - Bug #79354 (Rejected): PageRepository::getPage fails in Backend contexthttp://forge.typo3.org/issues/793542017-01-17T14:49:42ZTimo Hund
<p>The call of PageRepository::getPage currently fails in the backend context with the following error:</p>
<p>Uncaught TYPO3 Exception<br />explode() expects parameter 2 to be string, null given</p>
<p>TypeError thrown in file<br />/var/www/dev-master.local.typo3.org/typo3_src/typo3/sysext/core/Classes/Database/Query/Restriction/FrontendGroupRestriction.php in line 36.</p>
<p>This happens because FrontendGroupRestriction tries to read TSFE->gr_list. In TYPO3 7.6. is worked to call PageRepository::getPage in the backend context.<br />Is this a bug, or should a page be fetched in a different way?</p> TYPO3 Core - Bug #79052 (Closed): Error with PHP 7.1 when calling TypoScriptFrontendController->g...http://forge.typo3.org/issues/790522016-12-20T16:40:54ZTimo Hund
<p>When i run some test from EXT:solr with PHP 7.1 i get the following error:</p>
<p>TypeError: Argument 2 passed to <code>TYPO3\CMS\Core\Utility\ArrayUtility::mergeRecursiveWithOverrule()</code> must be of the type array, string given</p>
<p>I think the reason is, that <code>TypoScriptFrontendController->config</code> is still an empty string, when the part i the code is called, and the second argument was expected to be an array.</p>
<pre>
if (is_array($this->tmpl->setup['config.'])) {
ArrayUtility::mergeRecursiveWithOverrule($this->tmpl->setup['config.'], $this->config['config']);
$this->config['config'] = $this->tmpl->setup['config.'];
}
</pre> TYPO3 Core - Bug #78266 (Closed): Installing 8.0.1 - 8.3.1 with composer end-up with error http://forge.typo3.org/issues/782662016-10-12T15:07:55ZTimo Hund
<p>In my ci system i have the following problem.</p>
<p>When i install TYPO3 with composer:</p>
<p>e.g.:</p>
<p>composer require --dev --prefer-source typo3/cms="8.0.1"</p>
<p>since yesterday i have the following problem:</p>
<p>PHP Fatal error: Class TYPO3\CMS\Fluid\Core\Cache\FluidTemplateCache contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (TYPO3Fluid\Fluid\Core\Cache\FluidCacheInterface::getCacheWarmer) in /home/travis/build/ext-solr/.Build/vendor/typo3/cms/typo3/sysext/fluid/Classes/Core/Cache/FluidTemplateCache.php on line 27</p>
<p>For me it looks like, that the composer dependency e.g. in 8.0.1 or 8.3.1 allows also the install of fluid 1.1.0 (which afaik should only be used since 8.4):</p>
<p>"typo3fluid/fluid": "^1.0.7", which is ">=1.0.7 <2.0.0"</p> TYPO3 Core - Bug #77256 (Closed): Missing test fixtures when installing 7.6.10 as require dev dep...http://forge.typo3.org/issues/772562016-07-26T11:37:39ZTimo Hund
<p>Since commit:</p>
<p><a class="external" href="https://github.com/TYPO3/TYPO3.CMS/commit/4c46b1b7cecb82d092ad99cbcac1eee2bc47951a">https://github.com/TYPO3/TYPO3.CMS/commit/4c46b1b7cecb82d092ad99cbcac1eee2bc47951a</a></p>
<p>You can not use e.g. FunctionalTestCase::setUpBackendUserFromFixture because the needed fixture file is missing.</p>
<p>I think at least the fixture files should not be excluded.</p> TYPO3 Core - Bug #75299 (Closed): Behaviour of escapeChildren for self closing ViewHelpershttp://forge.typo3.org/issues/752992016-03-29T17:13:21ZTimo Hund
<p>Hi,</p>
<p>in an Extension i have the problem that the whole content is escaped. As mentioned in the release notes of 8.0 the property escapeChildren could be changed if needed. But for me when is change this in the first view helper in the template that is self closing it effects als nodes, so it seems that "escapeChildren" also effects nodes after self closing node.</p>
<p>Is this intended or a bug?</p>
<p><ext:viewhelper /></p>
<p><ext:nextviewhelper></ext:nextviewhelper></p>
<p>In this case escapeChildren would also be set in the scope of ext:nextviewhelper</p> TYPO3 Core - Task #75026 (Closed): Refactore Acceptance Tests to centralize CSS and XPath selecto...http://forge.typo3.org/issues/750262016-03-12T13:35:33ZTimo Hund
<p>In the acceptance tests we should refactor the structure in a way the it is easier later to adapt them to css changes.</p>
<p>I would propose to introduce a BackendSelectors class that could be retrieved from the actor to get common selectors.</p> TYPO3 Core - Bug #74503 (Closed): Can not change sort order of template includes in current 7.6.5...http://forge.typo3.org/issues/745032016-03-08T16:06:43ZTimo Hund
<p>In the current 7.6.5 development state i have a problem to change the order of included TypoScript Templates in the backend.</p> TYPO3 Core - Task #74379 (Closed): Acceptance tests should be more stable on travishttp://forge.typo3.org/issues/743792016-03-06T20:38:20ZTimo Hund
<p>Currently some of the acceptance tests fail on travis-ci because of timing issues. We should investigate this and make them more stable.</p> TYPO3 Core - Task #74334 (Closed): The Scheduler should be tested with an acceptance testhttp://forge.typo3.org/issues/743342016-03-05T20:22:32ZTimo Hund
<p>The scheduler should be tested with an acceptance test. We should check<br />if we can create and execute an scheduler task.</p> TYPO3 Core - Task #74177 (Closed): Remove fileinfo as dependency in SystemEnvironment/Checkhttp://forge.typo3.org/issues/741772016-03-04T14:49:22ZTimo Hund
<p>Currenty 'fileinfo' is listed as required php extension in SystemEnvironment/Check<br />but it is currently not really required and prevents from installing TYPO3 on Systems where it is not present (e.g. Mircosoft Azure Cloud)</p>
<p>The class is currently only used once in the core in "TYPO3\CMS\Core\Type\File\FileInfo" and only when it exists, so it is not really a hard dependency.</p>
<p>Also grepping on an installation folder does not find any match where \finfo is really required.</p>