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 #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 #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 #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 #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> TYPO3 Core - Bug #99493 (New): On CLI no exceptions are loggedhttp://forge.typo3.org/issues/994932023-01-08T18:08:54ZHelmut Hummeltypo3@helhum.io
<p>Since symfony/console catches all exceptions from commands<br />to render the exception, the TYPO3 exception handler is never triggered,<br />thus not only completely unused on CLI, but also does not log anything<br />to the configured logs</p> TYPO3 Core - Bug #99465 (Closed): Accessing site configuration via TypoScript getData triggers a ...http://forge.typo3.org/issues/994652023-01-05T12:24:43ZHelmut Hummeltypo3@helhum.io
<p>The following stdWrap code currently triggers a log warning:</p>
<pre>
if.isTrue.data = site:settings.optional.property
</pre>
<p>My expectation is, that this "incident" should rather be logged at least as notice instead,<br />since the value accessed could intentionally be an optional value.</p> TYPO3 Core - Bug #98484 (Closed): Install all extensions in vendor folder for composer based inst...http://forge.typo3.org/issues/984842022-09-30T14:43:07ZHelmut Hummeltypo3@helhum.ioTYPO3 Core - Bug #98121 (Closed): <typo3-backend-icon> does not reflect icon size when size is se...http://forge.typo3.org/issues/981212022-08-10T22:50:54ZHelmut Hummeltypo3@helhum.io
<p>When using the custom element <typo3-backend-icon><br />with a JS framework, that renders the DOM (e.g. Vue <a class="external" href="https://github.com/vuejs/core/issues/3738">https://github.com/vuejs/core/issues/3738</a> <a class="external" href="https://github.com/vuejs/core/issues/3792">https://github.com/vuejs/core/issues/3792</a>),<br />it can happen, that they set the properties of the custom element<br />instead of an attribute.</p>
<p>Since Lit does not reflect these properties to attributes by default,<br />but the icon-element relies on CSS set on the host element that depends<br />on the size attribute, the icon is not rendered in the correct size.</p>
<p>See: <a class="external" href="https://web.dev/custom-elements-best-practices/">https://web.dev/custom-elements-best-practices/</a><br />on why reflecting properties to attributes might be a good idea<br />in some cases.</p>
<p>To reproduce put the following in a Fluid template of a backend module (TYPO3 12/ main):</p>
<pre>
<f:be.pageRenderer includeJavaScriptModules="{0: '@typo3/backend/element/icon-element.js'}"/>
<div id="app" style="font-size: 8px"></div>
<script>
let icon = document.createElement('typo3-backend-icon');
icon.identifier = 'actions-search';
icon.size = 'large';
document.getElementById('app').appendChild(icon);
</script>
</pre>
<p>Expected:</p>
<p>Large icon</p>
<p>Actual:</p>
<p>Very small icon</p>
<p>For TYPO3 11, the page renderer VH is different:</p>
<pre>
<f:be.pageRenderer includeRequireJsModules="{0: 'TYPO3/CMS/Backend/Element/IconElement'}"/>
</pre>
<p>The rest is the same</p>