TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-11-30T17:47:27ZTYPO3 Forge
Redmine TYPO3 Core - Bug #87049 (Closed): Workspace Preview Info is rendered with pointer-events: nonehttp://forge.typo3.org/issues/870492018-11-30T17:47:27ZLorenz Ulrich
<p>The Workspace Preview information contains a link to leave the Preview mode:</p>
<p><img src="http://forge.typo3.org/attachments/download/33979/workspace-preview-info.jpg" alt="" loading="lazy" /></p>
<p>The container has the CSS style <code>pointer-events: none</code> which seemingly doesn't allow the link to be clicked.</p>
<p>I'm not sure why this is the case. I assume the motivation was not to block any essential parts of the sites during Workspace Preview.</p> TYPO3 Core - Bug #82750 (Closed): Workspace preview doesn't preview MM relations properlyhttp://forge.typo3.org/issues/827502017-10-12T19:07:39ZLorenz Ulrich
<p>If the workspace preview is used to preview a record of an Extbase extension having an m:n relation, the relation data isn't displayed properly in the stage preview.</p>
<p>The stage preview doesn't show a relation added to an item in a workspace while it is correctly saved in the database and also correctly applied if published.</p>
<p>So I assume the reason for the preview not working properly must be a bug in Extbase.</p>
<p>I created an extension to demonstrate the issue:</p>
<p><a class="external" href="https://github.com/visol/ext-group_mm_workspaces_test">https://github.com/visol/ext-group_mm_workspaces_test</a></p>
<p>The Workspace preview only works in this case if <a class="external" href="https://review.typo3.org/#/c/52791/">https://review.typo3.org/#/c/52791/</a> is applied.</p> TYPO3 Core - Bug #75484 (Rejected): Error in file list module when having a read-only filemount f...http://forge.typo3.org/issues/754842016-04-10T21:04:44ZLorenz Ulrich
<p>Test case:</p>
<ul>
<li>Assign a normal filemount, e.g. for 1:/test (Folder test in storage 1) to a user</li>
<li>Set a read-only filemount for the root path of storage 1: <code>options.folderTree.altElementBrowserMountPoints = 1:/</code></li>
</ul>
<p>This is the case in an environment where editors only can manipulate certain folders (e.g. of their departments), but should be able to read/use all file of the website.</p>
<p>Now, after switching to a non-admin user that has both filemounts assigned, a click to "test" in the File List module leads to an "endless" call that is terminated at max_execution_time.</p>
<p>This problem was introduced with <a class="external" href="https://review.typo3.org/#/c/39898">https://review.typo3.org/#/c/39898</a> in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Prevent information disclosure in file list (Closed)" href="http://forge.typo3.org/issues/67245">#67245</a>. Before (or without) that change, this setup works/worked fine.</p> TYPO3 Core - Bug #72116 (Closed): Files without references still show a warning before deletinghttp://forge.typo3.org/issues/721162015-12-09T09:48:48ZLorenz Ulrich
<p>I have some files in the File module that have no references with is correctly shown in the list:</p>
<p><img src="http://forge.typo3.org/attachments/download/30274/file-reference-1.png" alt="" loading="lazy" /></p>
<p>When I look at the detail view of the file, I see a reference nevertheless - the reference from the sys_file_metadata record to this file:</p>
<p><img src="http://forge.typo3.org/attachments/download/30276/file-reference-2.png" alt="" loading="lazy" /></p>
<p>Now when I'm trying to delete this file, which is never used in content, I still get the warning that there is one reference:</p>
<p><img src="http://forge.typo3.org/attachments/download/30275/file-reference-3.png" alt="" loading="lazy" /></p>
<p>I assume that the problem is that the JavaScript dialog is based on the total number of references without considering that every file has a sys_file_metadata record.</p> TYPO3 Core - Bug #71973 (Closed): Sorting of file relations doesn't have any effect in a workspacehttp://forge.typo3.org/issues/719732015-11-30T10:56:49ZLorenz Ulrich
<p>Sorting file references, e.g. in a "file links" element, doesn't have any effect in a workspace. After saving, the sorting is just as it was before:</p>
<p><img src="workspaces-fal-sorting.mp4" alt="" /></p> TYPO3 Core - Bug #66653 (Closed): shortcut_mode value is not correctly selected when adding trans...http://forge.typo3.org/issues/666532015-04-29T11:37:36ZLorenz Ulrich
<p>When a page of type "Shortcut" is translated, the value for the field <code>shortcut_mode</code> is not correctly selected:</p>
<p><img src="http://forge.typo3.org/attachments/download/28863/shortcut_mode.png" alt="" loading="lazy" /></p>
<p>This is distracting for editors because they assume that by default a translated page has the same properties as the page in the default language.</p> TYPO3 Core - Bug #65705 (Closed): baseURL determination of EXT:rtehtmlare fails in edge casehttp://forge.typo3.org/issues/657052015-03-12T22:01:32ZLorenz Ulrich
<p>The RTE has a client-side method of determining the baseURL. The baseURL is later used for loading additional resources (e.g. custom CSS). It first tries to use the <code>document.baseURI</code> property (which isn't present in IE), with fallbacks to the base href in the content and the whole URL. To ensure that the baseURL is only the path to the TYPO3 installation (without a document or arguments), a Regex rule is then applied to extract the path to TYPO3:</p>
<pre>
if (this.baseURL && this.baseURL.match(/(.*\:\/\/.*\/)[^\/]*/)) {
this.baseURL = RegExp.$1;
}
</pre>
<p>This works perfectly for standard URLs such as <code>https://mydomain.tld/typo3/alt_doc.php?foo=bar</code>; the RegExp returns <code>https://mydomain.tld/typo3/</code>.</p>
<p>But if the URL of the page contains another fully qualified URL, the Regex fails and the whole URL is taken. For <code>https://mydomain.tld/typo3/alt_doc.php?returnUrl=https://mydomain.tld/typo3/something.php</code>, the whole input string is returned. This leads to a wrong baseURL and makes the browsers (tested: Firefox) fail to load the resources.</p>
<p>The Regex needs to be improved.</p> TYPO3 Core - Bug #60254 (Closed): Non-admins cannot rename bookmarkshttp://forge.typo3.org/issues/602542014-07-10T22:10:16ZLorenz Ulrich
<p>A non-admin can add bookmarks to pages, but adding bookmarks to records fails. After the confirmation popup is clicked, nothing happens.</p> TYPO3 Core - Bug #59849 (Closed): Global renderReadonly in Tceforms doesn't affect treehttp://forge.typo3.org/issues/598492014-06-24T14:43:12ZLorenz Ulrich
<p>The global renderReadonly status in Tceforms doesn't affect a rendered tree because the check was forgotten when <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: TCA Tree readOnly not working (Closed)" href="http://forge.typo3.org/issues/25888">#25888</a> was implemented.</p> TYPO3 Core - Bug #59338 (Closed): Improve styling of sys_action "Create Backend User"http://forge.typo3.org/issues/593382014-06-04T14:52:46ZLorenz Ulrich
<p>The styling of the sys_action "Create Backend User" is not very user-friendly. Especially if you're dealing with a lot of categories, selecting them is a pain because the height of the selector is only 4 items:</p>
<p><img src="http://forge.typo3.org/attachments/download/26860/create-beuser.png" alt="" loading="lazy" /></p>
<p>This should be improved; at the same time the fields should be enlarged and old icons (delete) should be replaced.</p> TYPO3 Core - Bug #59297 (Closed): sorting.direction in Content Object FILES has no stdWraphttp://forge.typo3.org/issues/592972014-06-02T21:07:31ZLorenz Ulrich
<p>I remember a decision that new TypoScript properties should always be stdWrap enabled, but I'm not sure if it is strict policy.</p>
<p>The sorting.direction subproperty of FileContentObject currently lacks stdWrap:</p>
<pre>
if (is_array($conf['sorting.']) && isset($conf['sorting.']['direction']) && strtolower($conf['sorting.']['direction']) === 'desc') {
$fileObjects = array_reverse($fileObjects);
}
</pre>
<p>What do you think about adding it?</p> TYPO3 Core - Bug #59192 (Closed): mergeIfNotBlank with FAL recordshttp://forge.typo3.org/issues/591922014-05-28T22:55:07ZLorenz Ulrich
<p>mergeIfNotBlank doesn't seem to play with FAL records. I'm using EXT:news with FAL relations enabled (default as of 3.0). There are two FAL fields:</p>
<p>- Media file (fal_media)<br />- Related files (fal_related_files)</p>
<p>Both are using <code>ExtensionManagementUtility::getFileFieldTCAConfig</code> for their file field.</p>
<p>The <a href="http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Index.html?highlight=l10n_mode#l10n-mode" class="external">TCA reference</a> states the following: "Field will be editable but if the field value is blank the value from the default translation is used (this can be very useful for images shared from the default record). Requires frontend support. In the backend the effect is that the field content is not copied when a new "localization copy" is made."</p>
<p>From my understanding, applied to a FAL field this means the following when I localize an item:</p>
<a name="Scenario-A-I-just-want-to-use-the-files-from-the-original-version"></a>
<h2 >Scenario A: I just want to use the files from the original version<a href="#Scenario-A-I-just-want-to-use-the-files-from-the-original-version" class="wiki-anchor">¶</a></h2>
<p><strong>Expectation:</strong></p>
<p>The sys_file_references are not copied. I see an information about the items that are going to be used if I don't set any new relations:</p>
<p><img src="http://forge.typo3.org/attachments/download/26824/mergeifnotblank-information.png" alt="" loading="lazy" /></p>
<p>When I view the localized news, the files from the original version are visible.</p>
<p><strong>Current behaviour, sys_language_mode=strict:</strong></p>
<ul>
<li>I don't see any information about the files being used if I don't set any new relations.</li>
<li>I have no files in the frontend output at all.</li>
</ul>
<p><strong>Current behaviour, sys_language_mode=content_fallback:</strong></p>
<ul>
<li>I don't see any information about the files being used if I don't set any new relations.</li>
<li>I can see the file references.</li>
</ul>
<a name="Scenario-B-I-want-to-use-own-files-for-the-localized-version"></a>
<h2 >Scenario B: I want to use own files for the localized version<a href="#Scenario-B-I-want-to-use-own-files-for-the-localized-version" class="wiki-anchor">¶</a></h2>
<p><strong>Expectation:</strong></p>
<p>I add own files. Since the fields are no longer blank in the localized version, only the localized files I added will be displayed.</p>
<p><strong>Current behaviour, sys_language_mode=strict:</strong></p>
<p>No files are displayed at all.</p>
<p><strong>Current behaviour, sys_language_mode=content_fallback:</strong></p>
<p>The files from the default language are displayed, the files from the localized version are ignored.</p>
<a name="Possible-workaround"></a>
<h2 >Possible workaround<a href="#Possible-workaround" class="wiki-anchor">¶</a></h2>
<p>The only way I can add files at all in a translated item is to change the TCA definition of the field to display the localization buttons:</p>
<pre>
$TCA['tx_news_domain_model_news']['columns']['fal_related_files'] = array(
'exclude' => 1,
'l10n_mode' => 'mergeIfNotBlank',
'label' => '' . $ll . 'tx_news_domain_model_news.fal_related_files',
'config' => \TYPO3\CMS\Core\Utility\ExtensionManagementUtility::getFileFieldTCAConfig(
'related_files',
array(
'appearance' => array(
'showAllLocalizationLink' => 1,
'showSynchronizationLink' => 1,
)
)
)
);
</pre>
<p>Then I see the files from the original language.</p>
<p><img src="http://forge.typo3.org/attachments/download/26825/fal-localized-buttons.png" alt="" loading="lazy" /></p>
<p><strong>sys_language_mode=strict:</strong> They are still not displayed in the frontend as it would be expected for "mergeIfNotBlank" fields.</p>
<p>Once I localize the references, the files are displayed. But the meta information is always taken from the default language and cannot be overridden:</p>
<p><img src="http://forge.typo3.org/attachments/download/26826/fal-override-notworking.png" alt="" loading="lazy" /></p>
<p>Relations that only exist in the localized version are still not displayed at all (both language modes).</p>
<p>I don't know if these are mostly Extbase or non-Extbase issues.</p> TYPO3 Core - Bug #59161 (Closed): Metadata and File Reference inconsitencyhttp://forge.typo3.org/issues/591612014-05-28T09:39:32ZLorenz Ulrich
<p>Currently, the usage of Metadata in File References is a bit distracting.</p>
<p>Once the sysext filemetadata is installed, there are two fields in a file:</p>
<p>- Description<br />- Caption</p>
<p>In sys_file_reference, the label is called</p>
<p>Description (Caption)</p>
<p>and it takes the data from the description field.</p>
<p><img src="http://forge.typo3.org/attachments/download/26815/fal-description-caption.png" alt="" loading="lazy" /></p>
<p>This can be confusing for editors. I'm aware that I can just overwrite the field names and hide the not needed fields, but I want to check whether you think that the current default state is OK in your eyes.</p> TYPO3 Core - Bug #58916 (Closed): Non-admin user cannot restore pages with recyclerhttp://forge.typo3.org/issues/589162014-05-19T12:35:35ZLorenz Ulrich
<p>As a non-admin user, I cannot restore a page I deleted. After deleting a page, this is the admin's view of the recycler:</p>
<p><img src="http://forge.typo3.org/attachments/download/26733/recycler-admin.png" alt="" loading="lazy" /></p>
<p>The non-admin doesn't see the pages table:</p>
<p><img src="http://forge.typo3.org/attachments/download/26734/recycler-nonadmin.png" alt="" loading="lazy" /></p>
<p>The non-admin has modification rights to table pages and full write-access to the parent page of the deleted page.</p>
<p>Restoring tt_content items works.</p> TYPO3 Core - Bug #58914 (Closed): Cursor position is at the beginning of the segment after pastinghttp://forge.typo3.org/issues/589142014-05-19T12:12:34ZLorenz Ulrich
<p>When I insert text from the clipboard, the cursor position after pasting is always at the beginning of the segment, where I would expect it to be at the end of the inserted segment.</p>
<p>Tested in Chrome and Firefox.</p>