TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-09-08T08:31:55ZTYPO3 Forge
Redmine TYPO3 Core - Feature #101879 (New): Decouple TYPO3\CMS\Core\Tree\TableConfiguration\TreeDataProvi...http://forge.typo3.org/issues/1018792023-09-08T08:31:55ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<ol>
<li>Story<br />As a developer i want to be able to use a database independent treeConfig/DataProvider in TCA/FlexForms select fields of renderType selectTree.</li>
</ol>
<ol>
<li>Details<br />ATM the TreeDataProviderFactory is tightly coupled to the internal implementation of the DatabaseTreeDataProvider.<br />It checks for 'foreign_table', 'childrenField' and 'parentField' while this should be done by the specific TreeDataProvider itself.</li>
</ol>
<p>With the removal of the "internal_type" check this behavior forces you to set thoose fields even if your treeDataProvide is not even using a database see:<br /><a class="external" href="https://github.com/TYPO3/typo3/commit/6f557ac5aae1b44f882dfbe09d60c2f68ce3534d#diff-2a75aeb556ea1fbf95b8ff85c45804ae0141c922fe2b1561362fa91555ce0c40L69">https://github.com/TYPO3/typo3/commit/6f557ac5aae1b44f882dfbe09d60c2f68ce3534d#diff-2a75aeb556ea1fbf95b8ff85c45804ae0141c922fe2b1561362fa91555ce0c40L69</a></p>
<ol>
<li>Example<br />Lets say you want to provide TreeData from remote Source e.g. a Webservice. <br />In this case you need to provide dummy foreign_table, ChildrenField and ParentField as well as adding the corresponding setters to your TreeDataProvider even though they are not used at all.</li>
</ol>
<ol>
<li>Solution<br />Leave the TCA Checks to the Dataprovider itself. <br />Remove the tight coupling to the DatabaseTreeProvider:<br /><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L71">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L71</a><br /><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L73">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L73</a><br /><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L80">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L80</a><br /><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L112">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/Tree/TableConfiguration/TreeDataProviderFactory.php#L112</a></li>
</ol>
<p>A treeConfig with a custom TreeDataProvider is not "invalid" if "foreign_table" or the child/Parent field is missing :)</p> TYPO3 Core - Bug #101344 (Resolved): Call to a member function getSetupArray() for custom t3 reco...http://forge.typo3.org/issues/1013442023-07-13T09:41:32ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Prior in TYPO3v11 the Linkbrowser respected custom linkhandler configuration in TCEMAIN.linkHandler.</p>
<p>In TYPO3v12 it does not.</p>
<p>Even worse: <br />If the target field of the redirect contains a custom t3-record link e.g.: t3://record?identifier=news&uid=4</p>
<p>The Redirect module fails with:<br />Call to a member function getSetupArray() on null in /var/www/html/vendor/typo3/cms-frontend/Classes/Typolink/DatabaseRecordLinkBuilder.php line 41</p> TYPO3 Core - Bug #100351 (New): ElementBrowserRecordlist::isRowListingConditionFulfilled does not...http://forge.typo3.org/issues/1003512023-03-29T15:48:25ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p><strong>Story</strong><br />The element browser should respect the filter property of group fields. <br />This works for regular TCA group field definitions but not for group fields comming from a flexform.<br />This missbehavior is caused by function isRowListingConditionFulfilled fetching the field configuration from from the relating table and field which in case of a flexform is always "tt_conntent"/pi_flexfrom insteand of the actual configuration within the flexform.</p>
<p>Therefor filter userfunc are not executed for groupfields configured within flexforms.</p>
<p><strong>Reproduce</strong><br />Add a flexform to a plugin.<br />E.g.:<br /><pre><code class="xml syntaxhl" data-language="xml"><span class="nt"><config></span>
<span class="nt"><type></span>group<span class="nt"></type></span>
<span class="nt"><internal_type></span>db<span class="nt"></internal_type></span>
<span class="nt"><allowed></span>tx_foo_domain_model_bar<span class="nt"></allowed></span>
<span class="nt"><minitems></span>1<span class="nt"></minitems></span>
<span class="nt"><filter></span>
<span class="nt"><numIndex</span> <span class="na">index=</span><span class="s">"0"</span><span class="nt">></span>
<span class="nt"><userFunc></span>Foo/User/Filter->doFilter<span class="nt"></userFunc></span>
<span class="nt"><parameters></span>
<span class="nt"><myParameter></span>abc<span class="nt"></myParameter></span>
<span class="nt"></parameters></span>
<span class="nt"></numIndex></span>
<span class="nt"></filter></span>
<span class="nt"></config></span>
</code></pre></p>
<p><strong>Expected Behavior</strong><br />Foo/User/Filter->doFilter should be called</p>
<p><strong>Actual Behavior</strong><br />Foo/User/Filter->doFilter is not called because isRowListingConditionFulfilled looks for a filter in <br /><pre><code class="php syntaxhl" data-language="php"><span class="nv">$GLOBALS</span><span class="p">[</span><span class="s1">'TCA'</span><span class="p">][</span><span class="s1">'tt_content'</span><span class="p">][</span><span class="s1">'columns'</span><span class="p">][</span><span class="s1">'pi_flexform'</span><span class="p">][</span><span class="s1">'config'</span><span class="p">]</span>
</code></pre></p>
<p><strong>Possible Solution</strong><br />Introduce an exception for pi_flexform. Not that easy though because the content of the pi_flexform is not available at this point.</p> TYPO3 Core - Bug #95496 (Closed): TYPO3\CMS\Backend\Form\Behavior\UpdateValueOnFieldChange::__con...http://forge.typo3.org/issues/954962021-10-06T14:33:17ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>The constructor of TYPO3\CMS\Backend\Form\Behavior\UpdateValueOnFieldChange expects the $identifier to be a string.</p>
<p>Unfortunatly $identifier is (can be )an integer when called from TYPO3\CMS\Backend\Controller\FormFlexAjaxController.<br />See <a class="external" href="https://github.com/TYPO3/typo3/blob/master/typo3/sysext/backend/Classes/Controller/FormFlexAjaxController.php#L131">https://github.com/TYPO3/typo3/blob/master/typo3/sysext/backend/Classes/Controller/FormFlexAjaxController.php#L131</a></p>
<p>Quick and dirty fix would be just cast it to a string before passing it.</p> TYPO3 Core - Bug #81036 (New): TCA l18n_parent is processed for sys_language_uid 0http://forge.typo3.org/issues/810362017-04-27T10:39:51ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>When opening a TCA Form of e.g. a tt_content record of sys_language_id 0 the l18n_parent field is processed, though the field isn't even displayed.</p>
<p>If you v a lot of tt_content records on the same pid this leads to major performance issues.</p>
<p>E.g. if arround 45k tt_content records on the same pid which are used by a container record via IRRE (kind of like the news does).</p>
<p>If there r 10 Records attached to the container records that leads to 10x45k interations in TYPO3\CMS\Backend\Form\FormDataProvider\AbstractItemProvider\addItemsFromForeignTable which takes 40sec. On my maschine :).</p>
<p>The only way to get arround this is to set type=>none to l18n_parent via override.</p>
<p>This behavior did not exist in TYPO3 6.1 (not sure about later versions).<br />I assume it has been introduced by the rewriting of the whole tce/form stuff.</p>
<p><strong>I think this is more a general issue, imho fields that r not displayed at all by e.g. DisplayCond should be filtered earlier so that dont make their way through the itemProvider.</strong></p>
<p>Note: this issues is not restricted to tt_content. In general: fields are processed by itemProviders/Dataproviders no matter if they r acctually displayed/used or not.</p> TYPO3 Core - Bug #24838 (Closed): [Unit Tests] t3lib_formprotection_BackendFormProtectionTest cau...http://forge.typo3.org/issues/248382011-01-26T17:15:54ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>The t3lib_formprotection_BackendFormProtectionTest test sets $GLOBALS['BE_USER'] to a mocked BE user object.</p>
<p>Revision 10306 introduced t3lib_formprotection_BackendFormProtection::isAuthorizedBackendSession()</p>
<p>The methode isAuthorizedBackendSession() is called on construction of t3lib_formprotection_BackendFormProtection and an exception is thrown if it fails.</p>
<p>Within the test an instance of t3lib_formprotection_BackendFormProtection is created. This fails due to the above mentioned BE user mocking and the checks in isAuthorizedBackendSession() (see source).</p>
<p>Furthermore a php fatal error occurs since __destruct() is call within tearDown of the test. Which isn't possible since the object has never been created (due to exception in constructor).</p>
<p>This is just a quickfix. It would be better to stop messing arround with GLOBALS within tests and the actuall class implementation.</p>
<p>Something like: isAuthorizedBackendSession($beSession) and injection of the current beSession on construction would be much cleaner and easier to test imho. But that is another story. <br />(issue imported from #M17342)</p> TYPO3 Core - Bug #23276 (Closed): Use t3lib_div::getIndpEnv('SCRIPT_FILENAME') to determine PATH_...http://forge.typo3.org/issues/232762010-07-27T12:11:17ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Currently PATH_thisScript is checked/defined in several files using a pretty ugly "monster clause chain"</p>
<p>Changing this to t3lib_div::getIndpEnv('SCRIPT_FILENAME') makes things more readable and maintainable.</p>
<p>This is a pre-condition for resolving:</p>
<p><a class="external" href="http://bugs.typo3.org/view.php?id=15241">http://bugs.typo3.org/view.php?id=15241</a></p>
<p>(issue imported from #M15246)</p> TYPO3 Core - Bug #23271 (Closed): Recognize php-fpm sapi for path generation.http://forge.typo3.org/issues/232712010-07-26T18:03:30ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>$PATH_thisScript is determined depending on the used PHP SAPI. As of version 5.3.3 php ships with php-fpm. Currently TYPO3 does not recognizes it. Therefor the path determination fails.</p>
<p>(issue imported from #M15241)</p> TYPO3 Core - Bug #23130 (Closed): Remove trailing whitespaces in front of EOLhttp://forge.typo3.org/issues/231302010-07-08T14:45:56ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>obvious</p>
<p>(issue imported from #M15047)</p> TYPO3 Core - Bug #23129 (Closed): Trailing newlines after php closing tag.http://forge.typo3.org/issues/231292010-07-08T11:59:34ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Some core classes contain newline characters after the php closing tag (?>).<br />Although a single newline character doesn't harm (see <a class="external" href="http://bugs.php.net/bug.php?id=21891">http://bugs.php.net/bug.php?id=21891</a>) the CGL explicit states: "There must be no empty lines after the closing PHP tag." (see: <a class="external" href="http://typo3.org/documentation/document-library/core-documentation/doc_core_cgl/4.4.1/view/1/3/">http://typo3.org/documentation/document-library/core-documentation/doc_core_cgl/4.4.1/view/1/3/</a>).</p>
<p>(issue imported from #M15045)</p> TYPO3 Core - Bug #23117 (Closed): Testcase for t3lib_div::isFirstPartOfStr is missing.http://forge.typo3.org/issues/231172010-07-07T15:26:26ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>obvious</p>
<p>(issue imported from #M15029)</p> TYPO3 Core - Bug #22202 (Closed): Improve performance of t3lib_div::revExplodehttp://forge.typo3.org/issues/222022010-02-26T13:14:27ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Replace foreach by array walk.</p>
<p>(issue imported from #M13681)</p> TYPO3 Core - Bug #22158 (Closed): Replace calls to t3lib_div:: within t3lib_div to self:: du to p...http://forge.typo3.org/issues/221582010-02-22T16:20:31ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Currently t3lib_div uses t3lib_div:: to refere to itself statically.</p>
<p>Self:: is 8% to 10% faster than using classname:: due to the fact that no scope resolution has to be performed.</p>
<p>See:<br /><a class="external" href="http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_API.c?view=markup">http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/Zend/zend_API.c?view=markup</a></p>
<p>Line(2154 to 2164).</p>
<p>Minitest:<br /><?php<br />class Test {<br /> public static function a() {<br /> Test::c();<br /> }</p>
<pre><code>public static function b() {<br /> self::c();<br /> }</code></pre>
<pre><code>static function c() {<br /> $a = 1;<br /> }<br />}</code></pre>
<p>$interation = 100000;</p>
<p>$timeStart = microtime();<br />for ($i = 1; $i <= $interation; $i++) {<br /> Test::a();<br />}<br />$timeEnd = microtime();<br />$time = $timeEnd - $timeStart;<br />echo $time . ' seconds -> ' . $interation . 'x Test::c <br />';</p>
<p>$timeStart = microtime();<br />for ($i = 1; $i <= $interation; $i++) {<br /> Test::b();<br />}<br />$timeEnd = microtime();<br />$time = $timeEnd - $timeStart;<br />echo $time . ' seconds -> ' . $interation . 'x self::c <br />';<br />?><br />(issue imported from #M13611)</p> TYPO3 Core - Feature #21666 (Closed): Introduce seperate templates for the diverent states of "lo...http://forge.typo3.org/issues/216662009-11-24T14:38:19ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Currently different states of the login subpart are implemented by setting the formpart to '' and other status messages. I would be greate to have seperate subpart for each state.</p>
<p>(issue imported from #M12730)</p> TYPO3 Core - Feature #21662 (Accepted): Optionaly disable (or notifiy on) concurrent loginshttp://forge.typo3.org/issues/216622009-11-24T11:55:51ZNikolas Hagelsteinnikolas.hagelstein@gmail.com
<p>Currently there is no way to controll concurent logins.</p>
<p>Suggestion add an option to prevent concurrent logins.</p>
<p>(issue imported from #M12725)</p>