TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-05-27T20:30:33ZTYPO3 Forge
Redmine TYPO3 Core - Bug #27098 (Closed): Fatal error when downloading extension fileshttp://forge.typo3.org/issues/270982011-05-27T20:30:33ZJeff Segarsjsegars@alumni.rice.edu
<p>When attempting to download files from the "Edit Files" page in the Extension Manager, a fatal error occurs. This is because the downloadFile URL parameter is not decoded first.</p>
<pre>
#1270853980: TYPO3 Fatal Error: Error while trying to download the extension file...
RuntimeException thrown in file
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php in line 1677.
3 SC_mod_tools_em_index::showExtDetails("felogin")
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php:
00432: // Command given which is executed regardless of main menu setting:
00433: if ($this->CMD['showExt']) { // Show details for a single extension
00434: $this->showExtDetails($this->CMD['showExt']);
00435: } elseif ($this->CMD['requestInstallExtensions']) { // Show details for a single extension
00436: $this->requestInstallExtensions($this->CMD['requestInstallExtensions']);
2 SC_mod_tools_em_index::main()
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php:
02594: $SOBE->checkExtObj();
02595:
02596: $SOBE->main();
02597: $SOBE->printContent();
02598:
1 require("/usr/bin/wecsharedsource/typo3_src-trunk/typo3/sysext/em/classes/index.php")
/usr/bin/wecsharedsource/typo3_src-trunk/typo3/mod.php:
00049: require($temp_path . 'conf.php');
00050: $BACK_PATH = '';
00051: require($temp_path . 'index.php');
00052: $isDispatched = TRUE;
00053: } else {
</pre> TYPO3 Core - Bug #24864 (Closed): stdWrap .current and .setContentToCurrent do not return contenthttp://forge.typo3.org/issues/248642011-01-27T23:28:32ZJeff Segarsjsegars@alumni.rice.edu
<p>With the tslib_content refactoring in 4.5, we now have standalone methods for many pieces of stdWrap, which are chained together at the end of the main stdWrap method. Each standalone helper method takes the $content and $conf, processes it, and returns the $content.</p>
<p>stdWrap_setContentToCurrent() and stdWrap_setCurrent() do not return $content, however. This means that any stdWrap properties coming after these two do not have content to operate on.</p>
<p>(issue imported from #M17372)</p> TYPO3 Core - Bug #24802 (Closed): Admin Panel CSS is loaded in the Backendhttp://forge.typo3.org/issues/248022011-01-25T16:16:13ZJeff Segarsjsegars@alumni.rice.edu
<p>Since the admin panel CSS is at t3skin/visual/admin_panel.css, it is loaded with every backend request. Obviously, the admin panel is not needed in the backend so its a bit of a waste to load it.</p>
<p>In addition, the CSS has a strange issue that it interferes with resizable text areas in Chrome 9 (as described on <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Resizable textares not working in Chrome 9 (Closed)" href="http://forge.typo3.org/issues/24744">#24744</a>).</p>
<p>Moving the admin panel CSS to t3skin/standalone/admin_panel.css ensures that it is not loaded automatically by the backend.</p>
<p>(issue imported from #M17302)</p> TYPO3 Core - Bug #24692 (Closed): Live Search: Search query loops over all tables even after max ...http://forge.typo3.org/issues/246922011-01-20T22:10:23ZJeff Segarsjsegars@alumni.rice.edu
<p>When executing a live search, we loop over all tables defined in the TCA. After this search is complete, we then slice the search array and throw away everything we don't need.</p>
<p>For better performance, we should stop searching as soon as we've found enough results.</p>
<p>(issue imported from #M17177)</p> TYPO3 Core - Bug #24666 (Closed): Update plugin layout to match other content elementshttp://forge.typo3.org/issues/246662011-01-19T18:11:52ZJeff Segarsjsegars@alumni.rice.edu
<p>In TYPO3 4.5, we have a new layout for built in content elements and plugins. FE Login is a bit of a hybrid since it is a frontend plugin but replacing the old built in content element. To achieve this, it overrides the TCA showitem definition of the old login content element. This showitem definition should be updated to the 4.5 layout.</p>
<p>(issue imported from #M17147)</p> TYPO3 Core - Bug #23293 (Closed): Raw HTML shown in Element Browser's pagetree with options.pageT...http://forge.typo3.org/issues/232932010-07-28T22:35:10ZJeff Segarsjsegars@alumni.rice.edu
<p>When options.pageTree.showNavTitle = 1 is set, we get a little too much data htmlspecialchar'd and raw HTML is shown in the Element Browser's pagetree. See attached screenshot.</p>
<p>(issue imported from #M15273)</p> TYPO3 Core - Bug #21071 (Closed): Install Tool button in User Settings does not reflect current s...http://forge.typo3.org/issues/210712009-09-16T15:53:03ZJeff Segarsjsegars@alumni.rice.edu
<p>In User Settings we have a button to create or delete the ENABLE_INSTALL_TOOL file. The ENABLE_INSTALL_TOOL file itself is manually deleted on the first access when there's been an hour of inactivity and not immediately deleted when that hour of inactivity occurs. This leads to a User Settings button that doesn't really reflect the current state.</p>
<p>When an hour has passed since the last activity, the User Settings button will still offer the opportunity to delete the ENABLE_INSTALL_TOOL file despite the fact that the Install Tool will not be accessible if you try to browse to it directly.</p>
<p>The solution is to have User Settings update the timestamp on the existing ENABLE_INSTALL_TOOL file or delete the file completely if its more than an hour hold, just like the main Install Tool code.</p>
<p>(issue imported from #M11974)</p> TYPO3 Core - Bug #19490 (Closed): RTE uses JScodeLibArray to insert CSShttp://forge.typo3.org/issues/194902008-10-21T16:24:05ZJeff Segarsjsegars@alumni.rice.edu
<p>In tx_rtehtmlarea_base, the RTE uses $GLOBALS['SOBE']->doc->JScodeLibArray to insert CSS into the page header. This was added in revision 4298.</p>
<p>When using edit forms on the page in frontend editing, we don't have a true doc template and are just going through TCEForms instead. This means that adding Javascript (or CSS) through JScodeLibArray has no effect.</p>
<p>In bug <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Frontend Editing does not work anymore (Closed)" href="http://forge.typo3.org/issues/19485">#19485</a>, Olly added a separate loadJavascriptLib() method for frontend editing that inserts the Javascript libraries into TSFE but that won't be the correct solution for CSS files. I'd suggest falling back to $this->TCEform->additionalCode_pre as it was in the past or adding a generic loader into TCEForms.</p>
<p>I'm attaching a patch that uses $this->TCEform->additionalCode_pre and works correctly in my testing in both the frontend and backend (I am seeing problems with the RTE in IRRE child records but that seems to occur with and without my patch).</p>
<p>(issue imported from #M9613)</p> TYPO3 Core - Bug #19338 (Closed): XML Problems with PHP5 and libxml 2.7.1http://forge.typo3.org/issues/193382008-09-16T17:06:05ZJeff Segarsjsegars@alumni.rice.edu
<p>When using PHP5 with libxml 2.7.1, HTML entities are stripped from any XML content (FCEs, Flexforms, etc) when its saved or retrieved.</p>
<p>For things like RTE content, this means that "<LINK 43>Page with UID 43</LINK>" is not actually transformed into a link but instead renders in the frontend at "LINK 43Page with UID 43/LINK"</p>
<p>This also affects Flexible Content Elements if HTML entities were used for Typoscript assignments, such as "10 < styles.content.get". A previous working FCE and the assignment operator removed and thus renders no content at all.</p>
<p>For more information on the bug, see <a class="external" href="https://qa.mandriva.com/show_bug.cgi?id=43486">https://qa.mandriva.com/show_bug.cgi?id=43486</a> and <a class="external" href="http://bugs.php.net/bug.php?id=45996">http://bugs.php.net/bug.php?id=45996</a>.</p>
<p>It remains to be seen how widespread this issue will become or how quickly PHP will patch it, but one helpful option for new sites is to enable the useCDATA option from t3lib_div::array2xml. This will cause TYPO3 to insert CDATA anytime there are html entities within the content. Once CDATA is present, the new content will work as expected.</p>
<p>I'm attaching a one line patch that enables CDATA within flexform XML. There are several other places in the core that also use XML but the flexform part seems to be the most prominent.</p>
<p>(issue imported from #M9359)</p> TYPO3 Core - Bug #18901 (Closed): XHTML Validation Problems on Forgot Password Formhttp://forge.typo3.org/issues/189012008-06-03T17:22:46ZJeff Segarsjsegars@alumni.rice.edu
<p>The forgot password form has a minor XHTML validation problem when using the default template.</p>
<p>Both the label "for" attribute and the input ID are tied to ###FORGOT_EMAIL### (as is the input "name" attribute"). This marker evaluates as "tx_felogin_pi1[forgot_email]", but the brackets are not allowed in the ID or "for" attribute.</p>
<p>Changing the ID to forgot-email or something like that should clear up the issue, although it may introduce some small compatibility problems for people hooking CSS or Javascript onto the existing ID.</p>
<p>(issue imported from #M8600)</p> TYPO3 Core - Bug #18427 (Closed): Required fields within flexform section elements cause Javascri...http://forge.typo3.org/issues/184272008-03-11T19:29:42ZJeff Segarsjsegars@alumni.rice.edu
<p>If a flexform uses section elements with required fields, a Javascript error is generated as soon as the form is loaded and that flexform cannot be saved.</p>
<p>I believe this is related to changeset 2628, which made significant enhancements to section handling. To see the error in action, check out the Scoring Tab within the pb_survey plugin.</p>
<p>The error message is "document[TBE_EDITOR.formname][elementName] has no properties". Once the required eval is removed, the Javascript errors go away because the code causing the error is no longer executed.</p>
<p>(issue imported from #M7829)</p> TYPO3 Core - Bug #18422 (Closed): Task center iframes are only sized on loadhttp://forge.typo3.org/issues/184222008-03-10T21:35:39ZJeff Segarsjsegars@alumni.rice.edu
<p>Within the task center, iframes are used to include external content such as a TCE form for editing records as part of sys_action. These iframes have an onload attribute to set the height of the form, but this event handler could be improved.</p>
<p>Other iframes within the new backend are automatically resized when the browser window is resized (via Prototype event handlers) so the task center should get this same behavior.</p>
<p>(issue imported from #M7820)</p> TYPO3 Core - Bug #18279 (Closed): Several problems with locking API (t3lib_lock)http://forge.typo3.org/issues/182792008-02-22T20:20:57ZJeff Segarsjsegars@alumni.rice.edu
<p>The locking API has problems if an extension sets TSFE->set_no_cache().</p>
<p>When a page is rendered, a lock is generated as long as the page itself isn't set to be uncached. At this point in time, we know nothing about what individual extensions will do within page caching. When rendering completes, we again check to see if the page is marked as uncached, which it may be because of an extension setting TSFE->set_no_cache. If the page is now marked as uncached, we don't do anything with locks which in turn leaves us with an open lock. Subsequent reloads of the page will take approximately 30 seconds due to the open locks.</p>
<p>The attached patch fixes this issue by releasing the locks within TSFE->set_no_cache(). The patch also contains some debug output for more insight into the problem, but this should be removed before its committed.</p>
<p>I'm also attaching a test extension that contains a frontend plugin for setting TSFE->set_no_cache(). You can first try the plugin without the patch. Make sure you're not logged into the backend and page loads should take approximately 30 seconds. After applying the patch, it should be back to normal speeds.</p>
<p>(issue imported from #M7630)</p> TYPO3 Core - Bug #17546 (Closed): Default values not used in IRRE childrenhttp://forge.typo3.org/issues/175462007-08-21T01:48:07ZJeff Segarsjsegars@alumni.rice.edu
<p>When editing child records using IRRE, the TCA-defined defaults are not used. This is due to a small error in t3lib_tceforms_inline->getRecord().</p>
<p>The getRecord() method calls t3lib_transferdata->fetchRecord($table, $idList, $operation). According to comments on the fetchRecord method, "If $operation is "new", then negative ids are meant to point to a "previous" record and positive ids are PID values for new records. Otherwise (for existing records that is) it is straight forward table/id pairs.".</p>
<p>I updated the call to fetchRecord() so that it passes along the pid when $operation is "new" and this causes defaults to be set properly in my testing.</p>
<p>I'm attaching the one line patch to fix this.</p>
<p>(issue imported from #M6183)</p> TYPO3 Core - Bug #15354 (Closed): Import of testsite from T3D exceeds PHP maximum_execution_timehttp://forge.typo3.org/issues/153542006-01-03T17:56:04ZJeff Segarsjsegars@alumni.rice.edu
<p>When testing the import of a T3D-based testsite package on my local install, I bumped up against PHP's maximum_execution_time of 30 seconds. Once I raised this limit in php.ini, the import worked properly.</p>
<p>At Michael Stucki's suggestion, I revert to the original php.ini and added "ini_set('max_execution_time', 300);" to the top of typo3conf/localconf.php, which also fixed the timeout problems.</p>
<p>Adding ini_set to the impexp system extension should fix this issue.</p>
<p>(issue imported from #M2169)</p>