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 - Bug #22862 (Closed): t3lib_utility_client is not working with php 5.2.0http://forge.typo3.org/issues/228622010-06-10T20:08:19ZFranz Kochtypo3@elements-net.de
<p>the preg_match_all pattern used to get the client information is using named subpatterns that are not compatible with php 5.2.0 but only php 5.2.2. Changing their spelling from '?<browser>' to '?P<browser>' does solve the issue.</p>
<p>(issue imported from #M14692)</p> TYPO3 Core - Bug #22724 (Closed): prioriCalc no longer working correctly after #0013670 (Performa...http://forge.typo3.org/issues/227242010-05-27T02:31:52ZFranz Kochtypo3@elements-net.de
<p>As the topic already says, the changes in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Performance optimization: change while(list() to foreach() (Closed)" href="http://forge.typo3.org/issues/22194">#22194</a> broke prioriCalc. The replacement of the while(list()) in method "calcPriority" of class.t3lib_div.php cause a wrong calculation.<br />Solution would be either to revert the changes from <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Performance optimization: change while(list() to foreach() (Closed)" href="http://forge.typo3.org/issues/22194">#22194</a> for class.t3lib_div.php or apply my attached patch, that's keeping the "foreach" loop instead "while(list())" but fixes the issue.</p>
<p>(issue imported from #M14488)</p> TYPO3 Core - Bug #21924 (Closed): suggest wizard does not work properly with TCA fields of type "...http://forge.typo3.org/issues/219242010-01-07T19:05:00ZFranz Kochtypo3@elements-net.de
<p>Also the pending documentation claims that the new suggest wizard is working nicely with group and select fields, it's not the case for select fields for two reasons:<br />a) 'foreign_table' is not taken into account for the search, only 'allowed' which is not present in select field configurations by default</p>
<p>b) once a) is fixed, the JS part of the suggest box is handling the search results wrong because the ID values of the generated option fields always have the tablename prepended as it's needed for group fields, but not select fields</p>
<p>The attached patch has as first step a patch for a). I didn't have a closer look at the JS part yet - maybe if one who knows what to do could provide a patch for the JS? Thanks.</p>
<p>The attatched patch is also introducing a new configuration option for the wizard, that allows to define additional search fields in which the wizard should search in.<br />(issue imported from #M13172)</p> TYPO3 Core - Bug #20481 (Closed): calls to deprecated method t3lib_div::makeInstanceClassnamehttp://forge.typo3.org/issues/204812009-05-20T14:03:48ZFranz Kochtypo3@elements-net.de
<p>In addition to ticket <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: tslib_content calls deprecated function makeInstanceClassName (Closed)" href="http://forge.typo3.org/issues/20257">#20257</a> there are some other places in the core that still use calls to t3lib_div::makeInstanceClassName. This patch is fixing those.</p>
<p>(issue imported from #M11154)</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 #17029 (Closed): SQL-Error on MySQL4http://forge.typo3.org/issues/170292007-02-23T12:03:46ZFranz Kochtypo3@elements-net.de
<p>When the flag 'Enable extensions without review (basic security check)' is activated there are no search results in the EM. In a small debug-session I found out that the a SQL-statement is not compatible with my MySQL 4.1.4 installation. It all worked with RC1, so I suppose the bug is due to the latest changes from Karsten. To make it work with MySQL4 again, the term only has to be in brackets - see below.</p>
<p>PS: I hope that I categorized this report correctly as blocker for 4.1</p>
<p>In class.em_xmlhandler.php line 74:</p>
<p>----Current - not working----<br /> $where.= ' AND NOT reviewstate < 0';<br />-------------------------------------</p>
<p>----working----------------------<br /> $where.= ' AND NOT (reviewstate < 0)';<br />-------------------------------------<br />(issue imported from #M5055)</p>