TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-04-15T16:25:03ZTYPO3 Forge
Redmine TYPO3 Core - Bug #84735 (Closed): InlineControlContainer wrongly assumes group field values are s...http://forge.typo3.org/issues/847352018-04-15T16:25:03ZFranz Kochtypo3@elements-net.de
<p>The inlineControlContainer wrongly assumes that fields of type "group" still have the "_tablename|id|..." string as field value in "databaseRow", but this value is already converted into an array by the TcaGroup FromDataProvider.</p>
<p>See <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/backend/Classes/Form/Container/InlineControlContainer.php#L198">https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/backend/Classes/Form/Container/InlineControlContainer.php#L198</a> for the according code in InlineControlContainer.</p>
<p>Affected versions are 8.7 and current master</p> TYPO3 Core - Bug #82114 (Closed): OnlineMedia Processing forces FAL drivers to extend AbstractDriverhttp://forge.typo3.org/issues/821142017-08-16T14:29:06ZFranz Kochtypo3@elements-net.de
<p>FAL drivers are not obligated to extend the AbstractDriver but only to implement the DriverInterface. Having custom drivers that are not based on AbstractDriver (because they are f.e. non hierarchical) currently causes an Exception because \TYPO3\CMS\Core\Resource\OnlineMedia\Processing\PreviewProcessing expects an instance of AbstractDriver as method argument and not DriverInterface.</p>
<p>Patch/fix is already on Gerrit. Ticket only for reference.</p> TYPO3 Core - Bug #61830 (Closed): Localization of file references brokenhttp://forge.typo3.org/issues/618302014-09-24T05:16:09ZFranz Kochtypo3@elements-net.de
<p>The LocalizationUtility from Extbase is using $GLOBALS['TSFE']->sL to translate translateFileReference passed to it, but this is no longer available and thus these translations fail. Removing the FE special case and using $GLOBALS['LANG'] instead.</p>
<p>Before:<br /><pre>
static protected function translateFileReference($key) {
if (TYPO3_MODE === 'FE') {
$value = $GLOBALS['TSFE']->sL($key);
return $value !== FALSE ? $value : NULL;
} elseif (is_object($GLOBALS['LANG'])) {
$value = $GLOBALS['LANG']->sL($key);
return $value !== '' ? $value : NULL;
} else {
return $key;
}
}
</pre></p>
<p>after:<br /><pre>
static protected function translateFileReference($key) {
if (is_object($GLOBALS['LANG'])) {
$value = $GLOBALS['LANG']->sL($key);
return $value !== '' ? $value : NULL;
} else {
return $key;
}
}
</pre></p> TYPO3 Core - Bug #61617 (Closed): Absolute publicUrls of images are prepended with relative prefixeshttp://forge.typo3.org/issues/616172014-09-15T18:11:53ZFranz Kochtypo3@elements-net.de
<p>The ImageService->getImageUri() method prepends the publicUrl of file objects with prefixes without checking if the URL is already absolute. I stumbled over this issue because the FAL driver I have implemented is connecting an external image database where the images are hosted externally and local processing is not allowed.</p> TYPO3 Core - Bug #61261 (Closed): Edit icons in FAL filelist and context menus are missing permis...http://forge.typo3.org/issues/612612014-08-29T10:30:24ZFranz Kochtypo3@elements-net.de
<p>In filelist as well as in context menus the edit/info/cut/copy/paste icons are always shown and not disabled/removed if related FAL object doesn't allow these actions.</p> TYPO3 Core - Bug #35787 (Closed): Subject can't be set with the form wizardhttp://forge.typo3.org/issues/357872012-04-09T04:35:49ZFranz Kochtypo3@elements-net.de
<p>Unlike to the old form system, editors now can't set the email subject using the form content element/wizard. Having to add the subject manually to the TS is nothing editors should have to deal with and I consider this more to be a bug then a missing feature. So please add a 3rd input field to the mail postProcessor JS alongside recipientEmail and senderEmail. Easy task, big benefit for editors.</p> TYPO3 Core - Task #6249 (Closed): Support for TCA fields of type "group" - allowes DAM support (...http://forge.typo3.org/issues/62492010-01-27T15:18:12ZFranz Kochtypo3@elements-net.de
<p>Hi, extbase currently doesn't support TCA fields of type "group" natively. A easy workaround currently is to additionally define a "foreign_table" in your columns configuration together with a MM relation of course (no comma separated lists).</p>
<p>But unfortunately this little trick doesn't work together with DAM relations and probably some other multicolumn relations, because DAM itself is not configuring all MM_match_fields (tablenames missing by default) and is letting TYPO3 do the job of filling in the correct 'tablenames' match fields in MM relations. This patch is a first attempt to do in extbase the same as TYPO3 does in the backend. So with this patch you get:</p>
<p>- native support of group fields (type: group, interal_type: db, allowed: onlyOneTableNameSoFar)<br />- handling of multi-table relations like the CORE of TYPO3 does (adding tablenames if needed)</p>
<p>With this patch applied, DAM relations will work by default.</p>
<p>What will not work:<br />Retrieving/persisting objects to multiple tables for a single db field (so more then one allowed relation table, like the RECORDS CType of TYPO3 is using). To support this, some major rework is needed I think, that should/could be done together with singleTableInheritance.</p> TYPO3 Core - Bug #19545 (Closed): Moving page in WS will hide it from editors due to missing acce...http://forge.typo3.org/issues/195452008-10-31T11:37:42ZFranz Kochtypo3@elements-net.de
<p>I've got several editors that are limited to a certain subtree of the website. Every editor is 'locked' in the same custom workspace - so that they can't mess things up in live version.</p>
<p>Every subtree has the following access settings:<br />- owner: all rights<br />- group: all rights<br />- all: no rights - not even viewing</p>
<p>Now, when a editor is moving a page in his subtree, the page finally disappears in the pagetree. As admin I still can see the page and the WS-Placeholder created for it, but the placeholder has no access configuration at all - thus it's disallowed for all users. By setting the placeholers access rights, the editors finally can see the moved page in the workspace pagetree again.</p>
<p>In pageTS I defined a default usergroup and access-settings to use for new pages - but they don't get used for the WS-placeholder. Also TCAdefaults didn't work. <br />But the placeholder should have the same access settings as it's related page and not fall back to some default value anyway.</p>
<p>So I digged the source and found a solution that's working for me. Hope it's fixed in the right place and the correct way.</p>
<p>(issue imported from #M9705)</p> TYPO3 Core - Bug #19370 (Closed): "Do"-Dropdown doesn't respect current user's rights and is not ...http://forge.typo3.org/issues/193702008-09-23T18:00:03ZFranz Kochtypo3@elements-net.de
<p>The new "do" dropdown in the workspace module doesn't respect the users rights and is always showing all options - which is quite confusing for editors. Second thing is that it's not localized.</p>
<p>I've started recoding this and now the dropdown is only showing the options the current user is allowed to do. I also started localizing it - but some needed language labels where not present in locallang file and I didn't know what the best way would be to add the needed ones - so localizing still needs to be done after applying the patch.</p>
<p>(issue imported from #M9415)</p> TYPO3 Core - Bug #18605 (Closed): defect wsid check in workspace-overlay delivering wrong record ...http://forge.typo3.org/issues/186052008-04-11T12:57:16ZFranz Kochtypo3@elements-net.de
<p>The method t3lib_BEfunc::workspaceOL is using a defect check for the current workspace-id with the following sideeffect:</p>
<p>When you have a page in various versions (through versioning) and are working in LIVE-Workspace, the method will overlay the current live version of the record with a older, outdate version.</p>
<p>This happened to me, when I was trying to fetch a pageTS for a certain page and the setting I needed to check did not show up although I defined it in pageTS. Then I started debugging and found this bug.</p>
<p>Sidenote: I set the TYPO3-version for this bug to 4.2 in order to get that fixed for 4.2, but the bug itself is also present in 4.1.5 and probably some versions earlier. <br />(issue imported from #M8092)</p> TYPO3 Core - Bug #18554 (Closed): not longer possible to use non-integer uids for fake treeitems ...http://forge.typo3.org/issues/185542008-04-03T14:47:00ZFranz Kochtypo3@elements-net.de
<p>Due to a codechange in 4.1.x it's no longer possible to use non-integer uid values for the tree-data. When a non-integer value is used, a TYPO3 error is shown and the script is exiting/crashing. In my case I'm using a mixture of strings and integers as keys (alphabetic grouped usernames) and since I updated to TYPO3 4.1.x this is no longer possible (worked with 4.0.2 f.e.).</p>
<p>The line causing this is line 773 of class.t3lib_treeview.php (current SVN, TYPO3 4.2 trunk):<br />if ($newID==0) {</p>
<p>This line has to be changed in one of the two ways in order to get this back working:<br />a) if ($newID=='0') {<br />b) if(empty($newID) {</p>
<p>Would be nice if this could be changed to get it working again.</p>
<p>(issue imported from #M8006)</p> TYPO3 Core - Bug #16148 (Closed): IFSUB and ACTIFSUB of Menus fails with pagetype shortcut as sub...http://forge.typo3.org/issues/161482006-05-15T15:29:21ZFranz Kochtypo3@elements-net.de
<p>This bug is related due to missing SQL-Query-Result fields in the function "getMenu()" (in class.t3lib_page.php) called by function "isSubMenu" from "class.tslib_menu.php". <br />The function getMenu provides a function-variable (operator? - I'm no developer) in which the whished fields for the result rows can be given. Nice feature, but the problem is that the function also does the submenu check (ISSUB etc.) and therefore needs certain fields in the result row. If these are not part of the values passed in the function call, those checks will always fail (which currently does).</p>
<p>Therefore there are 2 possible solutions:<br />Either parse the field-values passed to the function variable with a t3lib_div::uniqueInList($passed_fields.",".$required_fields_by_function_itself) or simply add those fields to the functioncall in line 1343 of class "class.tslib_menu.php".<br />The missing fields in the function call are "shortuct" and "shortcut_mode".</p>
<p>(issue imported from #M3493)</p> TYPO3 Core - Bug #15769 (Closed): NO/wrong language-merging for cType RECORDS - (so also not for ...http://forge.typo3.org/issues/157692006-03-06T14:30:28ZFranz Kochtypo3@elements-net.de
<p>I think I just found a bug with 'sys_language_mergeIfNotBlank' but I must say I'm a little confused currently of the way it is handled.</p>
<p>When fetching content with cType CONTENT, the query for selecting the content elements is built by a function 'tslib_content::getWhere' which (and only if $conf['languageField'] is expicit defined) switches the language-selection in the where-clause from the current sys_language to '0,-1' (default,all languages) which means that you get the content-element in the default language back and not the originaly asked one.</p>
<p>This element is later (in cType CONTENT) passed to another if-clause that merges the actual current sys_language over the given one, which HAS TO BE either 'default' or 'all languages' (therefore it had been switched before).</p>
<p>Isn't that double-reverse-thing a little unhandy?</p>
<p>Well, I think it is, as in this way it is impossible to get language-merged content-elements that are not passed through the CONTENT cType, which would be for example cType RECORDS. Because cType RECORDS can have direct references to translated content-elements which aren't fetched over the before mentioned function 'tslib_content::getWhere' which reverses the language.</p>
<p>So you will most likely not get language-merged content-elements over the function call 't3lib_page::getRecordOverlay' in cType RECORDS which leads to a big problem with all TemplaVoila sites, that fecht almost every content over cType RECORDS.</p>
<p>I stumbled over this as I coulnd't get 'sys_language_mergeIfNotBlank' work in TemplaVoila but it has worked with common rendering (page.30 < styles.content.get).</p>
<p>I'm no core developer, so I don't know what the actual idea was behind this double-language-conversion whatever thing, but I think it would be much wiser to remove this language conversion stuff and handle the overlay in one central function, which would be 't3lib_page::getRecordOverlay'.</p>
<p>The second thing is:<br />Currently the 'language conversion' in 'tslib_content::getWhere' is <em>ONLY</em> done when the given $conf-Array contains a field called 'languageField'. As I don't think that every developer is aware of this wouldn't it be better to simply check the TCA for the definition of that field (as it is done one line after: 6586, class.tslib_content.php) and optional check an override of the variable 'languageField'?</p>
<p>Here are my changes to my local system that made it work as it is supposed to be. I testet it with workspaces, versioning and language content-fallback. Everything seems to be ok, but it would be good if more people with different setups could test it before implementing in core.</p>
----- class.tslib_content.php around line 6584 ------------
<ol>
<li>from:<br /> if ($conf['languageField']) {<br /> if ($GLOBALS['TSFE']->sys_language_contentOL && $TCA[$table] && $TCA[$table]['ctrl']['languageField'] && $TCA[$table]['ctrl']['transOrigPointerField']) {<br /> // Sys language content is set to zero/-1 - and it is expected that whatever routine processes the output will OVERLAY the records with localized versions!<br /> $sys_language_content = '0,-1';<br /> } else {<br /> $sys_language_content = intval($GLOBALS['TSFE']->sys_language_content);<br /> }<br /> $query.=' AND '.$conf['languageField'].' IN ('.$sys_language_content.')';<br /> }</li>
</ol>
<ol>
<li>to:<br /> if($TCA[$table] && ($TCA[$table]['ctrl']['languageField'] || $conf['languageField'])) {<br /> $lField = $conf['languageField']? $conf['languageField'] : $TCA[$table]['ctrl']['languageField'];<br /> $query.=' AND '.$lField.' IN ('.$GLOBALS['TSFE']->sys_language_content.')';<br /> }<br />-----------------------------------------------------------<br />maybe a additional check should be added if the defined 'languageField' in $conf really exists in $TCA[$table]['columns'].</li>
</ol>
----- class.t3lib_page.php line 324 -----------------------
<ol>
<li>from: if ($row[$TCA[$table]['ctrl']['languageField']]<=0) {</li>
<li>to: if ($row[$TCA[$table]['ctrl']['languageField']] > 0) {<br />-----------------------------------------------------------</li>
</ol>
----- class.t3lib_page.php around line 330-----------------
<ol>
<li>from:<br />' AND '.$TCA[$table]['ctrl']['languageField'].'='.intval($sys_language_content).<br />' AND '.$TCA[$table]['ctrl']['transOrigPointerField'].'='.intval($row['uid']).</li>
</ol>
<ol>
<li>to:<br />' AND '.$TCA[$table]['ctrl']['languageField'].' IN (0,-1)'.<br />' AND uid='.intval($row['l18n_parent']).<br />-----------------------------------------------------------</li>
</ol>
----- class.t3lib_page.php around line 345-----------------
<ol>
<li>from:<br />if ($fN!='uid' && $fN!='pid' && isset($olrow[$fN])) {<br /> if ($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]!='exclude'<br /> && ($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]!='mergeIfNotBlank' || strcmp(trim($olrow[$fN]),''))) {<br /> $row[$fN] = $olrow[$fN];<br /> }<br />}</li>
</ol>
<ol>
<li>to:<br />if ($fN!='uid' && $fN!='pid' && isset($row[$fN])) {<br /> if (($GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]=='exclude'
|| $GLOBALS['TSFE']->TCAcachedExtras[$table]['l10n_mode'][$fN]=='mergeIfNotBlank') && !strcmp(trim($row[$fN]),'')) {<br /> $row[$fN] = $olrow[$fN];<br /> }<br />}<br />-----------------------------------------------------------</li>
</ol>
<p>I'll provide diff-files as soon as I know how to create them correct.<br />(issue imported from #M2773)</p> TYPO3 Core - Bug #15700 (Closed): Wrong hardcoded path to fileicons in class.tslib_content.phphttp://forge.typo3.org/issues/157002006-02-22T15:37:16ZFranz Kochtypo3@elements-net.de
<p>I just tested 4.0 beta3 and noticed that the fileicons where missing in the content-elements "uploads". The hardcoded path in "sysext/cms/tslib/class.tslib_content.php" on line 3843 is wrong.</p>
<p>Wrong: <br />$iconP = t3lib_extMgm::siteRelPath('cms').'media/fileicons/';</p>
<p>Correct:<br />$iconP = t3lib_extMgm::siteRelPath('cms').'tslib/media/fileicons/';</p>
<p>At least works for me on windows, zip-package. Couldn't check the linux-package, but as it should be the same now (no symlinks) the bug should be there, too.</p>
<p>but as this should become customizable anyway, maybe this bug will become obsolete</p>
<p>featurerequest for customizable icon-path see bug 1378:<br /><a class="external" href="http://bugs.typo3.org/view.php?id=1378">http://bugs.typo3.org/view.php?id=1378</a></p>
<p>(issue imported from #M2667)</p> TYPO3 Core - Bug #15666 (Closed): Old logo and "skin" in install-tool and install-wizardhttp://forge.typo3.org/issues/156662006-02-18T11:33:57ZFranz Kochtypo3@elements-net.de
<p>I just added this "bug" as I'm testing the new 4.0 Beta3 and noticed that the install-tool as well as the install-wizard don't yet show the new skin and logo.</p>
<p>Searched for this bug here, but dind't find it.</p>
<p>(issue imported from #M2618)</p>