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 #97776 (New): Disabled scheduler tasks are not dimmed outhttp://forge.typo3.org/issues/977762022-06-15T09:50:04ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The <code>SchedulerModueController</code> says <code>// Row is shown dimmed if task is disabled, unless it is still running</code> and a corresponding CSS class <code>disabled</code> is set on disabled tasks, but visually there is no difference.</p>
<p>Tested in TYPO3 v10, but I suppose this is also the case in higher versions.</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 - 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 - 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 #92909 (New): Page Translation list is not orderable, but is rendered always in ...http://forge.typo3.org/issues/929092020-11-23T15:24:12ZSebastian Michaelsenmichaelsen@t3seo.de
<p>In the list view for translated pages the "Page Translation" list is always on top.</p>
<p>In the daily work of content editors this list will hardly ever be the most important one, but there is no possbility to reorder it, because <code>mod.web_list.tableDisplayOrder</code> doesn't have any effect on it.</p>
<p>The fact that you also can't really collapse it (<a class="issue tracker-1 status-1 priority-4 priority-default" title="Bug: Page and Page Translation lists can not be collapsed/expanded independently (New)" href="http://forge.typo3.org/issues/92907">#92907</a>) makes the situation worse.</p> TYPO3 Core - Bug #92907 (New): Page and Page Translation lists can not be collapsed/expanded inde...http://forge.typo3.org/issues/929072020-11-23T15:06:14ZSebastian Michaelsenmichaelsen@t3seo.de
<p>In the list module when you collapse/expand the "Page Translation" list, it will not be persisted. Instead it seems that it will always take over the state of the "Page" list.</p>
<p>Reproduce in a multi-language installation:</p>
<ol>
<li>Open a page in the list module that has translations and subpages. It will have “Page Translations” and “Page” record lists.</li>
<li>Collapse the “Page Translation” list by clicking the little “up”-chevron in the top right.</li>
<li>Refresh the module. “Page Translations” is not collapsed.</li>
<li>Collapse the “Page” list.</li>
<li>Refresh the module. Both lists are now collapsed.</li>
</ol> 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 - Bug #89192 (Accepted): TypoScript multi-line value syntax in is broken in Backend La...http://forge.typo3.org/issues/891922019-09-17T18:06:42ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Consider the following Backend Layout:</p>
<pre><code class="text syntaxhl" data-language="text">mod.web_layout.BackendLayouts.infoPage {
title = Info Page
config.backend_layout {
colCount = 1
rowCount = 1
rows {
1.columns.1 {
name = Content Area
colPos = 0
allowed.CType (
gridelements_pi1,
list,
shortcut,
text,
)
}
}
}
}
</code></pre>
<p>The multi-line value for allowed.CType is perfectly valid and correctly parsed by TYPO3. However <code>\TYPO3\CMS\Backend\Provider\PageTsBackendLayoutDataProvider->generateBackendLayoutFromTsConfig</code> tries to reconstruct the original TSconfig from the parsed array and assumes all values are one-line values with <code>=</code> syntax.</p>
<p>The reconstructed TSconfig then looks like this (in Xdebug)</p>
<pre><code class="text syntaxhl" data-language="text">backend_layout.colCount = 1
backend_layout.rowCount = 1
backend_layout.rows.1.columns.1.name = Content Area
backend_layout.rows.1.columns.1.colPos = 0
backend_layout.rows.1.columns.1.allowed.CType = gridelements_pi1,
list,
shortcut,
text
</code></pre>
<p>Resulting in only <code>gridelements_pi1</code> to be allowed.</p>
<p>A possible solution could be to strip all line breaks while reconstructing the TSconfig.</p>
<p>Workaround: Do not use the multi-line value syntax in Backend Layouts.</p>
<p>This affects at least TYPO3 8 to 10.</p> TYPO3 Core - Bug #82784 (Accepted): DataHandler: copyRecords doesn't set sorting correctly for ne...http://forge.typo3.org/issues/827842017-10-17T15:52:35ZSebastian Michaelsenmichaelsen@t3seo.de
<p>In <code>DataHandler->copyRecord()</code> accepts a <code>$destPid</code> which (according to the phpDoc) can either contain a page id or (indicated by a negative number) a content uid after which the source record is copied to. This "convention" is also used in <code>DataHandler->moveRecord()</code>.</p>
<p>However <code>DataHandler->copyRecord()</code> does not implement the functionality. Only <code>DataHandler->moveRecord()</code> does.</p>
<p>How to reproduce:</p>
<pre>
$dataHandler = GeneralUtility::makeInstance(DataHandler::class);
$data = [
'tt_content' => [
$sourceContentUid=> [
'copy' => ($targetContentUid * -1),
],
],
];
$dataHandler->start([], $data);
$dataHandler->process_cmdmap();
</pre>
<p>The copied element will just receive the sorting value of the source element instead of being sorted after the target content element.</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> TYPO3 Core - Bug #43874 (Closed): array_merge_recursive_overrule: __UNSET can't unset array valueshttp://forge.typo3.org/issues/438742012-12-11T11:17:09ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If the $enableUnsetFeature parameter is true, array_merge_recursive_overrule you can unset values from the first array.<br />The phpDoc says:<br /><pre>
* @param boolean $enableUnsetFeature If set, special values "__UNSET" can be used in the second array in order to unset array keys in the resulting array.
</pre><br />But in fact keys are only unset if they don't hold an array value. I see no reason why this should be like this. There should be the possibility to unset array values.</p> TYPO3 Core - Task #40870 (Closed): Add Utility Functions to retreive Information from Class Nameshttp://forge.typo3.org/issues/408702012-09-12T16:23:02ZSebastian Michaelsenmichaelsen@t3seo.de
<p>My intention is to introduce these 2 Utility Functions:</p>
<p>\TYPO3\CMS\Core\Extension\ExtensionManager::getClassNameWithoutVendorAndProduct($className)<br />\TYPO3\CMS\Core\Extension\ExtensionManager::getExtensionKeyFromClassName($className)</p>
<p>These can be used in the the Autoloader for example (will be a separate patch, when this one is done).<br />Also Extbase can make use of these functions to resolve #40742.</p> TYPO3 Core - Feature #21928 (Accepted): Enable/Disable Control Icons in the List Module via Page...http://forge.typo3.org/issues/219282010-01-08T14:14:52ZSebastian Michaelsenmichaelsen@t3seo.de
<p>For each record in the databse the List module offers a variety of funtions. Depending on the Database Table, User Rights and other circumstances you can Edit, Move, Delete, Preview etc records.<br />But especially for editors with low technical skills the "wall of icons" in the extended view can be confusing.<br />Yes, you can disable the extended view, but then you might take away features the editor needs to perform his tasks.<br />Until now it's not possible to disable single Control Icons.</p>
<p>Solution is to introduce some properties to mod.web_list (which is avaiable in PageTS and UserTS).<br />My patch introduces the following properties:</p>
<p>mod.web_list.tableControls.[table].delete.disabled<br />mod.web_list.tableControls.[table].edit.disabled<br />mod.web_list.tableControls.[table].hideUnhide.disabled<br />mod.web_list.tableControls.[table].history.disabled<br />mod.web_list.tableControls.[table].info.disabled<br />mod.web_list.tableControls.[table].move.disabled<br />mod.web_list.tableControls.[table].moveLevels.disabled<br />mod.web_list.tableControls.[table].newRecordAfter.disabled<br />mod.web_list.tableControls.[table].permissions.disabled <br />mod.web_list.tableControls.[table].show.disabled<br />mod.web_list.tableControls.[table].upDown.disabled<br />mod.web_list.tableControls.[table].versions.disabled</p>
<p>Obviously all of them are boolean and "1" disables the certain icon.</p>
<p>Now you can disable Icons depending on Be-User, Page and Database Table.</p>
<p>Mind that some of the Controls are only available for certain tables. Eg. "moveLevels" is only for pages.</p>
<p>Though most Icons should be uite clear I attached a screenshot, showing which property belongs to which icon.<br />(issue imported from #M13183)</p>