TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-08-30T11:27:43ZTYPO3 Forge
Redmine TYPO3 Core - Bug #101798 (New): Prevent saving unchanged inline records to save performancehttp://forge.typo3.org/issues/1017982023-08-30T11:27:43ZSebastian Michaelsenmichaelsen@t3seo.de
<p><strong>Problem</strong></p>
<p>When you have a record, which has 10 inline items and the record is translated (along with the inline items) into 10 languages, then saving the record even with no changes to the inline items causes the DataHandler to save 110 database records which can take some 30 seconds.</p>
<p><strong>Why is that?</strong></p>
<p>The inline records have toggles to hide/unhide them (unless the table does no support that), which means when saving the record there will be a `someid => ['hidden' => '0']` entry for each inline item, which causes DataHandler to save that inline item, which then also triggers saving of its translations.</p>
<p><strong>Solution(?)</strong></p>
<p>It could be solved in backend JavaScript, so that the inline `hidden` form fields are only included in the request when their value was changed.</p>
<p><strong>Workaround</strong></p>
<p>For our project I created a backend middleware, that intercepts the `data` when a record is saved and removes any entries, that have just the hidden field and it is unchanged. (Yes, I create a database request for each of those entries but it's still <em>way</em> faster than before)</p> TYPO3 Core - Bug #95368 (Closed): Passing an eID array URL parameter logs into the TYPO3 error loghttp://forge.typo3.org/issues/953682021-09-27T10:31:17ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Calling <a class="external" href="https://www.example.com/index.php?eID[]=">https://www.example.com/index.php?eID[]=</a> produces an entry like this in the <code>sys_log</code>:</p>
<pre>
Core: Error handler (FE): PHP Warning: Illegal offset type in /path/to/project/typo3/sysext/frontend/Classes/Middleware/EidHandler.php line 70
</pre>
<p>This is the case for TYPO3 v10.4 and from looking at the code also at master.</p> TYPO3 Core - Bug #93480 (New): PDF Cropping configuration is not possible for editorshttp://forge.typo3.org/issues/934802021-02-10T09:42:03ZSebastian Michaelsenmichaelsen@t3seo.de
<p>TYPO3 can create images from PDFs and can also crop them. But for editors it's not possible to set that cropping, because the cropping wizard doesn't work for PDFs.</p> TYPO3 Core - Bug #93469 (Closed): Editing file metadata in a workspace takes immediate effect on ...http://forge.typo3.org/issues/934692021-02-09T08:09:54ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Steps to reproduce:</p>
<ul>
<li>Switch into a Workspace</li>
<li>Open the File module and edit a file</li>
<li>Fill out or change the title and save</li>
<li>Switch into the LIVE environment again</li>
<li>Edit the same file again<br />=> There are your Workspace changes, immediately applied to the LIVE record.</li>
</ul>
<p>As an editor I must be sure that my workspace changes can not alter the current LIVE website. Otherwise I will lose trust into the whole workspace feature.</p> TYPO3 Core - Feature #93460 (New): Register provider function for custom permission optionshttp://forge.typo3.org/issues/934602021-02-08T09:21:54ZSebastian Michaelsenmichaelsen@t3seo.de
<p>With $GLOBALS['TYPO3_CONF_VARS']['BE']['customPermOptions'] you can provide additional options that backend user groups can get assigned.<br />Docs: <a class="external" href="https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Examples/CustomPermissions/Index.html">https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Examples/CustomPermissions/Index.html</a></p>
<p>This is done in ext_tables and you have to provide an array of options. However if you want to involve database calls or other expensive operations to determine the available options, it would slow down the whole installation because it would be re-evaluated every time ext_tables is loaded.</p>
<p>It would be better to offer a way to register provider functions, that are only called when needed (in the backend form for backend user groups).</p> TYPO3 Core - Bug #93433 (New): TCA placeholder __row|field doesn't translate related recordshttp://forge.typo3.org/issues/934332021-02-04T11:40:41ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When using the __row|field syntax in placeholders, the related row is not overlaid with its translation.</p>
<p>example TCA for a tt_content field:<br /><pre>
'tx_myext_teaser_title' => [
'label' => $lll . '.tx_myext_teaser_title',
'config' => [
'type' => 'input',
'placeholder' => '__row|tx_myext_teaser_page|title',
],
],
</pre></p>
<p>For a translated content element, the placeholder should be filled with the value from the translated page record.</p> TYPO3 Core - Bug #93098 (Closed): Missing 'depends' section in ext_emconf.php leads to errorhttp://forge.typo3.org/issues/930982020-12-17T13:04:57ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If an extension has no <code>'depends'</code> section in <code>ext_emconf.php</code>, but requires packages via <code>composer.json</code>, then during <code>install:generatepackagestates</code> an error is raised:</p>
<p>The package "myext" depends on "my/composer-package" which is not present in the system.</p>
<p>When putting <code>'constraints' => ['depends' => []],</code> into <code>ext_emconf.php</code> it works fine.</p>
<p>Especially for project specific local extensions you may not have any dependencies specified. When it works with the empty depends array, it should also be possible to leave it out entirely.</p> TYPO3 Core - Bug #93024 (Closed): PDF download from private storage yields thumbnailhttp://forge.typo3.org/issues/930242020-12-08T07:50:01ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If a TYPO3 installation is capable (ImageMagick + configuration) of creating thumbnails of PDFs, the eID download of PDFs will always output an image instead of a PDF.</p>
<p>This is the case since <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Implement better FileDumpController (Closed)" href="http://forge.typo3.org/issues/90068">#90068</a></p>
Steps to reproduce:
<ul>
<li>Have a TYPO3 installation that creates thumbnails for PDFs (Check in Environment backend module)</li>
<li>Create a non-public file storage with a PDF in it.</li>
<li>Link the PDF, e.g. via the RTE of a text element.</li>
<li>Click the download link in the frontend.</li>
</ul>
<p>Expected result: PDF is opened or downloaded<br />Actual result: Thumbnail image of PDF is opened</p> TYPO3 Core - Task #92971 (Closed): Don't try to create language switch for non-persisted recordshttp://forge.typo3.org/issues/929712020-12-01T14:57:31ZSebastian Michaelsenmichaelsen@t3seo.de
<p><code>EditDocumentController->languageSwitch()</code> generates the language dropdown menu in the backend record edit form.</p>
<p>When creating a new record, the result is always that no dropdown form is displayed.</p>
<p>However also for new records the function performs DB queries and runs a lot of code. Instead it should not be called in this case.</p> TYPO3 Core - Feature #92929 (Closed): Allow registering additional "trees" in Configuration Modulehttp://forge.typo3.org/issues/929292020-11-25T09:37:55ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The list of available "trees" (<code>$GLOBALS['TYPO3_CONF_VARS']</code>, <code>$GLOBALS['TCA']</code>, ..., <code>Event Listeners</code>) of the Configuration module is hardcoded in the <a href="https://github.com/TYPO3/TYPO3.CMS/blob/73bcf9a1d971308f3ad66638ca1587a8dac8f681/typo3/sysext/lowlevel/Classes/Controller/ConfigurationController.php#L64" class="external">ConfigurationController</a> . An item for the form extension is <a href="https://github.com/TYPO3/TYPO3.CMS/blob/73bcf9a1d971308f3ad66638ca1587a8dac8f681/typo3/sysext/lowlevel/Classes/Controller/ConfigurationController.php#L179" class="external">added</a> via <code>if (ExtensionManagementUtility::isLoaded('form'))</code>.</p>
<p>Instead there should be an interface to add configration trees. The <code>form</code> extension and other extensions that maintain a configuration can then just add themselves to the module.</p> TYPO3 Core - Bug #92906 (New): File Metadata are not editable when translation doesn't exist yethttp://forge.typo3.org/issues/929062020-11-23T13:52:03ZSebastian Michaelsenmichaelsen@t3seo.de
<p>In the backend form of sys_file_reference inline records, typically there's a link where you can edit the metadata of the selected file.</p>
<p>Since the fix for <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: \TYPO3\CMS\Backend\Form\Container\InlineRecordContainer::renderForeignRecordHeaderControl wrong e... (Closed)" href="http://forge.typo3.org/issues/82178">#82178</a> this link is removed if there is not sys_file_metadata record in the same language as sys_file_reference record.</p>
<p>However obviously editors want to edit metdata for files which have not been explicitly localized before. So I suggest that sys_file_metadata translations are created on demand in this situation.</p> TYPO3 Core - Feature #92778 (Closed): Provide Event to modify Site configurationhttp://forge.typo3.org/issues/927782020-11-05T12:33:23ZSebastian Michaelsenmichaelsen@t3seo.de
<p>TYPO3 should provide a way to programmtically enhance the Site configuration right after it was read from the YAML file(s) and before it is cached (i.e. here: <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/abfef0336cb0d25335ace900df385e98d2951820/typo3/sysext/core/Classes/Configuration/SiteConfiguration.php#L172">https://github.com/TYPO3/TYPO3.CMS/blob/abfef0336cb0d25335ace900df385e98d2951820/typo3/sysext/core/Classes/Configuration/SiteConfiguration.php#L172</a>).</p>
<p>My first approach was using a middleware that modified the site config after it was initialized, but that can only modify the configuration of the <strong>current</strong> page. The configuration will be initialized again for the <code>$siteOfTargetPage</code> when you link to a page for example.</p>
<p><strong>Use Case:</strong><br />My <a href="https://github.com/smichaelsen/typo3-dynamic-routing-pages" class="external">EXT:dynamic_routing_pages</a> programatically provides the page ids for routes, that otherwise are hardcoded. Currently I have to use an Xclass to achieve it.</p>
<p>Also other extensions could provide site configuration programatically, e.g. determining the root page, languages or <a href="https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/SiteHandling/ExtendingSiteConfig.html" class="external">project specific options</a>.</p> TYPO3 Core - Feature #91077 (Closed): Define default page for Record selector / ElementBrowserhttp://forge.typo3.org/issues/910772020-04-17T08:59:39ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When using a <code>type=group</code> / <code>internal_type=db</code> TCA field you get a separate button for each allowed table that allows you to open the Record selector searching for that specific record type. If you have a (main) storage folder for a certain record type it would be convenient for editors if the Record selector loads with that page opened.<br />If for example your contact records are on <code>pid=370</code> you should be able to configure this in your TCA, so that the Record selector opens with page 370 preselected when the user wants to select for a contact record.</p>
<p>I did a quick proof of concept for which I attach a patch file based on TYPO3 8.7.</p>
<p>The configuration works like this (<code>myfield</code> being a <code>type=group</code> / <code>internal_type=db</code> field):</p>
<p><code>$GLOBALS['TCA']['tx_myext_mytable']['columns']['myfield']['config']['defaultStorageFolders'] = ['tt_address' => 370]</code></p>
<p><img src="http://forge.typo3.org/attachments/download/35081/screenshot-contact.png" alt="" loading="lazy" /></p> TYPO3 Core - Feature #85986 (Closed): Create new inline record before the existing oneshttp://forge.typo3.org/issues/859862018-08-27T09:19:08ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The default behaviour of the inline TCA input is that a "Create New" button is shown on <strong>top</strong> of the list of existing records. When using it a record is created at the <strong>bottom</strong> of the list. This is unintuitive. Also when setting the button position to <em>both</em> a user can expect that he can use the two buttons to create a new record at the top or at the bottom of the list respectively.<br />At the moment there seems no possibility to create a new inline record before the existing ones.</p> TYPO3 Core - Feature #76134 (Accepted): Signal to modify editlinks for LiveSearch resultshttp://forge.typo3.org/issues/761342016-05-11T10:20:23ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Some extensions bring their own backend modules to view and edit their data. But the results of LiveSearch always link to the regular TYPO3 forms. Extensions may want to alter the editlinks.</p>
<p>For my personal itch I wrote an extension introducing a signal in LiveSearch: <a class="external" href="https://github.com/smichaelsen/typo3-livesearch-linkhook">https://github.com/smichaelsen/typo3-livesearch-linkhook</a></p>