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 #24810 (Closed): CSH popup windows for FlexForm fields do not show field labelhttp://forge.typo3.org/issues/248102011-01-25T19:01:44ZJeff Segarsjsegars@alumni.rice.edu
<p>When using CSH for FlexForms, the popup window does not show the field label in the header like it does for normal fields. Instead, a path such as tt_content.pi_flexform.myext_pi1.list: myField is shown.</p>
<p>(issue imported from #M17310)</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 #23401 (Closed): Flexform sections cannot be deleted in frontend editinghttp://forge.typo3.org/issues/234012010-08-18T22:10:12ZJeff Segarsjsegars@alumni.rice.edu
<p>When using feedit or feeditadvanced, flexform sections cannot be deleted.</p>
<p>In t3lib_tceforms->getSingleField_typeFlex_draw(), a special hidden form field is created to pass along the name of the element being deleted. In a backend context, itemFormElName is data. In a frontend context, its TSFE_EDIT[data].</p>
<p>$actionFieldName = '_ACTION_FLEX_FORM'.$PA['itemFormElName'].$s<sup><a href="#fn0">0</a></sup>.'][_ACTION]['.$s<sup><a href="#fn1">1</a></sup>;</p>
<p>In t3lib_tcemain->checkValueFlex(), the check is hardcoded to rely on the backend version.</p>
<p>$actionCMDs = t3lib_div::_GP('_ACTION_FLEX_FORMdata');</p>
<p>The "data" portion should not be hardcoded and the t3lib_tcemain should not read directly from the GET/POST data.</p>
<p>(issue imported from #M15496)</p> TYPO3 Core - Bug #22876 (Closed): Automatically create ENABLE_INSTALL_TOOL file when 1-2-3 Instal...http://forge.typo3.org/issues/228762010-06-14T18:59:11ZJeff Segarsjsegars@alumni.rice.edu
<p>When a new user first installs TYPO3, they must create the ENABLE_INSTALL_TOOL file before installation can continue. For a friendlier first install, it would be nice to automatically create the file and go directly to the 1-2-3 Install Tool</p>
<p>Solution:<br />Just before the tslib_fe redirects to the 1-2-3 Install Tool, we can create the missing ENABLE_INSTALL_TOOL file.</p>
Notes:
<ul>
<li>This file will be created anytime there's a redirect to the 1-2-3 Install Tool and not just on initial install. In practice, this should only happen for the initial install but there's no check to prevent it at other times (if anyone thinks this a problem)</li>
</ul>
<ul>
<li>typo3/install/index.php handles the check for the ENABLE_INSTALL_TOOL file and the rest of TYPO3 is not yet initialized at this point so that forces us to create the file as part of the tslib_fe redirect or do a more complex rework of typo3/install/index.php.</li>
</ul>
<p>(issue imported from #M14719)</p> TYPO3 Core - Bug #22378 (Closed): "Check for extension updates" does not always find latest versionhttp://forge.typo3.org/issues/223782010-04-05T18:37:06ZJeff Segarsjsegars@alumni.rice.edu
<p>The "Check for extension updates" in the Extension Manager does not always find the latest version due to a bad expectation of the sort order.</p>
<p>In SC_mod_tools_em_index->showExtensionsToUpdate() we get a list of versions for a particular extension and the latest version is assumed to be the last entry in the versions array. This array is not necessarily sorted by version number however, so a simple natsort() will make sure that it is.</p>
<p>To duplicate the issue, ensure that you're on a TemplaVoila version prior to the 1.4.2 release. When you "Check for extension updates", you'll see 1.4.1 as the latest version. Searching for templavoila from the "Import extensions" submodule will reveal 1.4.2 however.</p>
<p>(issue imported from #M14003)</p> TYPO3 Core - Bug #19980 (Closed): Clean up frontend editing actionshttp://forge.typo3.org/issues/199802009-02-06T21:08:18ZJeff Segarsjsegars@alumni.rice.edu
<p>The frontend editing actions in t3lib_frontendedit have some small inconsistencies and duplicated code that can be cleaned up.</p>
<p>Calling editing actions based directly on the frontend editing cmd (ie. edit <del>> $this</del>>edit()) can cause problems with reserved keywords. While this isn't a problem in the current code, the frontend editing controller is extensible so an additional controller that needs to handle the 'new' cmd would have problems. This is fixed by prepending the cmd with 'do' instead (ie. edit <del>> $this</del>>doEdit()).</p>
<p>Additionally, inconsistencies with saving and duplicated code in the various move functions have been addressed.</p>
<p>(issue imported from #M10372)</p> TYPO3 Core - Bug #19798 (Closed): Cannot Load Multiple RTEs via AJAXhttp://forge.typo3.org/issues/197982009-01-12T18:23:44ZJeff Segarsjsegars@alumni.rice.edu
<p>In the new frontend editing concept for 4.3, we're loading the RTE via AJAX and displaying it in a lightbox. <br />On the first load of the RTE, HTMLArea._editorEvent is created as a generic event handler. When the RTE is closed, the HTMLArea.cleanup() method is called to free many variables, including HTMLArea._editorEvent which is set to null. This causes problems with the second RTE load when HTMLArea has already been initialized but _editorEvent is now null rather than a true method.</p>
<p>The solution is to remove the null assignment in HTMLArea.cleanup(). At the same time, the null assignment for HTMLArea.onload can be removed also since it could cause similar issues.</p>
<p>(issue imported from #M10105)</p> TYPO3 Core - Bug #18671 (Closed): Broken icons when creating +ext templatehttp://forge.typo3.org/issues/186712008-04-22T20:34:32ZJeff Segarsjsegars@alumni.rice.edu
<p>When creating a +ext template, the warning icons next to each button are broken. There's icon HTML has a duplicated src tag and the file path is slightly off.</p>
<p>(issue imported from #M8203)</p> TYPO3 Core - Bug #18613 (Closed): Extension configuration options are not always shownhttp://forge.typo3.org/issues/186132008-04-12T17:25:59ZJeff Segarsjsegars@alumni.rice.edu
<p>When importing an extension from the TER, any required database updates are shown. Externsion configuration options are not shown, however, and there's not a message that configuration options will be available upon install.</p>
<p>The attached screenshot from Steffen shows what the this looks like during installation of wec_map, which does have extension configuration options.</p>
<p>(issue imported from #M8108)</p> TYPO3 Core - Bug #18263 (Closed): Backend Alignment Problems in Internet Explorerhttp://forge.typo3.org/issues/182632008-02-20T23:09:03ZJeff Segarsjsegars@alumni.rice.edu
<p>The second row of the docheader has some alignment problems in Internet Explorer, as text labels and icons are not inline with one another and have different vertical spacing than other browsers.</p>
<p>The username in the top bar of the backend also suffers from similar alignment problems in Internet Explorer.</p>
<p>The attached patch tweaks the CSS for improved cross browser alignment.</p>
<p>(issue imported from #M7605)</p> TYPO3 Core - Bug #18258 (Closed): Fix module menu alignment and hover in Internet Explorerhttp://forge.typo3.org/issues/182582008-02-20T16:21:32ZJeff Segarsjsegars@alumni.rice.edu
<p>In Internet Explorer, labels in the module menu are not aligned the same as other browsers due to a collapsing span on the menu icons. Also, Internet Explorer 6 does not support the hover attribute on list elements.</p>
<p>To fix this, I've changed the icons to float left which allows IE and other browsers to give them a consistent width (regardless of icon size) and preserve the alignment in all browsers. For the hover, I've used a CSS selector within prototype to add and remove a hover class on mouseenter and mouseleave. These events are only available in IE, but thats fine since IE is our target.</p>
<p>(issue imported from #M7598)</p> TYPO3 Core - Bug #18118 (Closed): CSS Gremlins in t3skinhttp://forge.typo3.org/issues/181182008-02-05T06:28:37ZJeff Segarsjsegars@alumni.rice.edu
<p>From a thread on the dev list, we came up with a list of simple CSS gremlins in t3skin that can be addressed quickly. The attached patch fixes the following issues...</p>
<p>1. Links are not underlined (For now, all links are underlined but this means a lot of stuff is underlined. We may want to revisit this).<br />2. Remove borders and background colors from select fields.<br />3. File->Filelist has an old-style table header.<br />4. File->Filelist has an unstyled table when using clipboard #1.<br />5. Web->Info tables are not styled at all in the pagetree overview.<br />6. TCEForms record header has a background in IE.<br />7. Task Center horizontal tab menu on the left still has old skin colors and background.<br />8. Category treeviews like in tt_news have some extra pixels between the records.</p>
<p>(issue imported from #M7388)</p> TYPO3 Core - Bug #18041 (Closed): Add hook for warning messages within Help->About modules and im...http://forge.typo3.org/issues/180412008-01-23T05:57:47ZJeff Segarsjsegars@alumni.rice.edu
<p>A postProcessingHook within t3lib_beFunc->displayWarningMessages would allow extensions to insert their own warning messages if critical problems were detected.</p>
<p>The default warning messages could also be cleaned up a little, with links to the location where the suggested updates can be made.</p>
<p>(issue imported from #M7247)</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>