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 - Task #86887 (New): Enable urls like `https://example.com/` and `https://example.com/...http://forge.typo3.org/issues/868872018-11-08T14:29:05ZDaniel Siepmanncoding@daniel-siepmann.de
<p>We just discussed how to configure the new URL handling within 9.5.x.</p>
<p>Our goal: Have urls like <em><a class="external" href="https://example.com/">https://example.com/</a></em> and <em><a class="external" href="https://example.com/path/to/site.html">https://example.com/path/to/site.html</a></em>, so only <em>.html</em> suffix for page type 0 if there is a path.<br /><pre>
PageTypeSuffix:
default: .html
index: ''
map:
.html: 0
type: PageType
</pre></p>
<p>I know this doesn't fit the current idea of the enhancer. The <em>index</em> is by default set to <em>index</em>, resulting in <em><a class="external" href="https://example.com/index.html">https://example.com/index.html</a></em> which I can fully understand.</p>
<p>Most websites still were configured to support the above version. I can understand that this will not work, as you can have <em>.xml: 10</em> and <em>.json: 15</em> for example. So TYPO3 does need this to be consistent. But is there a chance to add something like <em>disableSuffixForDefault: true</em>:<br /><pre>
PageTypeSuffix:
default: .html
index: ''
disableSuffixForDefault: true
map:
.html: 0
type: PageType
</pre></p>
<p>So TYPO3 will check that the default mapping will be applied, with the <em>index</em> and prevent adding anything?</p>
<p>That should solve the issue and should, hopefully, not be a big deal. If so, I'll open an issue in forge.<br />Maybe there are other solutions, but I didn't find anything else that still fits the streamlined approach.<br />Or did I oversee some approach? As there is no issue right now, we might be alone with this issue?<br />Corresponding stackoverflow entry: <a class="external" href="https://stackoverflow.com/questions/52903641/real-urls-in-typo3-9-5-0">https://stackoverflow.com/questions/52903641/real-urls-in-typo3-9-5-0</a></p> TYPO3 Core - Bug #82833 (Closed): It's not possible to replace options from FinisherVariableProvi...http://forge.typo3.org/issues/828332017-10-20T13:11:41ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Currently only strings and integers are allowed. This prevents further values like floats from being used while saving to database.</p>
<p>The following implementation prevents such use case from working:<br /><pre>
if (!is_string($value) && !is_int($value)) {
$value = '{' . $match[1] . '}';
}
</pre><br /><a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/typo3/sysext/form/Classes/Domain/Finishers/AbstractFinisher.php#L208">https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/typo3/sysext/form/Classes/Domain/Finishers/AbstractFinisher.php#L208</a></p>
<p>To reproduce, register a custom finisher that will add a float and use this in another finisher like:<br /><pre>
lat:
value: '{Geocode.result.geometry.location.lng}'
</pre></p> TYPO3 Core - Bug #76662 (Rejected): Drag and Drop in Page module for new content elements ignores...http://forge.typo3.org/issues/766622016-06-16T15:14:49ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Using the click version of the wizard works as expected. Using drag and drop ignores the configured default values. Instead the ctype is selected by the provided key, all other values are ignored completely.</p> TYPO3 Core - Bug #55642 (Closed): Page tree filter can't filter for id or title anymore.http://forge.typo3.org/issues/556422014-02-04T09:26:24ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Ernesto figured out it was <a class="external" href="https://review.typo3.org/#/c/26740/">https://review.typo3.org/#/c/26740/</a> that introduced this bug.</p>