TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-08-27T15:13:32ZTYPO3 Forge
Redmine TYPO3 Core - Feature #29296 (Closed): Add possibility to define foreign_match_fields for IRRE inl...http://forge.typo3.org/issues/292962011-08-27T15:13:32ZIngmar Schlechtingmar@typo3.org
<p>This patch request adds the possibility to define foreign_match_fields (similar to MM_match_fields) for IRRE inline relations. This is required for the upcoming file abstraction layer in TYPO3.</p>
<p>New documentation:</p>
<p>For TYPO3 Core API, Chapter: ['columns'][fieldname]['config'] / TYPE: "inline"</p>
<p><a class="external" href="http://typo3.org/documentation/document-library/core-documentation/doc_core_api/4.3.0/view/4/2/#id2529282">http://typo3.org/documentation/document-library/core-documentation/doc_core_api/4.3.0/view/4/2/#id2529282</a></p>
<p>parameter name: foreign_match_fields<br />parameter type: array<br />parameter description: Array of field=>value pairs to both insert and match against when writing/reading IRRE relations. This feature is useful if you want to use the same child table in two inline fields within the same parent table. In that case you can then define an "identifier" field in the child record to distinguish the two relations.</p> TYPO3 Core - Bug #23731 (Closed): Felogin shouldn't show the permalogin form controls when permal...http://forge.typo3.org/issues/237312010-10-14T18:32:31ZIngmar Schlechtingmar@typo3.org
<p>The subject says it all:</p>
<p>Felogin shouldn't show the permalogin form controls when permalogin is set to "forced on" in intall tool.</p>
<p>(issue imported from #M15993)</p> TYPO3 Core - Bug #23730 (Closed): Incorrect default value of permaloginhttp://forge.typo3.org/issues/237302010-10-14T18:30:47ZIngmar Schlechtingmar@typo3.org
<p>The default value of permalogin (2) in config_default at the moment doesn't make sense and should be corrected.</p>
<p>0, which means "by default off, but can be enabled by a form control" is the best for most situations and should therefore be used as new default.</p>
<p>(issue imported from #M15992)</p> TYPO3 Core - Bug #25623 (Closed): Various small issueshttp://forge.typo3.org/issues/256232009-10-12T14:40:00ZIngmar Schlechtingmar@typo3.org
<p>Some language string mistakes / typos:</p>
<p>- two verbs in the following sentence: "The script to execute to run the Scheduler from the command line is"</p>
<p>- missing word "to" in "The webserver user is not allowed execute this script."</p>
<p>- the message is misleading in Windows and should be removed for Windows: "The webserver user is not allowed execute this script."</p>
<p>- wrong indentation in the file mod1/index.php in line 364 (starts with $dateFormat )</p>
<p>(issue imported from #M12211)</p> TYPO3 Core - Bug #25621 (Closed): Creation of late taskhttp://forge.typo3.org/issues/256212009-10-10T11:27:40ZIngmar Schlechtingmar@typo3.org
<p>I have a question (or maybe a feature request) regarding the creation of single (not recurring) tasks.</p>
<p>When I enter a date as "start date" that lies in the past, the BE module detects that and on-save changes the record to "disabled". So directly after saving the status of the newly created task is "Disabled, will not be executed, except manually".</p>
<p>Wouldn't it be nicer if it was instead "Late, will run with next execution"? I think people would expect that and also it would be a very convenient way to make tasks execute at the next occasion: Just set the date to something in the past, and it will appear as "Late".</p>
<p>(issue imported from #M12177)</p> TYPO3 Core - Bug #15188 (Closed): EM doesn't check for dependancies on Extension updatehttp://forge.typo3.org/issues/151882005-11-08T06:19:01ZIngmar Schlechtingmar@typo3.org
<p>The EM doesn't check for dependancies when you upgrade an extension.</p>
<p>That causes the following error message when you update from an older version of tt_products to the latest: "TYPO3 Fatal Error: Extension key "fh_library" was NOT loaded! (t3lib_extMgm::extPath)".</p>
<p>(issue imported from #M1807)</p> TYPO3 Core - Bug #14655 (Closed): require_once() instead of require() should be used in entry scr...http://forge.typo3.org/issues/146552005-04-09T16:51:56ZIngmar Schlechtingmar@typo3.org
<p>In showpic.php, index_ts.php, typo3/init.php TYPO3 uses the PHP function require() to include classes like t3lib_div.<br />Later on in the process, there are some other files included having a line like this:<br />require_once(PATH_t3lib.'class.t3lib_div.php');</p>
<p>Normally the fact that t3lib_div was already included earlier should not cause any problems because require_once() should only include if the class wasn't already included, but it seems like the behaviour of that function changed in a recent PHP version, so that require_once() now DOES include files which have already been included with require(). The solution would be to change also the FIRST inclusions from require() to require_once().</p>
<p>According to Rupert Germann, this bug only occurs when a PHP accelerator is enabled.</p>
<p>A typical PHP error message resulting from this problem is this:<br />PHP Fatal error: Cannot redeclare class t3lib_div in /www/htdocs/_data/typo3.com/typo3_src-3.8.0-dev-cvs/t3lib/class.t3lib_div.php on line 209<br />(issue imported from #M958)</p> TYPO3 Core - Bug #14263 (Closed): Path problems with PHP5http://forge.typo3.org/issues/142632004-08-04T10:19:18ZIngmar Schlechtingmar@typo3.org
<p>Typo3 shows the error message "Cannot find configuration. This file is probably executed from the wrong location." on PHP5 systems.</p>
<p>The reason for this is, that PHP5 doesn't support these $HTTP_*_VARS by default, however, it can be configured to do so.</p>
<p>Typo3 will have to be reviewed for these vars and changed accordingly.<br />(issue imported from #M273)</p> TYPO3 Core - Feature #14254 (Closed): Moving repetitive elementshttp://forge.typo3.org/issues/142542004-07-27T10:43:35ZIngmar Schlechtingmar@typo3.org
<p>This is a fix for Typo3-3.7-dev to enable moving repetitive flexform elements.</p>
<p>Just replace the two class files with your files in the typo3/t3lib/ folder.</p>
<p>(Optionally you can also patch your class files with the .diff patches attached to this bug.)<br />(issue imported from #M251)</p> TYPO3 Core - Feature #14253 (Closed): Setlocale does not work when page is cachedhttp://forge.typo3.org/issues/142532004-07-26T18:03:46ZIngmar Schlechtingmar@typo3.org
<p>Setlocale seems not to be executed when page is cached.<br />That results in wrong locales for non cached content like advCalendar.</p>
<p>(issue imported from #M250)</p> TYPO3 Core - Bug #14252 (Closed): Highlighting color of module should be same as highlighting col...http://forge.typo3.org/issues/142522004-07-26T14:21:28ZIngmar Schlechtingmar@typo3.org
<p>When you click on a module in the backend of Typo3 3.7 (!), the module you clicked is highlighted. However, it is highlighted in a different color to the color a page is highlighted when you click it.<br />This should be changed in the default stylesheet.</p>
<p>(issue imported from #M248)</p> TYPO3 Core - Feature #14240 (Closed): A memory_limit of NULL should be interpreted as "no limit" ...http://forge.typo3.org/issues/142402004-07-15T14:40:48ZIngmar Schlechtingmar@typo3.org
<p>Well, the subject line basically says it:<br />A memory_limit of NULL should be interpreted as "no limit" instead of 0 MB.</p>
<p>(issue imported from #M218)</p> TYPO3 Core - Bug #14201 (Closed): SafeMode detection issuehttp://forge.typo3.org/issues/142012004-06-12T13:12:15ZIngmar Schlechtingmar@typo3.org
<p>According to a report on <a class="external" href="http://www.typo3.net/viewtopic.php?p=43617">http://www.typo3.net/viewtopic.php?p=43617</a> Typo3 install tool sometimes claims SafeMode would be turned on although it isn't.</p>
<p>I suspect this is very similar to the SSL detection bug:<br /><a class="external" href="http://bugs.typo3.org/bug_view_page.php?bug_id=0000062">http://bugs.typo3.org/bug_view_page.php?bug_id=0000062</a><br />(issue imported from #M155)</p> TYPO3 Core - Bug #14139 (Closed): Install tool is incapable of comparing modern database dumpshttp://forge.typo3.org/issues/141392004-05-03T22:29:12ZIngmar Schlechtingmar@typo3.org
<p>When I use the "Database Analyzer" of the Typo3 install tool to compare the current database to the file typo3conf/database.sql it shows me lots of differences although the current database is in fact exactly the same as the database.sql file so there should NOT be ANY difference.</p>
<p>When I look closer at it, I see that the only differences Typo3 finds is the order of things.</p>
<p>It says it needs to do this...<br /> ALTER TABLE be_groups CHANGE tstamp tstamp <br /> int(11) unsigned NOT NULL default '0';</p>
<p>...because the current value is this:<br /> int(11) unsigned DEFAULT '0' NOT NULL</p>
<p>This bug is present in the install tool as well as in the extension manager.</p>
<p>I might be able to provide a fix for this when I've got some spare time, so I'll assign this bug to me.<br />(issue imported from #M55)</p> TYPO3 Core - Bug #14104 (Closed): Test. Ignore!http://forge.typo3.org/issues/141042004-04-26T12:51:08ZIngmar Schlechtingmar@typo3.org
<p>This is a test bug description.</p>
<p>no additional information available.<br />(issue imported from #M7)</p>