TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-15T17:07:32ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103407 (Resolved): Call to a member function getAttribute() on null (in Content...http://forge.typo3.org/issues/1034072024-03-15T17:07:32ZOliver BartschTYPO3 Core - Bug #102389 (New): Content element are not displayed in defLangBinding mode if free ...http://forge.typo3.org/issues/1023892023-11-16T20:43:04ZOliver Bartsch
<p>Given a backend layout with a couple of columns. Being in the page module (language comparison mode) with defLangBinding active,<br />content elements in columns, where no elements exist in the default language, are not displayed. The reason seems to be: <a class="external" href="https://github.com/TYPO3/typo3/blob/2116f3d3f42604440db499af21c8eec60d2026e7/typo3/sysext/backend/Resources/Private/Partials/PageLayout/LanguageColumns.html#L78">https://github.com/TYPO3/typo3/blob/2116f3d3f42604440db499af21c8eec60d2026e7/typo3/sysext/backend/Resources/Private/Partials/PageLayout/LanguageColumns.html#L78</a></p> TYPO3 Core - Feature #99979 (New): Allow "columns only" editing for sys_file_metadata in FileList http://forge.typo3.org/issues/999792023-02-17T10:40:17ZOliver Bartsch
<p>Since the introduction of the multi record selection and the "show columns" selector in the FileList module, it's possible to edit the metadata of multiple files at once. To further improve this, the FileList should also provide the "columns only" option - like available in the List module - to render FormEngine with only a subset of fields. Either all currently displayed or a single field, depending on the record selection and field selection.</p>
<p>For reference, display in list module:</p>
<p><img src="http://forge.typo3.org/attachments/download/37425/columns-only.png" alt="" loading="lazy" /></p> TYPO3 Core - Bug #97038 (Accepted): Do not persist automatic fallback in page modulehttp://forge.typo3.org/issues/970382022-02-25T10:28:03ZOliver Bartsch
<p>The page module allows to switch between languages as well as between the "Columns" and "Languages" mode.</p>
<p>However the available possibilities, e.g. the special -1 option ("All languages") depends on the selected page and site. For example, in a single-language site, the -1 option won't be available.</p>
<p>Therefore, the page module evaluates the currently stored options for the user when accessing any page in the page module and automatically falls back to defaults, on invalid options. This automatic fallback should however not be persisted since this breakes workflows. It's just sufficient to resolve invalid options on the fly .</p> TYPO3 Core - Feature #95907 (New): Wizard to recalculate image sizeshttp://forge.typo3.org/issues/959072021-11-08T11:38:40ZOliver Bartsch
<p>In case crop variants (TCA) are adjusted, currently all images need to be recalculated manually. This should be improved by adding e.g. a wizard for this task.</p>
<pre>
Imported from t3mc session "Zap the gremlins"
</pre> TYPO3 Core - Task #95906 (Needs Feedback): Improve f:image ViewHelperhttp://forge.typo3.org/issues/959062021-11-08T11:36:35ZOliver Bartsch
<p>Currently, the <code>f:image</code> ViewHelper throws an exception in case a referenced image can not be found. For local development, it's therefore required to clone the remote fileadmin. This should be improved by adding the possibility to define a fallback image, which is displayed, in case the referenced image can not be found on the system.</p>
<pre>
Imported from t3mc session "Zap the gremlins"
</pre> TYPO3 Core - Feature #95905 (Needs Feedback): Implement a "proxy" for fileadminhttp://forge.typo3.org/issues/959052021-11-08T11:18:05ZOliver Bartsch
<p>Instead of keeping a local copy of the fileadmin in sync, a "proxy" should be available to easily use the remote assets locally. See for example EXT:filefill.</p>
<pre>
Imported from t3mc session "Zap the gremlins"
</pre> TYPO3 Core - Epic #95904 (Under Review): Make backend user and user groups deployablehttp://forge.typo3.org/issues/959042021-11-08T11:15:51ZOliver Bartsch
<p>This issue was raised during the T3MC session "Zap the gremlins".</p>
<p>The issue has been discussed in April 2022 in the #typo3-cms-coredev channel (<a class="external" href="https://typo3.slack.com/archives/C03AM9R17/p1650369198186799">https://typo3.slack.com/archives/C03AM9R17/p1650369198186799</a>). The following is the result of the discussion.</p>
<a name="General-requirements"></a>
<h2 >General requirements<a href="#General-requirements" class="wiki-anchor">¶</a></h2>
<ul>
<li>preferred format: YAML
* core uses it already
* can be commented</li>
<li>definitions can be shipped with extensions</li>
<li>the functionality can be compared with the handling of Site configuration
* Site configuration (still) has implicit dependencies on UID values in `rootPageId` and `limitToPages` (for route enhancers)
* replacing those UIDs by distinct / universally-unique seems to be a good way to go</li>
<li>events should be provided
* as with the Site configuration
* allows extension authors to hang in there dynamically before / after the cache building</li>
<li>overwriting / modification should be simple
* it is a no-brainer to inherit the default "news editor" and remove some fields or add another backend module</li>
<li>error handling
* handle defined but missing relations to groups and mounts</li>
</ul>
<a name="User-Groups"></a>
<h2 >User Groups<a href="#User-Groups" class="wiki-anchor">¶</a></h2>
<ul>
<li>groups should be understood as roles, e.g. "news editor" </li>
<li>a role
* includes corresponding permissions (= contains the access control)
* should be assigned to a group (= collection of roles)</li>
<li>a group
* will be assigned to a user
* contains the DB and file mounts</li>
<li>be_groups needs an additional string identifier to avoid relying on autoincrement IDs</li>
<li>we recommend a human readable string identifier which helps to handle those definitions</li>
</ul>
<a name="Problems-to-be-discussed"></a>
<h3 >Problems to be discussed<a href="#Problems-to-be-discussed" class="wiki-anchor">¶</a></h3>
<ul>
<li>using string identifiers do not guarantee uniqueness -> having a UUID could solve the problem but causes additional work on datahandler (which considers everything not a UID to be a new record placeholder, if it starts with NEW)</li>
</ul>
<a name="Users"></a>
<h2 >Users<a href="#Users" class="wiki-anchor">¶</a></h2>
<ul>
<li>handling of one or more user records</li>
</ul>
<a name="Problems-to-be-discussed-2"></a>
<h3 >Problems to be discussed<a href="#Problems-to-be-discussed-2" class="wiki-anchor">¶</a></h3>
<ul>
<li>handling of sensitive data (passwordl, name, email address)</li>
</ul>
<p>Handling user groups would solve a big problem and would be a huge improvement. The import and export of users is rather complex, the value small.</p>
There are some <strong>solutions</strong> already out there:
<ul>
<li><a class="external" href="https://packagist.org/packages/maxserv/yaml_configuration">https://packagist.org/packages/maxserv/yaml_configuration</a></li>
<li>Benni Mack might have a PoC somewhere :)</li>
</ul> TYPO3 Core - Task #92468 (New): Use meaningful (real-world) values in ViewHelper exampleshttp://forge.typo3.org/issues/924682020-10-01T23:49:51ZOliver Bartsch
<p>A lot of ViewHelpers e.g. <code>TYPO3\CMS\Backend\ViewHelpers\Link\NewRecordViewHelper</code> contain examples how to use them in their PHPDoc. However, most of the examples just use dummy values such as <code>a_table</code> or <code>foo_value</code>. To make the examples more useful and easier to understand, they should use meaningful (real-world) values.</p> TYPO3 Core - Bug #92458 (New): Creating the "same" record in live and draft workspace led to misb...http://forge.typo3.org/issues/924582020-10-01T12:06:32ZOliver Bartsch
<p>Given you have two site languages (Default L=0 and Translation L=1) and the page is translated in L=1.</p>
<ol>
<li>Create a new content element in L=0</li>
<li>Switch in Workspace Draft and translate the newly created record (1.) in L=1 (Don't publish)</li>
<li>Switch back to Live and translate the newly created record (1.) in L=1</li>
<li>recordlist now displays the created live record (3.)</li>
<li>Switch back in Workspace Draft and publish the translated record (2.)</li>
<li>Switch back to Live</li>
<li>Now the record (2.) is displayed in recordlist although we created the translation already (3.)</li>
<li>Switch back in Workspace Draft and remove the record from (2.)</li>
<li>Live record (3.) is displayed again</li>
</ol>
<p>Doing the same in page module results in having two translations for the default record in connected mode.</p> TYPO3 Core - Feature #92440 (New): Allow selecting the source language for all record types not j...http://forge.typo3.org/issues/924402020-09-29T09:35:24ZOliver Bartsch
<p>It's already possible to select a source language for a new tt_content localization.</p>
<p>Having a setup like EN (default 0), DE (1), ES (2) one can translate content in ES and select DE as source language. This does however not work for other/custom record types, at least not in the Backend (Recordlist GUI).</p>
<pre>
Imported from T3cm 2020 (https://notes.typo3.org/s/WpKeyLuYr)
</pre> TYPO3 Core - Feature #92434 (New): Make relations available in fluid templates for content elemen...http://forge.typo3.org/issues/924342020-09-28T10:13:56ZOliver Bartsch
<p>With v10 the new fluid based page module was introduced. It's now possible to directly add custom fluid templates<br />for the content element preview. To increase the value of this, the resolved records (especially for m:m fields) should be available in the fluid templates to reduce the need for ViewHelpers.</p>
<pre>
Imported from T3cm 2020 (https://notes.typo3.org/s/WpKeyLuYr)
</pre> TYPO3 Core - Feature #89582 (New): Introduce translated page treehttp://forge.typo3.org/issues/895822019-11-05T08:52:13ZOliver Bartsch
<p><strong>Motivation</strong><br />Currently there is being some work for improving the accessibility of page tree done.<br />See e.g.: <a class="external" href="https://forge.typo3.org/issues/86818">https://forge.typo3.org/issues/86818</a>. This is therefore a great opportunity to jump on this train and continue this process.</p>
<p>There are already several issues in the board, which partially are almost six or more years old.<br />All these issues describe more or less the possibility to have a translated page tree.</p>
<p>This issue aims to summarize this requests and bundles them to have a good basis for further discussions and considerations.</p>
All this requests are based on several drawbacks, the page tree is facing currently:
<ul>
<li>A TYPO3 editor isn’t always fluent in the default language which is used for the page tree and therefore the page tree is just useless for him.<br />Expect the general page structure.</li>
<li>The page tree live search only considers the default page records (this applies for either searching for title and also for uid).<br />So it’s currently not possible to filter for localized page records.</li>
<li>To get the position of a localized page record in the page tree, one has to find it through the top bar navigation,<br />switch to the default record in e.g. the edit view, copy the uid and afterwards search in the page tree search for the default one.<br />Only after these steps he is able to edit the localized page record.</li>
</ul>
<p><ins>Site note:</ins> To improve the readability I’ll always use the term „language“. But keep in mind that it can actually also be a localization,<br />because one can add `sys_language` for DE_CH as well as DE_AT.</p>
<p><strong>Solution (general)</strong><br />Introduction of a selection (select box) at the top of the page tree (next to the search / filter) buttons to enable each backend user to select his preferred language.<br />Obviously in which he is fluent.</p>
<p>This selection should certainly be saved to backend users UC settings. He shouldn’t need to select it again after each login.</p>
<p>The select box will only be displayed if there is at least one `sys_language` record defined.<br />Furthermore only languages the backend user has proper access rights are displayed in the select box.</p>
<strong>Additional</strong>
<ul>
<li>Really obvious but it needs to be defined: Default will be always the default language till a backend user adjusts it by selecting another one.<br />Or another default is set via UserTSConfig.</li>
<li>The context menu in the page tree refers to the page record in the selected language.<br />This means, if a backend user has selected “German” and afterwards hides the page record in the context menu, the “German” record gets hidden.</li>
<li>Searching / Filtering the page tree will always consider the currently selected language + default records which are not yet translated (See „necessary consideration“ for the reasons).</li>
<li>Changing the page tree language while searching / filtering is active, the page tree will reload with the „new“ page tree in the selected language and after that also applies the filtering to it.</li>
<li>A UserTSConfig option will be introduced which allows disabling the language selector for user (groups).</li>
<li>A UserTSConfig option will be introduced which allows setting a default page tree language for user (groups).</li>
</ul>
<p><strong>Necessary considerations</strong><br />What happens if the page is not fully translated/localized in the selected language? <br />More specific: What happens when just a parent page is not translated/localized but the child pages are? <br />A possible solution would be to show the default ones in this case. Furthermore the page title should be in brackets<br />to give the backend user directly information about this record is yet not translated.<br />By editing the page title (returning the default title including the brackets) a new localized record will be created.<br />This possibility should be made public to the backend user via e.g. a tooltip by hovering over the default record.</p>
<p><strong>Step 2 features (TBD)</strong><br />If the page tree language was switched, hovering over a record should display a tooltip containing the uid and title of the default record.</p> TYPO3 Core - Feature #89524 (New): Allow searching for localized pages in the page tree live searchhttp://forge.typo3.org/issues/895242019-10-28T12:59:02ZOliver Bartsch
<p>Currently it's not possible to search for localized pages in the page tree live search.</p>
<p>Only if you enter a UID or a page title of the default record, the page is shown.</p>
<p>There are some frequently appearing use cases which would require to be able to also search for localized pages.</p>
<p>For example an editor which is just responsibly for one localization and isn't fluent with the default language (e.g. default is German and the editor is responsibly for France).<br />Furthermore, if e.g. a customer creates a ticket and just tells the UID of the localized page. Now one have to search for it but currently have to know the UID of the default record to find it. The same applies to the page records title.</p>
<p>I'm aware that it is possible to find localized page records throug the top navigation search. But by using this search you always end up in the edit form of the page or in the list view which isn't a valid UX if you want to get to the page in the page module, because you e.g. want to create/edit/delete new content elements on it.</p>
<p>Therefore, like the issue title already says, it would be a real benefit to allow searching also for localized page records by UID and title in the page tree live search.</p> TYPO3 Core - Bug #89070 (New): Positioning of FormEngine fields should be improvedhttp://forge.typo3.org/issues/890702019-09-03T17:29:35ZOliver Bartsch
<p>For some scenarios the positioning of FormEngine fields (e.g. type=input) should be improved.</p>
<p>1. If a field is added to a TCA type without using a palette, the field doesn't have enough space on the bottom. Thereby the charcounter runs into the border of the `form-section`.<br />This happens since the field doesn't get surrounded by a `row` and doesn't have the `col-md-*` class.</p>
<p><img src="http://forge.typo3.org/attachments/download/34521/no-palette.png" title="charcounter in border - No palette" alt="charcounter in border - No palette" loading="lazy" /></p>
<p>2. This also happens to all fields in palettes on smaller viewports (if they have e.g. `col-md-12` on Viewports <992, `col-sm-6` on Viewports <768, `col-sm-4` on Viewports <768, ...) as the appropriate styles are included in the media queries.</p>
<p><img src="http://forge.typo3.org/attachments/download/34520/palette-small-viewport.png" title="charcounter in title of next field (small viewport)" alt="charcounter in title of next field (small viewport)" loading="lazy" /></p>
<p><img src="http://forge.typo3.org/attachments/download/34519/palette-small-viewport-2.png" title="charcounter in border (small viewport)" alt="charcounter in border (small viewport)" loading="lazy" /></p>
<p>3. If more than one field are in a palette, not separated by a `--linebreak--` and one have a `description` while the other haven't the display looks distorted.</p>
<p><img src="http://forge.typo3.org/attachments/download/34522/palette-field-description.png" title="distorted display - palette - field description" alt="distorted display - palette - field description" loading="lazy" /></p>