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 #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 #24534 (Closed): Update page and tt_content labels to use title casehttp://forge.typo3.org/issues/245342011-01-13T00:04:30ZJeff Segarsjsegars@alumni.rice.edu
<p>According to <a class="external" href="http://wiki.typo3.org/TCEformsRecommendedLayout">http://wiki.typo3.org/TCEformsRecommendedLayout</a>, form labels should use title case. This is mostly the case already in the backend but there are several exceptions in pages and tt_content the should be fixed.</p>
<p>This is not a change of meaning in the labels, since the wording doesn't change and it just follow different capitalization/punctuation rules so the existing labels are changed but do not need to be re-translated.</p>
<p>(issue imported from #M16989)</p> TYPO3 Core - Bug #24533 (Closed): Update Context Sensitive Help for pages and tt_content to match...http://forge.typo3.org/issues/245332011-01-12T22:27:36ZJeff Segarsjsegars@alumni.rice.edu
<p>With the recent label updates from JoH, Ingo, and others, the CSH doesn't match the actual labels for pages and tt_content very well.</p>
<p>In addition, a lot of the CSH descriptions are outdated and could use a little tweaking for their grammar. This hasn't been a complete rewrite of the CSH but more of a cleanup while fixing the label issues.</p>
<p>Additionally, we want to make these changes as easy as possible on the translators so that the existing CSH continues to work if new translations are not available.</p>
<p>1) Create new CSH files (inside a 4.5 folder) for pages and tt_content so that old TYPO3 versions are not affected.<br />2) Register these new CSH files using $TYPO3_CONF_VARS']['SYS']['locallangXMLOverride']</p>
<p>When CSH is requested, the hierarchy will look like this....<br />1) Check for new 4.5 label in the current language<br />2) Check for old label in the current language<br />3) Check for new 4.5 label in the default language<br />4) Check for old label in the default language</p>
<p>In addition to tt_content and pages, there are 2 updates for CSH files that use SysFolder rather than the new Folder label.</p>
<p>(issue imported from #M16988)</p> TYPO3 Core - Bug #24311 (Closed): TCEForms->getIconHTML() does not resolve back paths before chec...http://forge.typo3.org/issues/243112010-12-08T21:58:30ZJeff Segarsjsegars@alumni.rice.edu
<p>TCEForms->getIconHTML() returns the HTML for a static image file or a sprite icon. When checking for a static image file, the back path is not resolved before calling is_file() so references such as "../uploads/path/to/my/file.png" will fail. This is most easily reproduced with TemplaVoila and preview icons for Data Structures and Template Objects.</p>
<p>(issue imported from #M16703)</p> TYPO3 Core - Bug #24310 (Closed): TCEForm select dropdowns have text overlapping icon in Webkithttp://forge.typo3.org/issues/243102010-12-08T21:19:01ZJeff Segarsjsegars@alumni.rice.edu
<p>When using the select dropdown for pages, content elements, etc in Webkit, the item text overlaps the icon.</p>
<p>Since form styling (especially selects) is horribly inconsistent between browsers, the best option I've found is to target Webkit specifically with a class already applied by ExtJS.</p>
<p>(issue imported from #M16702)</p> TYPO3 Core - Feature #22447 (Closed): When sending mail, use TYPO3_CONF_VAR for default from addr...http://forge.typo3.org/issues/224472010-04-14T00:25:55ZJeff Segarsjsegars@alumni.rice.edu
<p>It's often useful to set a default email from address for TYPO3 rather than relying on the server's configuration, especially in shared hosting environments where it cannot be configured.</p>
<p>Now that we have t3lib_utility_mail, there's a central location for mail sending and we can modify the mail headers to use this default address if a from address has not already been specified.</p>
<p>(issue imported from #M14098)</p> TYPO3 Core - Bug #20844 (Closed): TYPO3 Javascript object missing in alt_main.phphttp://forge.typo3.org/issues/208442009-08-06T21:08:23ZJeff Segarsjsegars@alumni.rice.edu
<p>When using the classic backend in alt_main.php, links under the Web module do not work. Instead, a Javascript error is generated that says "TYPO3 is not defined" and references line 91 of typo3/js/backend.js</p>
<p>(issue imported from #M11662)</p> TYPO3 Core - Bug #19968 (Closed): Whitespace cleanups in t3lib_frontendedithttp://forge.typo3.org/issues/199682009-02-04T23:22:24ZJeff Segarsjsegars@alumni.rice.edu
<p>There are several minor CGL and whitespace issues in t3lib_frontendedit. The attached patch cleans these up.</p>
<p>(issue imported from #M10351)</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 #18672 (Closed): Typo in extended list view for select fieldshttp://forge.typo3.org/issues/186722008-04-22T20:51:00ZJeff Segarsjsegars@alumni.rice.edu
<p>When showing select fields in the extended list view, there's a tiny typo when no value is set for the select field. Instead of using N/A as other fields do, n/A is displayed instead.</p>
<p>(issue imported from #M8204)</p> TYPO3 Core - Bug #18380 (Closed): TCEForms extraFormHeaders do not work with docheadershttp://forge.typo3.org/issues/183802008-03-05T21:04:04ZJeff Segarsjsegars@alumni.rice.edu
<p>TCEForms has the possibility to set extraFormHeaders that are included above the editing form. In templates/alt_doc.html, the ###EXTRAHEADER### is included as part of typo3-docheader so that content from the editing form always scrolls behind it.</p>
<p>The problem is that the docbody has an absolute position so adding extra rows to the header does not push the actual editing form down.</p>
<p>I can see two options to work around this...<br />#1 - Move ###EXTRAHEADER### outside the docheader so that it scrolls behind the header just like other content<br />#2 - There's already Javascript code in place for IE to dynamically calculate the height and fix scrolling problems so we could remove the absolute positioning and let the Javascript run for all browsers.</p>
<p>I'm attaching a screenshot and a sample extension that adds extra headers to all records.</p>
<p>(issue imported from #M7768)</p>