TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-02-22T11:52:58ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103177 (New): Inconsistent behavior in MathUtility::canBeInterpretedAsInteger()...http://forge.typo3.org/issues/1031772024-02-22T11:52:58ZMathias Brodalambrodala@pagemachine.de
<p>The behavior of <code>MathUtility::canBeInterpretedAsInteger()</code> is inconsistent:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre>
<p>Assuming that the common <code>true</code> = <code>1</code>, <code>false</code> = <code>0</code> logic applies, the behavior should be fixed to accept both boolean values. Both can be coerced into integers and thus interpreted a such:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // true
</pre>
<p>Alternatively both boolean values should be rejected for consistency:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // false
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre> TYPO3 Core - Feature #103072 (New): Manage translation DB fieldshttp://forge.typo3.org/issues/1030722024-02-07T10:59:45ZMathias Brodalambrodala@pagemachine.de
<p>Currently the TCA of TYPO3 knows these <code>ctrl</code> options to enable and manage translation behavior for tables:</p>
<p>- <code>languageField</code> (<code>sys_language_uid</code> by convention)<br />- <code>transOrigPointerField</code> (<code>l10n_parent</code> by convention, <code>l18n_parent</code> in <code>tt_content</code>)<br />- <code>translationSource</code>(<code>l10n_source</code> by convention)<br />- <code>transOrigDiffSourceField</code> (<code>l10n_diffsource</code> by convention, <code>l18n_diffsource</code> in <code>tt_content</code>)</p>
<p>Each of these have 2 purposes:</p>
<p>1. Enable translations or a related feature<br />2. Tell TYPO3 which DB field to use in queries</p>
<p>This by itself is a problem but the main question is whether the names of these DB fields need to be configurable at all.</p>
<p>There are recently a lot of consolidations and simplifications in TCA. The same could be applied here:</p>
<p>- Turn these options from <code>string</code> to <code>bool</code>, thus only enable/disable the feature. TYPO3 would then use fixed DB field names and thus fully manage these.<br />- Consolidate/merge these options with better and clearer names, e.g. <code>'enableTranslations' => true</code>, <code>'trackTranslationDifferences' => true</code> or similar.</p> TYPO3 Core - Bug #95272 (New): Redirect after page slug change ignores TCA defaultshttp://forge.typo3.org/issues/952722021-09-20T07:22:11ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Auto-create Redirects on Slug Changes (Closed)" href="http://forge.typo3.org/issues/89115">#89115</a> automatic redirects after page slug changes have been added.</p>
<p>However, these redirects are created using lowlevel DB API calls instead of the <code>DataHandler</code> and thus to not take TCA defaults into account.</p> TYPO3 Core - Feature #89762 (New): Add pagination to forms listhttp://forge.typo3.org/issues/897622019-11-24T12:17:48ZMathias Brodalambrodala@pagemachine.de
<p>There should be a pagination in the forms list to not have the module die on long form lists or folders with many files. As a side effect management for editors will be simpler since long lists are barely manageable.</p>
<p>Before this <a class="issue tracker-2 status-8 priority-4 priority-default child" title="Feature: Show storage list for selection (Under Review)" href="http://forge.typo3.org/issues/89760">#89760</a> should be done since currently all forms are loaded into a single list after loading them from all storage folders which would make a pagination pointless.</p> TYPO3 Core - Task #89761 (New): Optimize form listinghttp://forge.typo3.org/issues/897612019-11-24T12:15:43ZMathias Brodalambrodala@pagemachine.de
<p>Currently forms are retrieved as follows in exactly this order:</p>
<ol>
<li>Traverse all configured storage folders</li>
<li>Collect all <code>*.yaml</code> files in a folder</li>
<li>Read the full content of each <code>*.yaml</code> file</li>
<li>Determine if the content looks like a form definition</li>
<li>Skip anything which does not end with <code>.form.yaml</code></li>
</ol>
<p>There is clearly room to improve on each step and especially the order could be changed to have simple filters (like for <code>.form.yaml</code>) executed early using custom FAL filters.</p> TYPO3 Core - Epic #89759 (New): Performance improvements in Forms modulehttp://forge.typo3.org/issues/897592019-11-24T12:08:23ZMathias Brodalambrodala@pagemachine.deTYPO3 Core - Epic #89731 (New): Configuration streamlininghttp://forge.typo3.org/issues/897312019-11-21T18:55:56ZMathias Brodalambrodala@pagemachine.deTYPO3 Core - Feature #89417 (New): Snippets/components in form definitionshttp://forge.typo3.org/issues/894172019-10-15T09:58:57ZMathias Brodalambrodala@pagemachine.de
<p>It would be useful if the Form framework did support snippets/components. These could then be referenced in a regular form definition and would be inserted on the fly as soon as the form is built.</p>
<p>Obviously some kind of parameter support would be necessary here to make it easy to e.g. set the name for a form field provided by a snippet.</p>
<p>Maybe this could be achieved with <a class="issue tracker-2 status-5 priority-4 priority-default closed child parent" title="Feature: Support "imports" within forms form definition files (Closed)" href="http://forge.typo3.org/issues/84204">#84204</a> and YAML anchors/references.</p> TYPO3 Core - Bug #87667 (New): Replacements not applied for existing slughttp://forge.typo3.org/issues/876672019-02-06T14:41:41ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Using slash in slug in extension record throws exception in frontend (Closed)" href="http://forge.typo3.org/issues/86740">#86740</a> one can define <code>replacments</code> for <code>slug</code> fields, e.g. to get rid of slashes.</p>
<p>However, these are not applied for existing or predefined slugs, e.g. when creating pages through the <code>DataHandler</code>.</p>
<p>All <code>replacements</code> must be applied upon sanitation, no matter the source of the slug.</p> TYPO3 Core - Bug #87328 (New): "Make new translation of this page" can create invalid page transl...http://forge.typo3.org/issues/873282019-01-04T14:05:41ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: BE page module => 'Make new translation of this page' doesn't use command localize to create tran... (Closed)" href="http://forge.typo3.org/issues/81345">#81345</a> the <strong>Make new translation of this page</strong> feature within the page module directly creates localizations instead of opening the edit view for page translations.</p>
<p>This can lead to invalid page translations if e.g. the <code>title</code> has been configured to be empty in translations (unset <code>l10n_mode</code>) and thus must be filled by editors explicitly. In this case the edit view is shown correctly with errors after localization but one can simply close the view without additional prompt or action. After this the translation exists without title which in itself can lead to further issues. When trying to save instead a proper dialog is shown mentioning the invalid fields.</p> TYPO3 Core - Feature #83175 (New): Add option to disable "Move page" prompthttp://forge.typo3.org/issues/831752017-11-30T15:04:43ZMathias Brodalambrodala@pagemachine.de
<p>The new page tree shows a modal prompt when a page was moved to ask for Move, Copy or Cancel.</p>
<p>Since this slows down editing workflows considerably there should be an option to disable this and default to move and copy when pressing the Ctrl key during drag-and-drop.</p>
<p>Cancelling everything via the Esc key during drag would be the icing on the cake. ;-)</p> TYPO3 Core - Bug #82790 (New): Finisher FormEngine definition fails with nested optionshttp://forge.typo3.org/issues/827902017-10-17T16:48:25ZMathias Brodalambrodala@pagemachine.de
<p>If a finisher is configured by nested options (similar to <code>elements</code> or <code>databaseColumnMappings</code> of the <code>SaveToDatabase</code> finisher), an error will occur while the FlexForm of a form plugin is being built. This causes the option in question and all other following options to be skipped entirely.</p>
<p>This is caused by e.g. <code>option.nestedKey</code> being looked up in <code>TYPO3.CMS.Form.prototypes.standard.finishersDefinition.MyFinisher.FormEngine.elements</code> which causes <code>ArrayUtility::getValueByPath()</code> to throw an exception. Due to this, no element configuration is found and the option is skipped.</p>
<p>As a workaround I have set the relevant options to empty values in my form definition.</p> TYPO3 Core - Feature #82019 (New): Accept array instead of CSV in TCAhttp://forge.typo3.org/issues/820192017-08-01T14:14:26ZMathias Brodalambrodala@pagemachine.de
<p>There are various locations in TCA which require a CSV string of values, e.g. <code>ctrl/searchFields</code> or <code>types/N/showitem</code>.</p>
<p>To make it easer to handle this e.g. in Git one can use a multi-line string or the <code>implode()</code> function to convert an array of strings back to an CSV string.</p>
<p>Arrays of strings should be supported natively here to streamline TCA config.</p> TYPO3 Core - Bug #59822 (New): Same action called on property mapping errors with view.pluginName...http://forge.typo3.org/issues/598222014-06-23T17:17:00ZMathias Brodalambrodala@pagemachine.de
<p>With <code>plugin.tx_<myext>.view.pluginNamespace</code> one can have all plugins of an extension share the same prefix for form data, e.g. for having multiple plugins affect the same object.</p>
<p>However, if property mapping errors occur in this setup, all plugins show the same output (of the last plugin).</p>
<p>This error occurs due to the internal argument <code>__referrer</code> having the same prefix for all plugins, thus the last one prevails and all actions are redirected to this referring request.</p> TYPO3 Core - Bug #56812 (New): TCA fields without positioning added to last tab, not "Extended" tabhttp://forge.typo3.org/issues/568122014-03-12T12:59:26ZMathias Brodalambrodala@pagemachine.de
<p>TCA fields added via <code>ExtensionManagementUtility::addToAllTCAtypes</code> are appended to the <code>showitem</code> list of all types if no explicit positioning (e.g. <code>after:title</code>) has been requested.</p>
<p>By default this appends the fields to the "Extended" tab which is present by default and ready to receive all fields which are simply appended.</p>
<p>However, if one adds a new tab via <code>--div--</code> without explicit positioning with some fields, all unrelated fields without explicit positioning are now appended to this tab instead. The resulting <code>showitem</code> portion which makes the issue clear:</p>
<blockquote>
<p>--div--;LLL:EXT:cms/locallang_ttc.xlf:tabs.extended, --div--;LLL:EXT:myext/locallang_db.xml:mytab, tx_myext_myfield;;;;1-1-1, unrelated_field</p>
</blockquote>
<p>The new tab with the field <code>tx_myext_myfield</code> was simply appended to the <code>showitem</code> list, thus preventing the "Extended" tab from being the last. The <code>unrelated_field</code> is now placed in the new tab.</p>
<p>A temporary fix is to set a explicit position for the newly added tab; this ensures that the tab and its fields are not simply appended and leaves the "Extended" tab on the last position.</p>
<p>The real fix however would involve explicitely placing all fields without explicit positioning in the "Extended" tab. This way arbitrary tabs could be appended without unrelated fields showing up in them.</p>
<p>This issue affects all TYPO3 CMS versions.</p>