TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-10-10T10:16:15ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102137 (Needs Feedback): Problems due to automatic redirectshttp://forge.typo3.org/issues/1021372023-10-10T10:16:15ZBjörn Jacobbjoern.jacob@tritum.de
<p>When you regenerate the URL segment for a page, a redirect is automatically created. This can cause redirects / a redirect loop. The editor will not notice because no warning is displayed.</p>
<ol>
<li>Scenario</li>
</ol>
<p>A possible scenario (which happens in real life and can be reproduced easily):</p>
<ul>
<li>editor copies page "X" -> new name "X1" </li>
<li>generated slug: "/x-1" </li>
<li>editor renames page "X1" to "Y" </li>
<li>generated slug: "/y" </li>
<li>auto-generated redirect: "/x-1" auf "/y" </li>
<li>editor renames page "Y" to "Z" </li>
<li>generated slug: "/z" </li>
<li>auto-generated redirect: "/y" auf "/z" </li>
<li>editor creates a new page "Y" </li>
<li>generated slug: "/y"</li>
</ul>
<ol>
<li>Result</li>
</ol>
<p>Page "Y" is not accessible because the redirect from "/y" to "/z", which was automatically generated earlier, is still active.</p>
<ol>
<li>Current solution</li>
</ol>
<p>Editor has to open the list of redirects and look for the corresponding entry. After that, the editor has to delete the redirect and everything works as expected.</p>
<p>It would be great if there could be checks installed which will warn the editor about this scenario and behaviour.</p> TYPO3 Core - Bug #97863 (New): EXT: form - do not send email notification by EmailToReceiverhttp://forge.typo3.org/issues/978632022-07-06T16:25:10ZBjörn Jacobbjoern.jacob@tritum.de
<p>Related to <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: EXT: form - do not send email notification by EmailToReceiver (Closed)" href="http://forge.typo3.org/issues/83010">#83010</a></p>
<p>I have the similiar problem with TYPO3 11, while I tried to use a form with an AJAX-request. The finisher for sending of emails would work sometimes; and sometimes it would not work. After a lot of poking around, I found out:</p>
<p>The following version in the template of the form prohibited the sending of mails in my case:</p>
<p><code><br /> <f:form.textfield<br /> value="{myLink}" <br /> name="{element.identifier}" <br /> id="{element.uniqueIdentifier}" <br /> errorClass="{element.properties.elementErrorClassAttribute}" <br /> additionalAttributes="{formvh:translateElementProperty(element: element, property: 'fluidAdditionalAttributes')}" <br /> /><br /></code></p>
<p>The following version performed the sending of mails in my case:</p>
<p><code><br /><f:form.textfield<br /> value="{myLink}" <br /> property="{element.identifier}" <br /> id="{element.uniqueIdentifier}" <br /> errorClass="{element.properties.elementErrorClassAttribute}" <br /> additionalAttributes="{formvh:translateElementProperty(element: element, property: 'fluidAdditionalAttributes')}" <br />/><br /></code></p>
<p>The line <code>property="{element.identifier}"</code> is the difference.</p> TYPO3 Core - Task #97857 (New): Deprecate inheritanceshttp://forge.typo3.org/issues/978572022-07-05T09:53:33ZBjörn Jacobbjoern.jacob@tritum.de
<p>The form framework has a concept called "inheritances". The solution is quite expensive:</p>
<ul>
<li>difficult to understand/ document/ explain</li>
<li>difficult to use</li>
<li>difficult to calculate by machines -> was the main reason to integrate caching</li>
</ul>
<p>The core itself does not use inheritances anymore. Instead, in v10 we got rid of all inheritances, applied the appropriate code snippets, restructured the form configuration and love the result. Therefore, we want to get rid of the whole concept and free brain and machine power.</p> TYPO3 Core - Task #97849 (New): Trim email adresses in form editorhttp://forge.typo3.org/issues/978492022-07-04T08:30:06ZBjörn Jacobbjoern.jacob@tritum.de
<p>The user experienced this problem: <a class="external" href="https://github.com/TYPO3-Documentation/TYPO3CMS-Exceptions/pull/69">https://github.com/TYPO3-Documentation/TYPO3CMS-Exceptions/pull/69</a></p>
<p>We want to discuss if we should trim email adresses upon saving in the form editor.</p> TYPO3 Core - Bug #97841 (Closed): Form element icon disappears in inspectorhttp://forge.typo3.org/issues/978412022-07-01T10:44:39ZBjörn Jacobbjoern.jacob@tritum.de
<p>I am having a form and some form elements. I want to change the label of one form element. While typing the icon in front of the headline disappears. See image for more details.</p>
<p><img src="http://forge.typo3.org/attachments/download/36952/image.png" alt="" loading="lazy" /></p> TYPO3 Core - Task #97839 (Closed): Extend PHP-CS-Fixer to avoid yoda stylehttp://forge.typo3.org/issues/978392022-07-01T08:35:24ZBjörn Jacobbjoern.jacob@tritum.de
<p>The PHP-CS-Fixer config should be extended to avoid yoda style. ATM, there are 18 occurrences across the core. The problem was raised while reviewing <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/74492/">https://review.typo3.org/c/Packages/TYPO3.CMS/+/74492/</a>.</p> TYPO3 Core - Bug #97836 (Closed): No pointer cursor on toggle checkboxeshttp://forge.typo3.org/issues/978362022-06-30T15:52:16ZBjörn Jacobbjoern.jacob@tritum.de
<p>In v11 and main the cursor doesn't change to a pointer when hovering over toggles (checkboxes as toggles). In current v10 it is still working.</p> TYPO3 Core - Task #97825 (Closed): Extend validator documentation for editorshttp://forge.typo3.org/issues/978252022-06-29T14:23:16ZBjörn Jacobbjoern.jacob@tritum.de
<p>ToDo</p>
<ul>
<li>proofread</li>
<li>link to form elements</li>
</ul> TYPO3 Core - Bug #97783 (New): Backport: Drop down indicator not behaving properlyhttp://forge.typo3.org/issues/977832022-06-17T12:47:50ZBjörn Jacobbjoern.jacob@tritum.de
<p>IMHO <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Drop down indicator not behaving properly (Closed)" href="http://forge.typo3.org/issues/97041">#97041</a> should be backported to v11 as well.</p> TYPO3 Core - Task #97782 (New): Extend double submit blocker examplehttp://forge.typo3.org/issues/977822022-06-17T12:35:15ZBjörn Jacobbjoern.jacob@tritum.de
<p>The example provided in <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Documentation: double submit blocker example (Closed)" href="http://forge.typo3.org/issues/95074">#95074</a> needs some love:</p>
<blockquote>
<p>But if the submit button gets disabled, the form also looses the __currentPage parameter, which is attached to the submit button and needed for submitting the form. Maybe you could update your example to a TYPO3 compatible solution? We are following an approach to extracting the __currentPage to a hidden field with JavaScript, but its still a little buggy.</p>
</blockquote>
<p>Maybe it is not only about documentation. Do we have to improve the form framework to get this one properly done?</p> TYPO3 Core - Task #97514 (New): Improve error modal: provide more informationhttp://forge.typo3.org/issues/975142022-04-29T09:16:31ZBjörn Jacobbjoern.jacob@tritum.de
<p>The error modal lists all elements which are not happily edited. Some information are missing. With the current situation you do not know which element is meant. This could be useful:</p>
<ul>
<li>Name of the element</li>
<li>Type of the element</li>
<li>Error reason</li>
</ul> TYPO3 Core - Task #97513 (New): Improve error modal: obvious clickabilityhttp://forge.typo3.org/issues/975132022-04-29T09:14:17ZBjörn Jacobbjoern.jacob@tritum.de
<p>The error modal lists all elements which are not happily edited. As an editor, I do not know that those elements can be clicked. Make it more obvious/ striking.</p> TYPO3 Core - Bug #97512 (New): Bring back validation for form element in structure treehttp://forge.typo3.org/issues/975122022-04-29T09:12:22ZBjörn Jacobbjoern.jacob@tritum.de
<p>If an error occurs for the form element, the structure tree does not reflect the problem accordingly. There used to be an exclamation mark in front of the element. Bring back this visualisation.</p> TYPO3 Core - Epic #97511 (New): Visual feedback when errors occur in form editorhttp://forge.typo3.org/issues/975112022-04-29T08:10:59ZBjörn Jacobbjoern.jacob@tritum.de
<a name="Steps-to-reproduce"></a>
<h2 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a new form called "Contact me" </li>
<li>Click on settings</li>
<li>Add the new finisher "Email to sender" </li>
<li>Do not enter any value</li>
<li>Add a new form element of type "Text" </li>
<li>Save the form</li>
</ul>
<a name="Current-behaviour"></a>
<h2 >Current behaviour<a href="#Current-behaviour" class="wiki-anchor">¶</a></h2>
<p>A modal is shown telling me to check the following elements. On a new line the name of the form "Contact me" is displayed. I have no idea what this is and don't know, what to do.</p>
<a name="Optimized-behaviour"></a>
<h2 >Optimized behaviour<a href="#Optimized-behaviour" class="wiki-anchor">¶</a></h2>
<p>My proposal is as follows:</p>
<ul>
<li>Mark the "Settings" button in the top bar red. This would be the same behaviour as for validators etc.</li>
<li>In addition to the name of the element also add the type of the element. In this case something like the name of the finisher would be displayed and not the name of the form.</li>
<li>Add an exclamation mark to the structure tree.</li>
</ul> TYPO3 Core - Task #97497 (Closed): Clearly document removal of deprecationshttp://forge.typo3.org/issues/974972022-04-28T07:46:42ZBjörn Jacobbjoern.jacob@tritum.de
<p>In the following files code has been marked as deprecated. It should be removed in 13.0 which must be clearly stated.</p>
<ul>
<li>packages\TYPO3.CMS\typo3\sysext\form\Classes\Controller
<ul>
<li>FormEditorController.php (1 usage found)
<ul>
<li>115 trigger_error('formEditor.dynamicRequireJsModules has been deprecated. Use formEditor.dynamicJavaScriptModules instead.', E_USER_DEPRECATED);</li>
<li>168 trigger_error('formEditor.dynamicRequireJsModules has been deprecated. Use formEditor.dynamicJavaScriptModules instead.', E_USER_DEPRECATED);</li>
</ul>
</li>
<li>FormManagerController.php (1 usage found)
<ul>
<li>106 trigger_error('formManager.dynamicRequireJsModules has been deprecated. Use formManager.dynamicJavaScriptModules instead.', E_USER_DEPRECATED);</li>
</ul></li>
</ul></li>
</ul>