TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-14T07:43:11ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103393 (Under Review): New IRRE (inline) records created within FlexForm have t...http://forge.typo3.org/issues/1033932024-03-14T07:43:11ZDaniel Siepmanncoding@daniel-siepmann.de
<p>This is a single issue for Cause of bug 1 of parent issue.<br />In order to allow a single Patch for Cause 1 referencing a proper issue.</p> TYPO3 Core - Bug #103174 (Resolved): CustomFileControlsEvent does not support javaScriptModuleshttp://forge.typo3.org/issues/1031742024-02-22T07:20:16ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The event provides access to the `$resultArray` and allows to set a new version of that variable.<br />But the triggering code does not use the modified version.</p>
<p>That array holds a list of javaScriptModules to load. This info is not respected.</p>
<p>This worked prior the event when one used a UserFunction in order to add custom controls, as the resultArray was provided and could be handled as reference.</p>
<p>It seems I could fix this via:<br /><pre><code class="diff syntaxhl" data-language="diff"><span class="gh">diff --git a/typo3/sysext/backend/Classes/Form/Container/FilesControlContainer.php b/typo3/sysext/backend/Classes/Form/Container/FilesControlContainer.php
index c231c8d076..250e1b7e68 100644
</span><span class="gd">--- a/typo3/sysext/backend/Classes/Form/Container/FilesControlContainer.php
</span><span class="gi">+++ b/typo3/sysext/backend/Classes/Form/Container/FilesControlContainer.php
</span><span class="p">@@ -271,14 +271,15 @@</span> class FilesControlContainer extends AbstractContainer
}
}
<span class="err">
</span><span class="gd">- $controls = $this->eventDispatcher->dispatch(
</span><span class="gi">+ $event = GeneralUtility::makeInstance(EventDispatcherInterface::class)->dispatch(
</span> new CustomFileControlsEvent($resultArray, $table, $field, $row, $config, $formFieldIdentifier, $formFieldName)
<span class="gd">- )->getControls();
</span><span class="gi">+ );
+ $resultArray = $event->getResultArray();
</span><span class="err">
</span><span class="gd">- if ($controls !== []) {
</span><span class="gi">+ if ($event->getControls() !== []) {
</span> $view->assign('customControls', [
'id' => $formFieldIdentifier . '_customControls',
<span class="gd">- 'controls' => implode("\n", $controls),
</span><span class="gi">+ 'controls' => implode("\n", $event->getControls()),
</span> ]);
}
</code></pre></p>
<p>But then I end up with<br /><pre>
Uncaught (in promise) Error: Unable to resolve specifier '@e2/e2-core/FilePathBasedBrowser/SearchForm.js' imported from http://localhost:8080/typo3/record/edit?token=a91f1f57ee42b3
</pre></p>
<p>I expect <a class="external" href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-98479-RemovedFileReferenceRelatedFunctionality.html">https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-98479-RemovedFileReferenceRelatedFunctionality.html</a> to be the change that broke the feature.</p> TYPO3 Core - Feature #103080 (Closed): Lacking of file search input within link wizardhttp://forge.typo3.org/issues/1030802024-02-08T07:26:05ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Our editors are happy with the search input for file names within the File module.<br />But they miss the same feature within the link wizard for files. There only the file tree has a search input, but files on the right side lack that feature.</p>
<p>See the two screenshots for comparison.</p>
<p>Our TYPO3 Version is v12 LTS.</p> TYPO3 Core - Bug #103061 (Closed): Broken link "official docs" of extension scannerhttp://forge.typo3.org/issues/1030612024-02-06T12:08:29ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The scanner links to <a class="external" href="https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/ExtensionScanner/Index.html">https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/ExtensionScanner/Index.html</a> which redirects to <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/HowTo/UpdateExtensions/ExtensionScanner/Index.html">https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/HowTo/UpdateExtensions/ExtensionScanner/Index.html</a> which is a 404.</p>
<p>The scanner could directly link to the proper url <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/HowTo/UpdateExtensions/ExtensionScanner.html">https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/HowTo/UpdateExtensions/ExtensionScanner.html</a></p> TYPO3 Core - Bug #103056 (Closed): The extension scanner does not report "Breaking: #96641 - Typo...http://forge.typo3.org/issues/1030562024-02-06T08:00:24ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The change log entry can be found at: <a class="external" href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-96641-TypoLinkRelatedHooksRemoved.html">https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.0/Breaking-96641-TypoLinkRelatedHooksRemoved.html</a></p>
<p>I'd expect the scanner to report a strong match for those two occurences:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['SC_OPTIONS']['tslib/class.tslib_content.php']['typoLink_PostProc'][$extKey] = \Vendor\OurKey\LinkBuilding\CustomCssClassBasedOnType::class . '->process';
</pre>
<p>And:</p>
<pre>
\TYPO3\CMS\Core\Utility\ArrayUtility::mergeRecursiveWithOverrule($GLOBALS['TYPO3_CONF_VARS'], [
'SC_OPTIONS' => [
'tslib/class.tslib_content.php' => [
'typoLink_PostProc' => [
$extKey => \Vendor\OurKey\LinkBuilding\CustomCssClassBasedOnType::class . '->process',
],
],
],
]);
</pre>
<p>Neither is reported.</p> TYPO3 Core - Bug #103050 (New): Calendar UX is bad on small screenshttp://forge.typo3.org/issues/1030502024-02-05T14:27:44ZDaniel Siepmanncoding@daniel-siepmann.de
<p>One of our customers has devices with small screens.<br />The calendar is not fully visible on those small screens. Also it is not possible to scroll the calendar into view port. The calendar will follow the scrolling.</p>
<p>It worked better in v10. There the screen was actually scrollable. The calendar sticked to its position and one could scroll the view port.</p> TYPO3 Core - Bug #103048 (Resolved): "this.createRenderRoot is not a function" JavaScript error i...http://forge.typo3.org/issues/1030482024-02-05T13:33:40ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Given that:<br />I am in the TYPO3 backend<br />And I open the install tool Update module<br />And trigger the "Check for Broken Extensions" or "Check TCA in ext_tables.php" I receive the following JS error within console.</p>
<p>It works fine within standalone version of the install tool. Also works fine in v12.<br />I only tested with released 13.0.0 via composer install, didn't check main.</p> TYPO3 Core - Bug #103004 (Closed): TMENUITEM cObject no longer has access to linked pagehttp://forge.typo3.org/issues/1030042024-01-31T10:42:22ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The docs still state:</p>
<blockquote>
<p>The current record is the page record of the menu item. If you would like to get data from the current menu item's page record, use stdWrap.data = field : [field name].</p>
</blockquote>
<p>at <a class="external" href="https://docs.typo3.org/m/typo3/reference-typoscript/12.4/en-us/MenuObjects/Tmenuitem/Index.html">https://docs.typo3.org/m/typo3/reference-typoscript/12.4/en-us/MenuObjects/Tmenuitem/Index.html</a> which worked in v10.<br />But this doesn't seem to work in v12 anymore.</p>
<p>Given the following TypoScript the data is resolved to the actual content element, not the menu page entry.</p>
<pre>
tt_content.menu_subpages {
20 {
1.NO.ATagTitle >
1.NO.ATagParams {
cObject = COA
cObject {
10 = TEXT
10 {
typolink {
parameter.field = uid
returnLast = url
}
noTrimWrap = |onclick="econdaTrackMarker('footer|');" |
}
20 = TEXT
20 {
typolink {
parameter.field = uid
returnLast = url
}
wrap = data-tracking-marker="footer|"
}
30 = TEXT
30 {
wrap = data-qa="|"
field = tx_e2core_qa_identifier
required = 1
}
}
stdWrap {
replacement {
1 {
search = .html
replace =
}
}
}
}
}
}
</pre> TYPO3 Core - Feature #102815 (Closed): Support ApplicationContext in TypoScript data/getText (.if)http://forge.typo3.org/issues/1028152024-01-11T08:57:29ZDaniel Siepmanncoding@daniel-siepmann.de
<p>TypoScript already supports ApplicationContext within Conditions, see: <a class="issue tracker-2 status-5 priority-4 priority-default closed child" title="Feature: TypoScript: Application Context condition (Closed)" href="http://forge.typo3.org/issues/50132">#50132</a> <br />But the context is not yet exposed via data/getText: <a class="external" href="https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/Functions/Data.html">https://docs.typo3.org/m/typo3/reference-typoscript/main/en-us/Functions/Data.html</a></p>
<p>This would enable to use this within `.if` conditions as well and streamline integrator experience.</p> TYPO3 Core - Bug #102573 (New): TypeError: strcasecmp(): Argument #1 ($string1) must be of type s...http://forge.typo3.org/issues/1025732023-11-30T14:27:24ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The TYPO3 API does not state that ArrayUtility::sortArraysByKey() should only work for strings. One can expect it to work with integers as well.</p>
<p>But the given code leads to an type error:</p>
<pre>
\TYPO3\CMS\Core\Utility\ArrayUtility::sortArraysByKey([
[
'key' => 10,
],
[
'key' => 11,
],
], 'key');
</pre>
<p>I'd either expect it to working, or a proper note in PHPDoc and type check upfront.<br />The issue occurs in TYPO3 v12, not in v11. Probably due to the added <code>strict_types=1</code>.</p> TYPO3 Core - Bug #102567 (New): Send 400 Bad Request in case of Extbase POST request with missing...http://forge.typo3.org/issues/1025672023-11-30T11:26:59ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Given the following setup:</p>
<ol>
<li>An Extbase action with a required argument</li>
<li>That Extbase action only will be called via POST (this can not be enforced yet, see: <a class="external" href="https://decisions.typo3.org/t/align-extbase-more-with-symfony/">https://decisions.typo3.org/t/align-extbase-more-with-symfony/</a>)</li>
<li>The action is called without that argument</li>
</ol>
<p>Right now Extbase would throw an exception: <a class="external" href="https://github.com/TYPO3/typo3/blob/v12.4.8/typo3/sysext/extbase/Classes/Mvc/Controller/ActionController.php#L818">https://github.com/TYPO3/typo3/blob/v12.4.8/typo3/sysext/extbase/Classes/Mvc/Controller/ActionController.php#L818</a></p>
<p>Proposal: Extbase should deliver a "400 Bad Request".</p>
<p>This can happen if stupid bots crawl a site. This might spam the logs with the Extbase exception.</p>
<p>This can be implemented without <a class="external" href="https://decisions.typo3.org/t/align-extbase-more-with-symfony/">https://decisions.typo3.org/t/align-extbase-more-with-symfony/</a>. That than can come on top in order to enforce Extbase to only call the action if the current request is a POST request. That again prevents flooding the logs by bad bots that might call the action via get request.</p> TYPO3 Core - Bug #102529 (New): Properly support HTTP Status Code 201 within extbasehttp://forge.typo3.org/issues/1025292023-11-27T14:53:07ZDaniel Siepmanncoding@daniel-siepmann.de
Sources regarding HTTP Status Code 201:
<ul>
<li><a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201">https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201</a></li>
<li><a class="external" href="https://www.rfc-editor.org/rfc/rfc9110#name-201-created">https://www.rfc-editor.org/rfc/rfc9110#name-201-created</a></li>
</ul>
<p>The 201 status code can contain a location header, like the 3xx redirect status codes.<br />This is currently not possible via Extbase, as Extbase has hard checks regarding >= 300 within the Bootstrap class after internal dispatching of the request. Returning a redirect with 201 and a url is therefore not working as expected.</p>
<p>Browsers (tested with Firefox) probably do not support this, but APIs might need to conform to this.</p>
<p>The corresponding checks regarding >=300 could be adjusted to also check for 201 status code.</p> TYPO3 Core - Feature #101446 (Accepted): Prevent re processing images with "same" processing inst...http://forge.typo3.org/issues/1014462023-07-26T06:23:04ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Foremost I'm not sure if TYPO3 should change that. Still I try to explain our scenario and a possible solution. I'm fine if TYPO3 decides to reject the issue.</p>
<p>Environment:<br />TYPO3 11.5.23<br />PHP 8.1</p>
<p>Our scenario:<br />We had a small code that called <code>applyProcessingInstructions()</code> of <code>TYPO3\CMS\Extbase\Service\ImageService</code><br />The code looked like this:<br /><pre><code class="php syntaxhl" data-language="php"><span class="nv">$cropParam</span> <span class="o">=</span> <span class="p">(</span><span class="nv">$crop</span><span class="p">)</span><span class="o">?</span><span class="s1">'c'</span><span class="o">:</span><span class="s1">''</span><span class="p">;</span>
<span class="nv">$processingInstructions</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'width'</span> <span class="o">=></span> <span class="nv">$imageWidth</span> <span class="mf">.</span> <span class="nv">$cropParam</span><span class="p">,</span>
<span class="s1">'crop'</span> <span class="o">=></span> <span class="nv">$this</span><span class="o">-></span><span class="nf">getCropArea</span><span class="p">(</span><span class="nv">$imageObj</span><span class="p">,</span> <span class="nv">$cropVariant</span><span class="p">),</span>
<span class="p">];</span>
<span class="k">if</span> <span class="p">(</span><span class="nv">$forceRatio</span> <span class="o">></span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="nv">$processingInstructions</span><span class="p">[</span><span class="s1">'height'</span><span class="p">]</span> <span class="o">=</span> <span class="p">(</span><span class="nv">$crop</span><span class="p">)</span> <span class="o">?</span> <span class="nv">$imageWidth</span> <span class="o">/</span> <span class="nv">$forceRatio</span> <span class="mf">.</span> <span class="nv">$cropParam</span> <span class="o">:</span> <span class="kc">null</span><span class="p">;</span>
<span class="p">}</span>
<span class="nv">$processedImage</span> <span class="o">=</span> <span class="nv">$this</span><span class="o">-></span><span class="n">imageService</span><span class="o">-></span><span class="nf">applyProcessingInstructions</span><span class="p">(</span><span class="nv">$imageObj</span><span class="p">,</span> <span class="nv">$processingInstructions</span><span class="p">);</span>
</code></pre></p>
<p>We than needed to make changes to the code base and ended up with the following code:<br /><pre><code class="php syntaxhl" data-language="php"><span class="nv">$cropParam</span> <span class="o">=</span> <span class="p">(</span><span class="nv">$crop</span><span class="p">)</span> <span class="o">?</span> <span class="s1">'c'</span> <span class="o">:</span> <span class="s1">''</span><span class="p">;</span>
<span class="nv">$processingInstructions</span> <span class="o">=</span> <span class="p">[</span>
<span class="s1">'width'</span> <span class="o">=></span> <span class="nv">$imageWidth</span> <span class="mf">.</span> <span class="nv">$cropParam</span><span class="p">,</span>
<span class="s1">'height'</span> <span class="o">=></span> <span class="kc">null</span><span class="p">,</span>
<span class="s1">'crop'</span> <span class="o">=></span> <span class="nv">$this</span><span class="o">-></span><span class="nf">getCropArea</span><span class="p">(</span><span class="nv">$image</span><span class="p">,</span> <span class="nv">$cropVariant</span><span class="p">),</span>
<span class="p">];</span>
<span class="k">if</span> <span class="p">(</span><span class="nv">$forceRatio</span> <span class="o">></span> <span class="mi">0</span> <span class="o">&&</span> <span class="nv">$crop</span><span class="p">)</span> <span class="p">{</span>
<span class="nv">$processingInstructions</span><span class="p">[</span><span class="s1">'height'</span><span class="p">]</span> <span class="o">=</span> <span class="p">(</span><span class="nv">$imageWidth</span> <span class="o">/</span> <span class="nv">$forceRatio</span><span class="p">)</span> <span class="mf">.</span> <span class="nv">$cropParam</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">return</span> <span class="nv">$this</span><span class="o">-></span><span class="n">imageService</span><span class="o">-></span><span class="nf">applyProcessingInstructions</span><span class="p">(</span>
<span class="nv">$image</span><span class="p">,</span>
<span class="nv">$processingInstructions</span>
<span class="p">);</span>
</code></pre></p>
<p>We didn't expect anything bad from that change. Once deployed our system went down due to heavy system load, caused by many gm (=graphics magick) processed.<br />We reverted the change and thanks to Hannes with his experience we found the root cause. We modified the <code>$processingInstructions</code> that is used to create a hash in order to find entries from database table <code>sys_file_processedfile</code>. Our modifications lead to a different array (height before, crop and height now always was set). That lead to a different hash leading to not finding processed images, leading to re-processing all images.</p>
<p>My proposal:<br />Add some streamlining to the incoming processing instructions. E.g. alphabetical sorting, array filter to filter out empty values like `null`. Something in that regard should prevent such issues for systems.<br />It forces an update wizard in order to update all existing entries with the sanitized and updated hash version in order to prevent re processing all images after system update.</p> TYPO3 Core - Bug #100893 (Resolved): Install Tool > Environment > Image Processing shows "Loading...http://forge.typo3.org/issues/1008932023-05-17T10:09:46ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Steps to reproduce:</p>
<ol>
<li>Adjust <code>$GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext']</code> to exclude some extensions, e.g. set it to <code>$GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'] = 'gif';</code></li>
<li>Open the "Image Processing" of the "Install Tool > Environment" </li>
<li>Run the checks</li>
<li>None allowed file extensions are stuck on "Loading …" instead of showing the result</li>
</ol>
<p>Expected behaviour:</p>
<p>The sections of none allowed extensions should show the AJAX response<br /><pre>
{
"status": [
{
"severity": 1,
"title": "Skipped test",
"message": "Handling format png must be enabled in TYPO3_CONF_VARS['GFX']['imagefile_ext']",
"storeInSession": false
}
]
}
</pre></p>
<p>I could reproduce the issue in v11 and v12.</p> TYPO3 Core - Bug #94710 (Under Review): Database Compare "Change fields" with SQLite shows red errorhttp://forge.typo3.org/issues/947102021-08-04T12:13:45ZDaniel Siepmanncoding@daniel-siepmann.de
<p>It doesn't work at all due to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: TypeError for SQLite in DB Compare (Closed)" href="http://forge.typo3.org/issues/94709">#94709</a>. This can be easily hotfixed.</p>
<p>I remember there was some change back during v10 to fix the behaviour to allow:</p>
<ol>
<li>select all</li>
<li>execute</li>
</ol>
<p>And repeat as often as necessary.</p>
<p>That still works but it might result in red errors which is highly user unfriendly. Also we might add an explanation how the process works? That one should just keep executing migrations (when on sqlite)</p>