TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-02-28T10:58:05ZTYPO3 Forge
Redmine TYPO3 Core - Bug #100043 (New): Link browser forgets scroll position after opening subtreehttp://forge.typo3.org/issues/1000432023-02-28T10:58:05ZJigal van Hemertjigal.van.hemert@typo3.org
<p>In the link browser modal you can open a subtree by clicking on the triangle in front of a page. After that the pagetree is displayed from the top and you may have to scroll way down to the position of the subtree you just opened.<br />With the rewrite of the JS in v11 this has been taken care of but it's a problem in v10 for editors who work with a huge pagetree on a daily basis.</p> TYPO3 Core - Bug #99472 (Needs Feedback): URLs in hreflang tags and language menus are cached wit...http://forge.typo3.org/issues/994722023-01-05T16:08:04ZJigal van Hemertjigal.van.hemert@typo3.org
<p>If you flush the cache of a page with hreflang tags and a language menu the query parameters of the first request are cached and used for subsequent requests to that page, even if other query parameters are present in the URL.</p>
<p>In other issues (such as <a class="external" href="https://forge.typo3.org/issues/88264">https://forge.typo3.org/issues/88264</a> ) it's suggested to add those parameters to the cHash white list. This is not desirable in all cases.<br />If for example a solr result plugin is displayed on the page then the search query and the facet parameters should not be included in the cHash (that would flood the cache) but these parameters should be part of the hreflang tags and the language menu.<br />Currently the parameters used with the first request for that page after flushing the cache are used for the hreflang tags and the language menu of future requests to the page. If you select other facets or visit the page without any parameters then the cached parameters are also used.</p> TYPO3 Core - Bug #98176 (New): Preview of translated siteroot page in EditDocumentController fail...http://forge.typo3.org/issues/981762022-08-19T08:37:12ZJigal van Hemertjigal.van.hemert@typo3.org
<p>For the preview URL the rootline of the preview page is traversed to find a Site (which will provide the domain). If the page is a translation the rootline will start with the record of the translation and the SiteFinder fails to find a Site for this page uid.</p>
<p>If a preview of a subpage is made then the rootline will have data for pages in the default language for pages above the preview page. The SiteFinder will then be able to find a Site.</p>
<pre>
[_] - root folder (to include global stuff)
+- Domain1
| +- subpage1
+- Domain2
+- subpage2
</pre>
<p>If you edit a translation of page "Domain1" and use the View button in the ButtonBar the previewPageId will be that of the translation of page "Domain1". The rootline will contain:</p>
<pre>
translation "Domain1" --> default language "root folder"
</pre>
<p>The SiteFinder can't find a Site based on the page uid of the translation of "Domain1".</p>
<p>If you edit a translation of a subpage (e.g. "subpage1") and use the same View button, the rootline will contain:</p>
<pre>
translation "subpage1" --> default language "Domain1" --> default language "root folder"
</pre>
<p>Now the SiteFinder will find the Site using the uid of the "Domain1" page in the default language.</p>
<a name="Solution"></a>
<h2 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>The View button is used for all kinds of records. For records other than 'pages' records there will be no problem because the previewPageId will always point to page in the default language. For 'pages' records it needs to be checked if the record is a translation and then the uid of the translation origin pointer needs to be used to generate the rootline.</p>
<p>The issue was found in v10 but looking at the code it's still present in the current code base. A patch for v10 was created which needs to be heavily adjusted for the changes in v11+ in the handling of preview URLs.</p> TYPO3 Core - Bug #97976 (Closed): In link popup it would be nice to enter a page ID directlyhttp://forge.typo3.org/issues/979762022-07-20T12:42:50ZJigal van Hemertjigal.van.hemert@typo3.org
<p>In v6 there was a field in the Page tab of the link popup where editors could enter the ID of the page directly.<br />Quite a few editors have asked why the field isn't present in later versions.</p> TYPO3 Core - Bug #97817 (New): RTE removes line with empty, allowed tags when savinghttp://forge.typo3.org/issues/978172022-06-28T07:46:04ZJigal van Hemertjigal.van.hemert@typo3.org
<p>Lines with only tags which are "empty" (not containing any text content) by definition but which are allowed in the configuration can be removed when saving the RTE contents if they happen to also contain a single </p>
<p>The offending paragraph was:<br /><pre>
<p>&nbsp;
<audio controls=""><source src="/fileadmin/filer/Lyd/Dansk_Lydhistorie__Statsbiblioteket/Dialekter/Dialekt_fra_Anholt__Djurs_.mp3" type="audio/mpeg" /></audio>
</p>
</pre></p>
<p>Both the audio and source tags were configured as allowed.</p>
<p>In \TYPO3\CMS\Core\Html\RteHtmlParser::divideIntoLines() there is a check to see if the line is considered as "empty": <a class="external" href="https://github.com/TYPO3/typo3/blob/10.4/typo3/sysext/core/Classes/Html/RteHtmlParser.php#L656-L661">https://github.com/TYPO3/typo3/blob/10.4/typo3/sysext/core/Classes/Html/RteHtmlParser.php#L656-L661</a></p>
<p>First it strips all tags and if a single is left<br />it checks to see if there is no img tag present<br />and no attributes from a set of general attributes present<br />if all these three conditions are met the line is considered "empty" and the contents are removed.</p>
<p>The check for a single is strange in itself, but not very relevant in this case.</p>
<p>The second check for the img tag probably wants to consider this tag as "content". A picture element must contain an img element and is content, an img element on its own is content, but audio and video elements only contain source elements to define their content.</p>
<p>A solution would be to also consider "source" elements as content.</p> TYPO3 Core - Bug #97094 (Under Review): Transl.Orig field for content element creates confusing t...http://forge.typo3.org/issues/970942022-03-03T13:54:39ZJigal van Hemertjigal.van.hemert@typo3.org
<p>For content elements the select box "Transl.Orig" modifies the l18n_parent field. The wizard (and the button to activate it) to translate content elements looks for elements using the l10n_source field.<br />This works fine if translations are made, but when someone edits an element in a non-default language and changes the l18n_parent field things start to go wrong.</p>
<p>Example with English as default language and German as translation.<br />1. Create an English element "en1" <br />2. Create an English element "en2" <br />2. Create a German element "de1" <br />The page indicates "free mode" for translation.</p>
<p>3. Edit the German element "de1" and set "en1" as the 'Transl.Orig' value. This modifies the l18n_parent field.<br />The page now indicates "connected mode".</p>
<p>4. Use the "Translate" button to translate the English content to German.<br />Now two (!) content elements have been added to the German page, translations of "en1" and "en2".</p> TYPO3 Core - Bug #95910 (New): Page history does not show changes from translated pageshttp://forge.typo3.org/issues/959102021-11-08T14:52:47ZJigal van Hemertjigal.van.hemert@typo3.org
<p>While it's technically understandable it's not clear for editors.</p>
Steps to reproduce:
<ul>
<li>create a page and one or more translations</li>
<li>change something in the page properties and in the page properties of the translation(s)</li>
<li>use the context menu in the page tree and select "History/Undo"</li>
</ul>
<p>The Changelog only lists changes in the page record in the default language.</p>
<p>If you open History/Undo on the parent page the changelog shows the changes in the sub page(s) in all languages.</p>
<p>Technically it's correct that the changelog shows the changes on the page itself and the records in that page. For editors a translated page is not a separate record but a variation of the current page. They expect the changes to be listed in the changelog.</p> TYPO3 Core - Bug #94355 (Closed): Delete action calls unserialize for a task which was listed as ...http://forge.typo3.org/issues/943552021-06-16T12:31:59ZJigal van Hemertjigal.van.hemert@typo3.org
<p>During an upgrade from 6.2 to 10 some tasks were not needed anymore and their classes were removed.<br />The scheduler module lists these as containing class which are not present in the installation (correct!). Upon deleting such a task \TYPO3\CMS\Scheduler\Controller\SchedulerModuleController::deleteTask() will fetch the task anyway (to check if it is running) and this requires a call to unserialize the task object.<br />Since this object contains the missing class PHP will end with a fatal error.</p>
<p>Solution could be to add an optional parameter to \TYPO3\CMS\Scheduler\Scheduler::fetchTask() which tells unserialize to only allow the AbstractTask class. That would make the check if the task is running still work and the task can be deleted after that.</p> TYPO3 Core - Bug #93597 (Closed): Adding a TS template with the runThroughTemplatesPostProcessing...http://forge.typo3.org/issues/935972021-02-26T21:00:19ZJigal van Hemertjigal.van.hemert@typo3.org
<p>The <code>runThroughTemplatesPostProcessing</code> hook in <code>TemplateService</code> is used to add a 'virutal' TS template (based on page properties).</p>
<p>In <code>runThroughTemplates()</code> each <code>sys_template</code> record also adds an item to the <code>rowSum</code> array (happens inside <code>processTemplate()</code> ).<br />After caches are cleared a hash from rowSum is used as key for caching all conditions. A hash of all matched conditions is used as key for caching all constants and setup.</p>
<p>If two pages only differ in the TS that the hook subscriber adds they will both get the same constants and setup from the cache (rowSum is equal and the same result from the conditions leads to the same key for the constants/setup cache).</p>
<p>If the hook subscriber could add items to rowSum the cache key would be different for both pages.</p>
<a name="Example"></a>
<h2 >Example<a href="#Example" class="wiki-anchor">¶</a></h2>
<p>Situation in site:<br /><pre>
+-- start <-- virtual TS added: "property=1"
+-- page1
+-- page2 <-- virtual TS added: "property=2"
| +-- page2.1
| +-- page2.2
+-- page3
</pre></p>
<p>If you clear caches, visit <strong>page1</strong> first the TS constants and setup are stored in cache. If you visit <strong>page2</strong> (or a subpage) after that the rowSum matches, the conditions are the same and thus the constants and setup from page1 are loaded from cache and used for page2 (and subpages).<br />If you clear caches, visit <strong>page2</strong> first that configuration will be used</p> TYPO3 Core - Bug #93263 (New): Creating a new page via pagetree context menu 'New' does not apply...http://forge.typo3.org/issues/932632021-01-11T14:47:12ZJigal van Hemertjigal.van.hemert@typo3.org
<p>TSconfig has:</p>
<pre>
TCAdefaults {
pages {
hidden = 1
}
}
</pre>
<p>If you use the context menu in the page tree to create a new page with the option 'New' it will open a new page record form which has the field hidden set to 0. The patch in <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: TCAdefaults.pages.hidden = 0 not working in TYPO3 9.5.9 and 10.1.0-dev using page tree drag & drop (Closed)" href="http://forge.typo3.org/issues/89211">#89211</a> applies the TSconfig before using the incoming fields, but this won't help as the value was already submitted.</p>
<p>Use case: no matter how you create a new page (drag'n'drop, context menu, wizard, ...) the default values for that site should be applied at first. With the 'New' context menu option the editor can change those defaults if they like</p> TYPO3 Core - Bug #90056 (New): Selection not open after after leaving filtered modehttp://forge.typo3.org/issues/900562020-01-06T11:35:37ZJigal van Hemertjigal.van.hemert@typo3.org
<p>If you select a page in the pagetree in filtered mode the node and then clear the search field, the pagetree returns to its previous state and the selected node may not be visible.</p>
Steps to reproduce:
<ul>
<li>have a pagetree with as few as possible nodes open</li>
<li>use search filter to find a page</li>
<li>select the page (it's now open in the right pane)</li>
<li>clear filter field</li>
</ul>
<p>The rootline to the selected page is not expanded.</p>
Expected behaviour:
<ul>
<li>after returning to unfiltered mode a selected node MUST be visible in the page tree (the nodes in its rootline must be opened)</li>
<li>after returning to unfiltered mode a selected node SHOULD be inside the visible part of the pagetree (scrolling issue)</li>
</ul>
<p>NB this is a déjà vu of a similar issue back in version 4.5-4.7 :-)</p> TYPO3 Core - Feature #88300 (New): Allow extra db columns in the records that are retrieved for t...http://forge.typo3.org/issues/883002019-05-08T10:33:21ZJigal van Hemertjigal.van.hemert@typo3.org
<p>In \TYPO3\CMS\Backend\Controller\Page\TreeController::getAllEntryPointPageTrees() the PageTreeRepository is instantiated with the default db fields for each row (fields defined in \TYPO3\CMS\Backend\Tree\Repository\PageTreeRepository::$fields). Sometimes other db fields are also needed, but this can't be configured.</p>
<p>Use case: a custom icon for a page in the pagetree is desired, based on the value of a db field that is not one of the default fields. A userFunc can be defined to set the icon class, but here the db row only contains the default fields defined in the PageTreeRepository class. In earlier versions of TYPO3 the entire db row was passed to such a userFunc.</p> TYPO3 Core - Bug #88299 (Closed): Refreshing the pagetree after persisting changes does not keep ...http://forge.typo3.org/issues/882992019-05-08T10:26:51ZJigal van Hemertjigal.van.hemert@typo3.org
<p>If you open a few subnodes of a selected page and edit the page properties of that selected page, saving the changes will trigger in a refresh of the pagetree (correct). The subnodes that were opened are now collapsed again.</p> TYPO3 Core - Bug #88298 (Closed): No way to reset search in pagetreehttp://forge.typo3.org/issues/882982019-05-08T10:12:20ZJigal van Hemertjigal.van.hemert@typo3.org
<p>The only way to clear the search in the pagetree is to delete the search word(s). This turns the pagetree in a state where all nodes are uncollapsed. Refreshing the tree turns it into a fully collapsed state. There is no way to return to the previous state (e.g. with a few nodes uncollapsed).</p>
<p>Expected behaviour:<br />after clearing the search field the pagetree returns to the previous state with one possible exception:<br />a selected node must always be visible</p> TYPO3 Core - Bug #82022 (Rejected): DataHandler doesn't store first record in foreign table as va...http://forge.typo3.org/issues/820222017-08-01T15:21:44ZJigal van Hemertjigal.van.hemert@typo3.org
<p>TCA:<br /><pre>
tx_myext_department
+- config
| +- foreign_table = tx_myext_departments
| +- foreign_table_where = ORDER BY tx_myext_departments.department
| +- maxitems = 1
| +- minitems = 1
| +- renderType = selectSingle
| +- size = 1
| +- type = select
+- exclude = 0
+- label = LLL:EXT:myext_metadata/locallang_db.xlf:pages.tx_myext_department
</pre></p>
<p>If new pages records are created from the page tree context menu or with the new record wizard the FormEngine (TM) kicks in and correctly selects the first record. If a new page is created by dragging in the page tree the field gets the value 0 which is later on displayed as [ INVALID VALUE ("0") ]</p>
<p>In TYPO3 6.2 the same configuration worked fine when creating new pages by dragging in the page tree. As the DataHandler is directly invoked by Ajax calls when you create a page in the pagetree the problem is most likely located in the DataHandler.</p>