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 #103060 (Under Review): ViewHelper won't work with link modificationshttp://forge.typo3.org/issues/1030602024-02-06T10:26:57ZDaniel Siepmanncoding@daniel-siepmann.de
<p>TYPO3 delivers some ViewHelper for link generation.<br />Those accept arguments like class.</p>
<p>TYPO3 itself, and extensions via Events, might add their own arguments, e.g. rel="noreferrer".</p>
<p>This will break as ViewHelper don't provide their own downstream to the link generation. But ViewHelpers fetch the result from the generation and overwrite their own info.</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 - Task #102836 (Resolved): Make JavaScript method FilesControlContainer::deleteRecord(...http://forge.typo3.org/issues/1028362024-01-15T10:42:33ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The mentioned method is private right now.<br />It is a callback when deleting inline elements via a button click.<br />But it is possible to add custom controls via PSR-14 Events.</p>
<p>We now have an event that should "update" an inline element, e.g. a sys_file_reference. The customer has a naming schema which increases a number at the end. We now have a control to update based on that schema.<br />We therefore need to remove the existing element and insert a new one.</p>
<p>We strived for an alternative using typo3:foreignRelation:insert but it respects max items and doesn't provide a replace way. We therefore first need to remove the old child prior adding the new one. We therefore need the deleteRecord() method to be publicly available.</p> 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 #102750 (Closed): addRecord pid ###SITE:<KEY>.<SUBKEY>### does not workhttp://forge.typo3.org/issues/1027502024-01-04T12:22:13ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The documentation <a class="external" href="https://docs.typo3.org/m/typo3/reference-tca/12.4/en-us/ColumnsConfig/CommonProperties/FieldControl/AddRecord.html#confval-options-pid">https://docs.typo3.org/m/typo3/reference-tca/12.4/en-us/ColumnsConfig/CommonProperties/FieldControl/AddRecord.html#confval-options-pid</a> says one should check out <a class="external" href="https://docs.typo3.org/m/typo3/reference-tca/12.4/en-us/ColumnsConfig/Type/Select/Properties/ForeignTableWhere.html#field-quoting">https://docs.typo3.org/m/typo3/reference-tca/12.4/en-us/ColumnsConfig/Type/Select/Properties/ForeignTableWhere.html#field-quoting</a> which offers <pre>###SITE:<KEY>.<SUBKEY>###</pre> which is not resolved right now. It is passed to Classes/Controller/Wizard/AddController.php which doesn't resolve the marker.</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>