TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-02-05T14:27:44ZTYPO3 Forge
Redmine 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 #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 - Feature #98590 (New): Show allowed CType of user in "Backend user details" viewhttp://forge.typo3.org/issues/985902022-10-12T14:12:07ZDaniel Siepmanncoding@daniel-siepmann.de
<p>TYPO3 has a feature to show the details of a backend user. One needs to open the "Backend Users" module. There you can click on the icon "Show details" of a user to enter the "Backend user details" view.</p>
<p>There you can see "Page types" allowed for the user, but allowed CTypes are missing. Would be cool to see them as well.</p>
<p>Andreas checked old 4.5 and found out the info was there, see attached screenshot.</p> TYPO3 Core - Task #96729 (Accepted): Auto generate database index "language"http://forge.typo3.org/issues/967292022-02-02T12:08:58ZDaniel Siepmanncoding@daniel-siepmann.de
<p>TYPO3 auto generates database columns from TCA configuration.<br />A typical use case is to have the two columns <code>l10n_parent</code> and <code>sys_language_uid</code>. Some core tables like tt_content create a language index based on these two fields (within its <code>ext_tables.sql</code> ).</p>
<p>Those columns are auto generated, while the index is not. The developer needs to define the index inside ext_tables.sql.</p>
<p>TYPO3 list modules queries translations which slows down the module if a huge amount of records exists in total. The index removes the performance issue.</p>
<p>Therefore it would be cool to auto generate the index if both fields (TCA: <code>languageField</code> and <code>transOrigPointerField</code> ) are configured.</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> TYPO3 Core - Bug #93532 (New): Localize of group breaks referenced record uidhttp://forge.typo3.org/issues/935322021-02-17T13:28:58ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Setup to reproduce:</p>
<ol>
<li>Create some kind of record with uid 1.</li>
<li>Create a content element with uid 1 in default language.</li>
<li>Use CType "shortcut" and select the foreign record with uid 1.</li>
<li>Create a foreign language</li>
<li>Translate the page with content element.</li>
<li>Translate the content of the page.</li>
</ol>
<p>Expected result: A new content element with uid 2 should be created. "records" field should contain <em>1</em>.<br />Actual result: A new content element with uid 2 is created. "records" field contains <em>2</em>.</p>
<p>The DataHandler actually tries to update references. If the field "records" includes references to the same uid as the language parent, then those uids are updated to the new uid. This happens within <em>DataHandler->remapListedDBRecords()</em></p> TYPO3 Core - Feature #92705 (New): Provide API for developers to adjust registered Extbase plugins http://forge.typo3.org/issues/927052020-10-26T11:52:16ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Right now it is only possible to re configure a plugin by calling <em>\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin</em> a 2nd time.<br />Also in order to change the default Controller-Action-Combination one needs to unset <em>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['extbase']['extensions']['ExtensionName']['plugins']['PluginName']</em> upfront.</p>
<p>That is very clunky and a clean API to configure and reconfigure a plugin would be much better.<br />Also Extbase could use a clean API in order to retrieve those info, instead of accessing a <em>TYPO3_CONF_VARS</em> array.</p>
<p>The new API should also only be intended for use within <em>ext_localconf.php</em>, not during runtime.</p> TYPO3 Core - Bug #92406 (New): Using formvh:render without extbase context results in Exceptionhttp://forge.typo3.org/issues/924062020-09-25T11:17:20ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Using <pre><formvh:render persistenceIdentifier="EXT:sitepackage/Resources/Private/Forms/enquiry.form.yaml" /></pre> inside an arbitrary Fluid template results in <pre>Argument 1 passed to TYPO3\CMS\Extbase\Service\ExtensionService::getPluginNameByAction() must be of the type string, null given, called in /var/www/html/public/typo3/sysext/extbase/Classes/Mvc/Web/Routing/UriBuilder.php on line 609</pre>. It looks like the reason is <pre>$form = $formDefinition->bind($renderingContext->getControllerContext()->getRequest(), $response);</pre> inside the ViewHelper.</p>
<p>I guess it should be possible to detect the state, and create a fake request with the expected defaults to the EXT:form plugin itself to make it way easier. Alternatively one could set the necessary info through additional arguments. Just like in the example when using FLUIDTEMPLATE: <a class="external" href="https://docs.typo3.org/c/typo3/cms-form/10.4/en-us/I/Concepts/FrontendRendering/Index.html#render-through-fluidtemplate-without-controller">https://docs.typo3.org/c/typo3/cms-form/10.4/en-us/I/Concepts/FrontendRendering/Index.html#render-through-fluidtemplate-without-controller</a></p>
<p>It would make usage of EXT:form much easier if that would work out of the box.</p> TYPO3 Core - Bug #91508 (New): It is not possible to save "negative" dates, e.g. a year before je...http://forge.typo3.org/issues/915082020-05-27T16:29:27ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Example setup to reproduce:</p>
<p>1. raise storage for field:</p>
<pre>
CREATE TABLE tt_content (
starttime bigint,
);
</pre>
<p>2. Select an date before year 0.<br />3. Save<br />4. You'll see the same year but after 0, not before 0.</p>
<p>The same happens when changing the setup of the field:<br /><pre>
$GLOBALS['TCA']['tt_content']['columns']['starttime'] = [
'exclude' => 0,
'label' => 'Some year',
'config' => [
'type' => 'input',
'renderType' => 'inputDateTime',
'eval' => 'date, int, required',
],
];
</pre></p> TYPO3 Core - Feature #90514 (Closed): Dashboard displaying top most executed redirectshttp://forge.typo3.org/issues/905142020-02-24T08:17:59ZDaniel Siepmanncoding@daniel-siepmann.de
<p>TYPO3 allows to toggle counting of triggered redirects.<br />A widget displaying the top most redirects (doughnut graph) would allow people to decide to replace redirects. E.g. if you copied old content into an "archive" section, you might want to migrate that old content if there are a lot of redirects.</p>
<p>If you think that one should not go into TYPO3 core, that would also be ok. But that one would also combine multiple features and make them more accessible.</p> TYPO3 Core - Feature #90443 (New): Idea for dashboard at initial installation of new TYPO3http://forge.typo3.org/issues/904432020-02-19T20:20:13ZDaniel Siepmanncoding@daniel-siepmann.de
<p>It would be cool to add a new dashboard to the first user after a TYPO3 installation was successful.<br />That dashboard could carry all necessary information to get started. Would make also sense to make it the default module instead of the "About".</p>
<p>That way new users that setup a TYPO3 installation get an "Introduction Dashboard" with all information to get deeper into the system.<br />Also static texts like "Next Steps" could be added.</p>
<p>That might improve the user experience for first time users.</p> TYPO3 Core - Bug #85456 (New): columnsOverrides not possible for type grouphttp://forge.typo3.org/issues/854562018-07-02T17:38:34ZDaniel Siepmanncoding@daniel-siepmann.de
<p>It's not possible to overwrite configuration of columns of type group via <em>columnsOverrides</em>.<br />It partially works, but not for the data source.</p>
<p>Due to configuration in <em>formEngine.formDataGroup.tcaDatabaseRecord</em> the order is wrong.</p>
<p><em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaColumnsOverrides::class</em> is called after <em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaGroup::class</em>.<br />While it would be easy to adjust order, it's in fact not. <em>TcaColumnsOverrides</em> does need <em>\TYPO3\CMS\Backend\Form\FormDataProvider\DatabaseRecordTypeValue</em> which in turn needs <em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaGroup::class</em> again.</p>
<p>This way one can not re-use the <em>records</em> column of <em>tt_content</em> for any other record. While it works while selecting entries, it does not work either for suggest nor for re-display in backend. As always the original <em>tt_content</em> records are fetched for persisted IDs.</p>