TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-10-13T16:22:35ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102167 (Resolved): Workspace Module: Icon Overlay not being displayed in table ...http://forge.typo3.org/issues/1021672023-10-13T16:22:35ZErnesto Baschnyeb@cron.eu
<p>Until TYPO3 v11 the table of the workspace module showing the changes made to tables also reflected the status of the page with it's icon.</p>
<p>Since change <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Use native icons for workspaces element (Closed)" href="http://forge.typo3.org/issues/94977">#94977</a>, you only see the icon based on the page type, so it does not reflect anymore any status changes (i.e. from Shortcut to normal page, from hidden to non-hidden, etc).</p>
<p><strong>In TYPO3 v10:</strong><br /><img src="http://forge.typo3.org/attachments/download/38016/workspace-v10.png" loading="lazy" style="width:600px;" alt="" /></p>
<p><strong>Since TYPO3 v11:</strong><br /><img src="http://forge.typo3.org/attachments/download/38017/workspace-v11.png" loading="lazy" style="width:600px;" alt="" /></p> TYPO3 Core - Bug #100707 (New): Web>List only applies list_type restriction if this column is sho...http://forge.typo3.org/issues/1007072023-04-21T14:27:30ZErnesto Baschnyeb@cron.eu
<p>The ACL <code>explicit_allowdeny</code> allows to restrict an editor to certain plugin types (field <code>list_type</code>):</p>
<p><img src="http://forge.typo3.org/attachments/download/37635/acl-list-type.png" alt="" loading="lazy" /></p>
<p>If an admin creates a plugin of a certain list_type which is not allowed by the editor, in Web>List module the editor will still see the "controls" which would allow him to edit this content element:</p>
<p><img src="http://forge.typo3.org/attachments/download/37636/web-list-buggy.png" alt="" loading="lazy" /></p>
<p>As soon as the user also shows the column <code>list_type</code>, the permission check works and he does not see the icons anymore:</p>
<p><img src="http://forge.typo3.org/attachments/download/37637/web-list-ok.png" alt="" loading="lazy" /></p>
<p>The bug most probably came from the optimizations done in Web>List in <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/68666">https://review.typo3.org/c/Packages/TYPO3.CMS/+/68666</a> - the $row which is passed on to DatabaseRecordList::makeControl and then later to BackendUserAuthentication::recordEditAccessInternals() no longer is the full row, but just a basic version of it + the fields select by the user in the backend. So <code>list_type</code> is missing, and this auth-check is then no longer performed.</p> TYPO3 Core - Task #54511 (Closed): Travis increase PHP memory_limit to 1280mhttp://forge.typo3.org/issues/545112013-12-19T13:56:58ZErnesto Baschnyeb@cron.eu
<p>Currently travis is failing due to exploded memory_limit (>1024m). Why it takes so much needs to be investigated and is planned here: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: phpunit run in Travis: Detect and fix memory leaks (Closed)" href="http://forge.typo3.org/issues/54510">#54510</a></p>
<p>While this is not tackled, we should increase memory_limit for phpunit run a bit so that it at least works again. I.e. to 1280M.</p> TYPO3 Core - Epic #54260 (Closed): WP: FAL Missing Issues / Features / APIhttp://forge.typo3.org/issues/542602013-12-07T14:56:05ZErnesto Baschnyeb@cron.euTYPO3 Core - Feature #53941 (Closed): UX: Multi-edit records looks uglyhttp://forge.typo3.org/issues/539412013-11-25T15:34:09ZErnesto Baschnyeb@cron.eu
<p>TCEforms has the so called "multi-record-edit" view, where you can edit the same set of fields for multiple records at once.</p>
<p>This can be reached from the Web>List view and you can even select which records to edit (by using Clipboard 1 or 2) and which records to edit (by enabling them in the List-view and clicking on the header "Edit" icon.</p>
<p>Now if you select only certain fields, this editing interface looks really ugly (see attached screen typo3-multi-edit.png).</p>
<p>The UX Team also noted that. The suggested solutions are documented here:</p>
<p><a class="external" href="https://projects.invisionapp.com/share/H2IU7YVE#/screens/10259939/comments/6159748">https://projects.invisionapp.com/share/H2IU7YVE#/screens/10259939/comments/6159748</a></p>
<p>Basically:</p>
<p>a) do not use multiple "H1" headers, instead have a single H1 header on top ("Edit Page Content on page "ab") and separate smaller H2 between the elements ("Page Content "xy").</p>
<p>Note that there is no GUI for editing individual fields of multiple records that spawn across multiple sites, only by using the "Edit" icons in the Web>List view in the table headers. So in this case you can be sure that you only have the same record type and the same page.</p>
<p>b) the frame that usually surrounds TCEform editing areas is not visible. By re-adding this, it would most probably group the editing in a more intuitive way.</p> TYPO3 Core - Epic #53915 (Closed): Usability and timing issues in Pagetreehttp://forge.typo3.org/issues/539152013-11-25T00:37:06ZErnesto Baschnyeb@cron.eu
<p>The page tree has some problems when it has to deal with long running tasks:</p>
<p>- delete whole tree<br />- copy tree with lots of childs<br />- etc...</p>
<p>This umbrella-issue should try to collect these so that they can be tackled at once.</p> TYPO3 Core - Bug #53891 (Closed): Upgrade Wizard "Migrate file relations" should hide itselfhttp://forge.typo3.org/issues/538912013-11-22T21:18:22ZErnesto Baschnyeb@cron.eu
<p>If there are nothing left to migrate, the Upgrade Wizard "Migrate all file relations from tt_content.image and pages.media" should hide itself. Currently this is the only Upgrade Wizard which is always shown, and this is confusing to the user.</p> TYPO3 Core - Feature #53890 (Closed): Upgrade Wizard, first step should be Database Migrationhttp://forge.typo3.org/issues/538902013-11-22T21:13:20ZErnesto Baschnyeb@cron.eu
<p>The first "Upgrade Wizard" should be a Database Analyser step that just migrates the database to the newly added features (new fields, new tables, new indexes). No "dropping" of any field at this point (as a later upgrade Wizard might need the information in them).</p>
<p>This first Upgrade Wizard could present a list of changes that will be done and a single checkbox bellow to "accept" that changes.</p>
<p>This Wizard should "hide itself" if it detects that there are no changes required.</p> TYPO3 Core - Feature #50481 (Closed): TCEforms: Replace "More options" icon for uncollapsing pale...http://forge.typo3.org/issues/504812013-07-27T00:09:55ZErnesto Baschnyeb@cron.eu
<p>The icons to collapse and expand the Palettes ("More options") is not very usable.</p>
<p>As discussed in the UX Team #50354, we want to replace the icon with the small arrow (used also by the IRRE collapsing-feature) along with the palettes label as text (or text "More options" in case there is no label for this palette):</p>
<ul>
<li>> More options <- completely clickable</li>
</ul>
<p>As soon as it is clicked, the palette is uncollapsed and the arrow points down and the text changes to:</p>
<ul>
<li>v Less options (or the label)</li>
</ul>
<p>While doing that change, the icon should be aligned back with the field above it (move it some px to the LEFT), probably by removing the inline-style "margin-left: 20px;" and adding a new class to the TD instead.</p> TYPO3 Core - Feature #50460 (Closed): TCEforms: More spacing between horizontal optionhttp://forge.typo3.org/issues/504602013-07-26T11:56:03ZErnesto Baschnyeb@cron.eu
<p>As discussed in the UX team: #50446.</p>
<p>Add more spacing between options</p>
<p>Jens Hoffmann: label > margin-right: 25px (is currently 7px)</p> TYPO3 Core - Bug #25398 (Closed): TCEforms draws huge empty icon row which on select-fields, maki...http://forge.typo3.org/issues/253982011-03-25T20:18:25ZErnesto Baschnyeb@cron.eu
<p>Certain fields of type "select" which offer records from a "foreign_table" will contain a huge amount of t3-icon-empty icons just below the select box. If you have enough of them, you even get a horizotanl scrollbar.</p>
<p>See some screenshots here:<br /><a class="external" href="http://forge.typo3.org/issues/13422">http://forge.typo3.org/issues/13422</a></p>
<p>The issue is not a CSS issue, but a bug in the rendering of such a field.</p>
<p>See it in action in tt_content field "sys_language". Just create enough sys_language records so that you see the row of empty icons being created. This wasn't this way before.</p>
<p>(issue imported from #M18041)</p> TYPO3 Core - Feature #25123 (Closed): Upgrade Wizard: "Show database queries performed" checkbox ...http://forge.typo3.org/issues/251232011-02-21T21:57:55ZErnesto Baschnyeb@cron.eu
<p>Every Wizard presents the checkbox " Show database queries performed" even if the particular step has nothing to do with the database.</p>
<p>So we need to allow a wizard to inform the Install Tool to not render this checkbox if it doesn't make sense.</p>
<p>(issue imported from #M17698)</p> TYPO3 Core - Bug #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</p> TYPO3 Core - Epic #24849 (Closed): Upgrade Wizard Usabilityhttp://forge.typo3.org/issues/248492011-01-27T11:06:34ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard of TYPO3 still lacks a better usability.</p>
<p>This is an umbrella-issue to collect the issues which we should solve in future TYPO3 versions.</p>
<p>Please add other issues which describe bugs, issues and problems with the Upgrade Wizard as a <strong>child</strong> of this issue. Thanks!</p>
<p>(issue imported from #M17353)</p> TYPO3 Core - Bug #15510 (Closed): UTF-8 sites display garbled chars in select-fields (in BE)http://forge.typo3.org/issues/155102006-01-26T16:50:33ZErnesto Baschnyeb@cron.eu
<p>Steps to reproduce (TCEforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)<br />3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.<br />4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string</p>
<p>Other place where it occurs (flexforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Add tt_news extension<br />3) Create a News Category called "ÖÖÖ" <br />4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".<br />5) Save and look at the displayed value in the left category box, its garbled again.</p>
<p>The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.</p>
<p>The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.</p>
<p>There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.</p>
<p>Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.</p>
<p>Initially reported for TYPO3 4.0<br />(issue imported from #M2396)</p>