TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-02-26T11:08:29ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103199 (Resolved): TransformViewHelper throws exception when spam protection is...http://forge.typo3.org/issues/1031992024-02-26T11:08:29ZHelmut Hummeltypo3@helhum.io
<p>DOMElement::setAttribute(): Argument #2 ($value) must be of type string, int given<br />typo3/cms-frontend/Classes/Html/HtmlWorker.php line 128</p>
<p>Reason is that on data attribute value is of type integer.</p> TYPO3 Core - Bug #102403 (Under Review): The cli setup command create different config files as t...http://forge.typo3.org/issues/1024032023-11-19T16:42:42ZHelmut Hummeltypo3@helhum.io
<p>During cli install the FactoryConfiguration.php is not respected at all</p> TYPO3 Core - Bug #101871 (Resolved): PackageArtifactBuilder still tries to create symlinks on Win...http://forge.typo3.org/issues/1018712023-09-07T09:51:24ZHelmut Hummeltypo3@helhum.io
<p>When a juction already exists, the code tries to also create a symlink on Windows</p> TYPO3 Core - Bug #101870 (Resolved): Simplify filesystem usage in PackageArtifactBuilderhttp://forge.typo3.org/issues/1018702023-09-07T09:46:32ZHelmut Hummeltypo3@helhum.io
<p>Only create one filesystem object,<br />instead of always creating new ones where needed.</p> TYPO3 Core - Bug #101868 (Resolved): #100719 breaks TYPO3 Console due to breaking change in Defau...http://forge.typo3.org/issues/1018682023-09-07T09:04:46ZHelmut Hummeltypo3@helhum.io
<p>Although, DefaultFactory is marked as internal API, I suggest to not break the API in a bugfix release.</p> TYPO3 Core - Bug #101678 (Resolved): setup command does not create PackageStates.php in non Compo...http://forge.typo3.org/issues/1016782023-08-14T11:02:51ZHelmut Hummeltypo3@helhum.io
<p>The code to create PackageStates.php is missing in SetupCommand.</p>
<p>Also from cli the .htaccess is not created, because \TYPO3\CMS\Install\FolderStructure\DefaultFactory does not create it due to missing context on cli. on cli an additional step for that needs to be created</p> TYPO3 Core - Bug #101212 (Resolved): FLUIDTEMPLATE content object can be cleaned uphttp://forge.typo3.org/issues/1012122023-06-30T17:21:06ZHelmut Hummeltypo3@helhum.io
<p>In previous TYPO3 versions content objects shared some instances.<br />This is not the case any more, allowing the workaround to be removed.</p> TYPO3 Core - Bug #101201 (Resolved): Clean up ContenObjectRenderer usagehttp://forge.typo3.org/issues/1012012023-06-29T15:17:08ZHelmut Hummeltypo3@helhum.io
<p>With the refactoring of Extbase ConfigurationManager, there are some leftovers<br />that can be cleaned up or simplified.</p> TYPO3 Core - Bug #101170 (Resolved): ContentObjectRenderer instance is not always and not properl...http://forge.typo3.org/issues/1011702023-06-26T15:15:14ZHelmut Hummeltypo3@helhum.io
<a name="Prerequisite"></a>
<h2 >Prerequisite<a href="#Prerequisite" class="wiki-anchor">¶</a></h2>
<p>Given the following TypoScript:</p>
<pre><code>
page = PAGE
page.10 = EXTBASEPLUGIN
page.10 {
extensionName = MyExt
pluginName = MyPlugin
}
</code></pre>
<p>Given the default action referenced plugin is cached</p>
<a name="Expectation"></a>
<h2 >Expectation<a href="#Expectation" class="wiki-anchor">¶</a></h2>
<p>The request in the plugin (and the ConfigurationManager has the currentContentObject attribute set.</p>
<a name="Actual-behaviour"></a>
<h2 >Actual behaviour<a href="#Actual-behaviour" class="wiki-anchor">¶</a></h2>
<p>The currentContentObject is not set</p>
<a name="Conceptual-considerations"></a>
<h3 >Conceptual considerations<a href="#Conceptual-considerations" class="wiki-anchor">¶</a></h3>
<p>During frontend rendering, all rendering is initiated with an instance of ContentObjectRenderer.<br />Since most rendering code depends on the current request, the request has always to be passed to<br />the ContentObjectRenderer, which can then pass it to rendering code it calls.<br />At the same time some rendering code depends also depends on the data,<br />that initiated the rendering (aka, the data that is contained in ContentObjectRenderer objects).</p>
<p>I see two options of how to pass the request <strong>and</strong> the ContentObjectRenderer object (cObj) to the rendering code:</p>
<ol>
<li>Extend the API to make both accessible directly</li>
<li>Wrap the initiating cObj (the cObj that initiates rendering) into the request it holds as attribute</li>
</ol>
<p>I suggested the latter in <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Provide current content object as request attribute (Closed)" href="http://forge.typo3.org/issues/100623">#100623</a>, but what we merged in the end is incomplete and therefore somewhat broken (see above)</p>
<p>I'm still wondering, if we should add the attribute to the request (at least in v12), directly in the request setter in ContentObjectRenderer.</p> TYPO3 Core - Bug #101164 (Resolved): The newly introduced EXTBASEPLUGIN content object does not a...http://forge.typo3.org/issues/1011642023-06-25T18:47:47ZHelmut Hummeltypo3@helhum.io
<p>While all other content element implement and check for top level stdWrap<br />property, the EXTBASEPLUGIN does not.</p>
<p>This unnecessary limits the extensibility of this content object compared to<br />USER object, that was used beforehand</p> TYPO3 Core - Bug #100925 (Resolved): Improve database schema cachehttp://forge.typo3.org/issues/1009252023-05-27T13:29:03ZHelmut Hummeltypo3@helhum.io
<p>Using the core cache for schema information comes with<br />various drawbacks.<br />1. There is no way to flush single core cache entries,<br /> thus the complete core cache needs to be flushed when<br /> changing the database schema<br />2. The PHP Frontend provides no benefit, when the to be cached<br /> information has to be serialized anyway.</p>
<p>Last but not least, currently not only the core cache, but ALL caches<br />are flushed after schema updates, which leads to errors, when some cache tables<br />are not created during one schema update.</p> TYPO3 Core - Bug #100374 (Rejected): When the password policy is disabled by configuration, it is...http://forge.typo3.org/issues/1003742023-04-01T08:13:40ZHelmut Hummeltypo3@helhum.io
<ul>
<li>set passwordPolicy to "none" in configuration</li>
<li>go to user settings of an admin and change password</li>
</ul>
<p>expected result:</p>
<p>password is changed without error</p>
<p>actual result:</p>
<p>no error is presented to the user, but password is not changed, because DataHandler still evaluates TCA enforcing the policy</p> TYPO3 Core - Bug #100160 (Resolved): Allow other SF console application instances in CommandAppli...http://forge.typo3.org/issues/1001602023-03-14T09:40:27ZHelmut Hummeltypo3@helhum.io
<p>After creating an own subclass of SF command Application for <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: TYPO3 cli bin: Add version info for PHP to top of output (Closed)" href="http://forge.typo3.org/issues/100019">#100019</a> <br />the property type was also changed, which wasn't necessary and an oversight<br />during reviews.</p>
<p>Property type should stay the same</p> TYPO3 Core - Task #100073 (Closed): Allow more use cases for Symfony expression evaluationhttp://forge.typo3.org/issues/1000732023-03-03T15:08:41ZHelmut Hummeltypo3@helhum.io
<p>Currently the TYPO3 API wrapper around expression evaluation is typed to only<br />allow boolean results and casts the result to boolean to achieve that.</p>
<p>To allow other expression evaluation where other types might be returned,<br />the return type should be mixed</p> TYPO3 Core - Bug #100059 (Closed): Events dispatched by Symfony EventDispatcher are not dispatche...http://forge.typo3.org/issues/1000592023-03-01T19:11:46ZHelmut Hummeltypo3@helhum.io
<p>I think this happened with removing the TYPO3 SF Adapter</p>