TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692011-01-27T23:28:32ZTYPO3 Forge
Redmine 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 #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 - Bug #25657 (Rejected): Task Object State Is Not Savedhttp://forge.typo3.org/issues/256572010-04-29T16:07:38ZJeff Segarsjsegars@alumni.rice.edu
<p>I've just started using the scheduler in 4.3 for the first time and overall its been a very pleasant experience. There is one area where I'm getting stuck, however.</p>
<p>In my task, I need to track a couple small variables that may change from one run to the next (ie. the last time an update was actually pulled from a remote server with changed data). I expected these would be saved when the task was serialized and available again on the next run, but instead I always have the default values.</p>
<p>This appears to be due to tx_scheduler->executeTask() which runs $task->save() prior to $task->execute. Is this the intended behavior? If so, I guess the best option is to just write my data somewhere else for saving rather than expecting my task to be persistent.</p>
<p>(issue imported from #M14251)</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 #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 #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>