<?xml version="1.0" encoding="utf-8"?>
<!--  RSS generated by Flaimo.com RSS Builder [2010-03-11 19:10:24]  --> <rss version="2.0" xmlns:im="http://purl.org/rss/1.0/item-images/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" >
<channel>
<docs>http://bugs.typo3.org/</docs>
<description>TYPO3 bugtracker - ISSUES</description>
<link>http://bugs.typo3.org/</link>
<title>TYPO3 bugtracker - ISSUES</title>
<image>
<title>TYPO3 bugtracker - ISSUES</title>
<url>http://bugs.typo3.org/images/mantis_logo_button.gif</url>
<link>http://bugs.typo3.org/</link>
<description>TYPO3 bugtracker - ISSUES</description>
</image>
<category>All Projects</category>
<ttl>10</ttl>
<sy:updatePeriod>hourly</sy:updatePeriod>
<sy:updateFrequency>1</sy:updateFrequency>
<sy:updateBase>2010-03-11T19:10:23+01:00</sy:updateBase>
<item>
<title>0013459: Front-end login is broken with Safari</title>
<link>http://bugs.typo3.org/view.php?id=13459</link>
<description>Login not possible with mac, leopard 10 and safari 4.04.&lt;br /&gt;
No problems with Safari,Opera, IE on windows, or Firefox on Mac.</description>
<guid>http://bugs.typo3.org/view.php?id=13459</guid>
<author>Rolf Maibach &lt;Rolf Maibach@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13459#bugnotes</comments>
</item>
<item>
<title>0013800: Cropping small images fails if noScaleUp is enabled</title>
<link>http://bugs.typo3.org/view.php?id=13800</link>
<description>If the install tool option noScaleUp is enabled, so images won't be scaled up, cropping images won't work, if the desired dimensions are larger than the processed image.&lt;br /&gt;
&lt;br /&gt;
The result is some missing path information in the imageInfo array returned by $cObject-&gt;getImgResource().&lt;br /&gt;
&lt;br /&gt;
Imho if the image dimensions are smaller than the desired dimensions, still valid pathes to the temporary file should be returned.</description>
<guid>http://bugs.typo3.org/view.php?id=13800</guid>
<author>Thomas Deinhamer &lt;Thomas Deinhamer@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13800#bugnotes</comments>
</item>
<item>
<title>0013721: No access to configuration in encodeTitle_userProc function from inside tx_realurl</title>
<link>http://bugs.typo3.org/view.php?id=13721</link>
<description>RealURL provides a place where to call a user function for custom processing when encoding a title (from inside tx_realurl_advanced) or an alias (from inside tx_realurl). One would expect the same information to be available from inside that function. Unfortunately, this is not the case.&lt;br /&gt;
&lt;br /&gt;
When tx_realurl_advanced is the parent object, it comes with the encoding configuration available as the &quot;conf&quot; member variable of the parent object. This corresponds actually to the &quot;pagePath&quot; part of the RealURL configuration.&lt;br /&gt;
&lt;br /&gt;
But when tx_realurl is the parent object, it has no &quot;conf&quot; member variable. There is thus no way to get the encoding configuration (like the &quot;spaceCharacter&quot; for example). This is a problem when you need to fully re-encode the title or the alias inside the encodeTitle_userProc function (which is my case).&lt;br /&gt;
&lt;br /&gt;
I propose to add the relevant configuration as an additional parameter to the function call. The attached patch does this. Note that - in the context of tx_realurl_advanced - the value of &quot;strtolower&quot; is hard-coded to &quot;TRUE&quot; since all titles are lower-cased by tx_realurl_advanced::encodeTitle().</description>
<guid>http://bugs.typo3.org/view.php?id=13721</guid>
<author>Francois Suter &lt;Francois Suter@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13721#bugnotes</comments>
</item>
<item>
<title>0013799: [Feature] ExtJS driven fading in/out Flashmessages</title>
<link>http://bugs.typo3.org/view.php?id=13799</link>
<description>This singleton class creates fading-in FlashMessages, they stay for given duration and then fade out again.&lt;br /&gt;
&lt;br /&gt;
Possible usage:&lt;br /&gt;
&lt;br /&gt;
TYPO3.Flashmessage.msg(1, &quot;TYPO3 Backend - Version 4.4&quot;, &quot;Ready for take off&quot;, 3);&lt;br /&gt;
&lt;br /&gt;
See screenshot and example patch</description>
<guid>http://bugs.typo3.org/view.php?id=13799</guid>
<author>Steffen Kamper &lt;Steffen Kamper@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13799#bugnotes</comments>
</item>
<item>
<title>0013750: Several GIFBUILDER features broken for IM4, IM6 and GM  (Solution included!)</title>
<link>http://bugs.typo3.org/view.php?id=13750</link>
<description>When IM4, IM6 or GM are used, several GIFBUILDER features that internally use mask images (e.g. SHADOW and NICETEXT) are broken.&lt;br /&gt;
The reason is a flawed processing of quoted parts in IM commands that probably has many more side effects.</description>
<guid>http://bugs.typo3.org/view.php?id=13750</guid>
<author>J?rg Wagner &lt;J?rg Wagner@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13750#bugnotes</comments>
</item>
<item>
<title>0013461: wrong image-path returned in class.t3lib_tceforms.php if TYPO3-source is symlinked (backend-redesign)</title>
<link>http://bugs.typo3.org/view.php?id=13461</link>
<description>If an extension is installed in 'typo3conf/ext/' and overrides BE-icons, the result of 't3lib_iconWorks::skinImg' (line:4008) is i.e. &quot;../typo3conf/ext/myextension/icons/gfx/i/pages.gif&quot;.&lt;br /&gt;
thats correct, but if we use a symlinked TYPO3-source we get an incorrect path to the imagefile and so we do not get the correct image-dimensions from 'getimagesize' (line:4010)!&lt;br /&gt;
&lt;br /&gt;
the result is, that dropdown-menus in backend-forms which contains icons, are not rendered correctly...icon is shown under text and text is positioned leftmost.&lt;br /&gt;
&lt;br /&gt;
One possible solution is, to check if the path begins with '../' after 't3lib_iconWorks::skinImg' returned the image-path and pass the new full path to 'getimagesize'.&lt;br /&gt;
returned iconPath without patch is: /var/www/typo3-4.3.1/typo3/../typo3conf/ext/myextension/icons/gfx/i/pages.gif&lt;br /&gt;
returned iconPath with patch is:  /var/www/typo3-4.3.1/typo3conf/ext/myextension/icons/gfx/i/pages.gif&lt;br /&gt;
&lt;br /&gt;
it worked for me with the following modified lines:&lt;br /&gt;
4009,4010c4009,4014&lt;br /&gt;
&lt;	$iconPath = substr($selIconFile, strlen($this-&gt;backPath));&lt;br /&gt;
&lt;	$selIconInfo = @getimagesize(PATH_typo3 . $iconPath);&lt;br /&gt;
---&lt;br /&gt;
&gt;	if (substr($selIconFile,0,3)=='../')    {&lt;br /&gt;
&gt;		$selIconInfo = @getimagesize(PATH_site.t3lib_div::resolveBackPath(substr($selIconFile,3)));&lt;br /&gt;
&gt;	} else {&lt;br /&gt;
&gt;		$iconPath = substr($selIconFile, strlen($this-&gt;backPath));&lt;br /&gt;
&gt;		$selIconInfo = @getimagesize(PATH_typo3 . $iconPath);&lt;br /&gt;
&gt;	}</description>
<guid>http://bugs.typo3.org/view.php?id=13461</guid>
<author>Stephan Kellermayr &lt;Stephan Kellermayr@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13461#bugnotes</comments>
</item>
<item>
<title>0013798: empty redirect setting: login message without logout button</title>
<link>http://bugs.typo3.org/view.php?id=13798</link>
<description>If a login doesn't have a redirect setting (for example if a login box is needed on any page and a user shouldn't be redirected at login) the logged-in message only gets the content of the markers ###STATUS_HEADER### and ###STATUS_MESSAGE###. The logout button isn't shown.&lt;br /&gt;
&lt;br /&gt;
This can be fixed in class.user_felogin_pi1.php with the following three lines of code, which have to be inserted in the function showLogout() right before the line &quot;// Hook for general actions after after login has been confirmed&quot;:&lt;br /&gt;
&lt;br /&gt;
$subpart = $this-&gt;cObj-&gt;getSubpart($this-&gt;template, '###TEMPLATE_LOGOUT###');&lt;br /&gt;
$markerArray['###LOGOUT_LABEL###'] = $this-&gt;pi_getLL('logout', '', 1);&lt;br /&gt;
$markerArray['###USERNAME###'] = htmlspecialchars($GLOBALS['TSFE']-&gt;fe_user-&gt;user['username']);</description>
<guid>http://bugs.typo3.org/view.php?id=13798</guid>
<author>WoK &lt;WoK@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13798#bugnotes</comments>
</item>
<item>
<title>0013486: wrong icon-state returned from 'getIcon' in class.t3lib_iconworks.php</title>
<link>http://bugs.typo3.org/view.php?id=13486</link>
<description>the current TYPO3-code causes the following situation:&lt;br /&gt;
&lt;br /&gt;
a page which is disabled because...&lt;br /&gt;
...the endtime is in the future, outputs the filename 'pages__f.gif' ($futuretiming = TRUE;)&lt;br /&gt;
...the starttime is in the future, outputs the filename 'pages__t.gif' ($timing = TRUE;)&lt;br /&gt;
...the endtime is in the past, outputs the filename 'pages__t.gif' ($timing = TRUE;)&lt;br /&gt;
...the starttime is in the future AND the endtime is in the future too, outputs the filename 'pages__tf.gif' ($timing = TRUE; $futuretiming = TRUE;)&lt;br /&gt;
&lt;br /&gt;
that is actually ok, but if you want to use a preciser icon-set to visualize the exact state, you dont have a chance to get the right icon, because there is missing a code in the futuretiming-concept:&lt;br /&gt;
&lt;br /&gt;
i.e.: if the starttime is in the future and the endtime is NOT SET, the page is inactive, and so we should have the case 'futuretiming' ...but TYPO3 just returns 'timing'. the filename we get is 'pages__t.gif'&lt;br /&gt;
thats the same file we get, when only endtime is set and is in the past.&lt;br /&gt;
&lt;br /&gt;
this problem doesnt affect the current available TYPO3-backend-skins, because none of them is using such precise icons to visualize this states especially in combination with 'Hide in menu' or 'Hide page'.&lt;br /&gt;
but if we are interested in designing a new backend-skin where we are able to express all this states with a small icon (or icon-overlay), this part is our stumbling block!&lt;br /&gt;
&lt;br /&gt;
the problem is also relevant, if you are about to use icons, which represents the page's current visility in the frontend!&lt;br /&gt;
...a patch would be great for editors, because they could see by mean of the icon, why a page is currently NOT visible.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
so i have a little patch here which solve this problem and has downward compatibility too:&lt;br /&gt;
just add after line 192 in class.t3lin_iconworks.php the following code:&lt;br /&gt;
// ...And if &quot;endtime&quot; is NOT set:&lt;br /&gt;
if (!$row[$enCols['endtime']]) {&lt;br /&gt;
	$futuretiming = TRUE;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
because of the fact, that the original files 'pages__t.gif' and 'pages__tf.gif' are identically, the patch doesnt affect current TYPO3-installations.&lt;br /&gt;
...but with this all backend-skinner get new chances to create meaningful new icon-sets and improve the usability of TYPO3!&lt;br /&gt;
&lt;br /&gt;
btw: this &quot;bug&quot; is very very very old...</description>
<guid>http://bugs.typo3.org/view.php?id=13486</guid>
<author>Stephan Kellermayr &lt;Stephan Kellermayr@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13486#bugnotes</comments>
</item>
<item>
<title>0013487: no alternative icon returned from 'getIcon' in class.t3lib_iconworks.php (backend-redesign)</title>
<link>http://bugs.typo3.org/view.php?id=13487</link>
<description>current situation:&lt;br /&gt;
the function 'getIcon' checks if an icon with the current states (hidden/timing/futuretiming/protected...) is available and returns this.&lt;br /&gt;
but if we are using an extension which overrides some icons AND provides additional icons which are NOT available in the source (i.e.: for some states which would be normally displayed with 'icon_not_found.gif' or the appendix '*__x.gif') it does not return the new icon, because there is no check to the alternative path given by $GLOBALS['TBE_STYLES']['skinImgAutoCfg']['absDir']&lt;br /&gt;
&lt;br /&gt;
in fact there is no possibility to improve the backend with replacements for missing icons at this time.&lt;br /&gt;
&lt;br /&gt;
...thats why the following modification would be fine for backend-redesigner and other people who wants to improve the default icon-set:&lt;br /&gt;
&lt;br /&gt;
replace line 251:&lt;br /&gt;
if (@is_file(dirname($absfile).'/'.$iconFileName_stateTagged))	{	// Look for [iconname]_xxxx.[ext]&lt;br /&gt;
&lt;br /&gt;
with this line:&lt;br /&gt;
if (@is_file(dirname($absfile).'/'.$iconFileName_stateTagged) || @is_file($GLOBALS['TBE_STYLES']['skinImgAutoCfg']['absDir'].'/'.dirname($iconfile).'/'.$iconFileName_stateTagged))	{	// Look for [iconname]_xxxx.[ext]&lt;br /&gt;
&lt;br /&gt;
this will also check the location of the alternative icons added by an extension and finally returns the new icon.</description>
<guid>http://bugs.typo3.org/view.php?id=13487</guid>
<author>Stephan Kellermayr &lt;Stephan Kellermayr@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13487#bugnotes</comments>
</item>
<item>
<title>0007893: Can not resolve path when installed as global extension</title>
<link>http://bugs.typo3.org/view.php?id=7893</link>
<description>Setting up my first Typo3 4.2b3 site, I thought I was wise, and installed TemplaVoilà as a global extension so that I won't have to install it on every site I make. &lt;br /&gt;
&lt;br /&gt;
I got the following error:&lt;br /&gt;
&lt;br /&gt;
****&lt;br /&gt;
Error in init.php: Path to TYPO3 main dir could not be resolved correctly.&lt;br /&gt;
&lt;br /&gt;
This happens if the last 6 characters of this path, /home/hageform/public_html/typo3/ext/templavoila/mod1/ ($temp_path), is NOT &quot;typo3/&quot; for some reason.&lt;br /&gt;
You may have a strange server configuration. Or maybe you didn't set constant TYPO3_MOD_PATH in your module?&lt;br /&gt;
&lt;br /&gt;
If you want to debug this issue, please edit typo3/init.php of your TYPO3 source and search for the die() call right after this line (search for this text to find)...&lt;br /&gt;
***&lt;br /&gt;
&lt;br /&gt;
It looks like TV doesn't like to be installed as a global extension.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
- Mathias</description>
<guid>http://bugs.typo3.org/view.php?id=7893</guid>
<author>Mathias Bolt Lesniak &lt;Mathias Bolt Lesniak@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=7893#bugnotes</comments>
</item>
<item>
<title>0013797: Move checkbox &quot;secondary options&quot; to users module</title>
<link>http://bugs.typo3.org/view.php?id=13797</link>
<description>It makes much more sense to move the checkbox &quot;secondary options&quot; to the user's settings module.  This will also make the BE a bit cleaner</description>
<guid>http://bugs.typo3.org/view.php?id=13797</guid>
<author>Ringer Georg &lt;Ringer Georg@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13797#bugnotes</comments>
</item>
<item>
<title>0009729: Ship optimal TYPO3 configuration by default</title>
<link>http://bugs.typo3.org/view.php?id=9729</link>
<description>By default TYPO3 comes with unoptimal configuration due to the bugfix &lt;a href=&quot;http://bugs.typo3.org/view.php?id=4962&quot;&gt;0004962&lt;/a&gt;. It is time to change it to optimal. If some installation disable mod_rewrite, it is not a reason to ship badly optimized installation to the rest of the world.&lt;br /&gt;
&lt;br /&gt;
To make optimal configuration, rename the following files from _.htaccess to .htaccess in the TYPO3 core:&lt;br /&gt;
&lt;br /&gt;
./typo3/contrib/_.htaccess&lt;br /&gt;
./typo3/gfx/_.htaccess&lt;br /&gt;
./typo3/mod/user/ws/_.htaccess&lt;br /&gt;
./typo3/sysext/_.htaccess&lt;br /&gt;
./typo3/sysext/t3skin/stylesheets/_.htaccess</description>
<guid>http://bugs.typo3.org/view.php?id=9729</guid>
<author>Dmitry Dulepov &lt;Dmitry Dulepov@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=9729#bugnotes</comments>
</item>
<item>
<title>0013796: htmlArea RTE: Extjize Remove format dialogue</title>
<link>http://bugs.typo3.org/view.php?id=13796</link>
<description>The attached patch rewrites the Remove format dialogue as an ExtJS window.&lt;br /&gt;
&lt;br /&gt;
Additionnally, a new option is added to remove non-breaking spaces.</description>
<guid>http://bugs.typo3.org/view.php?id=13796</guid>
<author>Stanislas Rolland &lt;Stanislas Rolland@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13796#bugnotes</comments>
</item>
<item>
<title>0003714: RTE htmlArea: Remove formatting does not remove non-breaking spaces and pop uwindow still too small.</title>
<link>http://bugs.typo3.org/view.php?id=3714</link>
<description>Using the rtehtmlarea 'Remove formatting' function on a formatted text does not remove ' '&lt;br /&gt;
&lt;br /&gt;
I expect this function to remove all kind of code from the source text, even html entities, &lt;br /&gt;
or at least replace a   with a normal space.&lt;br /&gt;
&lt;br /&gt;
Like reported in issue 0002229, the upcoming pop window still ist too small in firefox.</description>
<guid>http://bugs.typo3.org/view.php?id=3714</guid>
<author>Nils Clark-Bernhard &lt;Nils Clark-Bernhard@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=3714#bugnotes</comments>
</item>
<item>
<title>0009218: &quot;removeformat&quot; messes up some in-line formats</title>
<link>http://bugs.typo3.org/view.php?id=9218</link>
<description>When &quot;removeformat&quot; for Word is run on a sequence like&lt;br /&gt;
&lt;br /&gt;
&lt;p&gt; &lt;b&gt;abc&lt;/b&gt;&lt;b&gt; &lt;/b&gt;&lt;b&gt;def&lt;/b&gt; &lt;/p&gt;&lt;br /&gt;
&lt;p&gt;abcdef&lt;/p&gt;&lt;br /&gt;
&lt;br /&gt;
The result will be&lt;br /&gt;
&lt;br /&gt;
&lt;p&gt; &lt;b&gt;abc&lt;/b&gt;&lt;b&gt;&gt;&lt;b&gt;def&lt;/b&gt; &lt;/b&gt;&lt;/p&gt;&lt;b&gt; &lt;/b&gt;&lt;p&gt;&lt;b&gt;abcdef&lt;/b&gt;&lt;/p&gt;&lt;br /&gt;
&lt;br /&gt;
instead of&lt;br /&gt;
&lt;br /&gt;
&lt;p&gt; &lt;b&gt;abc def&lt;/b&gt;&lt;/p&gt;&lt;p&gt;abcdef&lt;/p&gt;&lt;br /&gt;
&lt;br /&gt;
While the extra &amp;gt, only shows up in certain test cases, the much bigger problem of, the bold setting not being reset seems to affect any sequence that resets bold too often. However, this is quite common in copy&amp;paste imports from Word.</description>
<guid>http://bugs.typo3.org/view.php?id=9218</guid>
<author>Christian Lerrahn &lt;Christian Lerrahn@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=9218#bugnotes</comments>
</item>
<item>
<title>0008275: Could not remove span with style and font tags</title>
<link>http://bugs.typo3.org/view.php?id=8275</link>
<description>I try to get rid of all font´s and span´s with a style attribute.&lt;br /&gt;
To achieve this, i´m trying to use the &quot;Remove formatting&quot; function, but all font´s and style´s stay. The are not removed.</description>
<guid>http://bugs.typo3.org/view.php?id=8275</guid>
<author>Schreiber &lt;Schreiber@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=8275#bugnotes</comments>
</item>
<item>
<title>0013791: RTE randomly inserts non-breaking spaces instead of spaces</title>
<link>http://bugs.typo3.org/view.php?id=13791</link>
<description>When entering text in a RTE field, e.g., for a text content element or news, the RTE sometimes inserts a non-breaking space instead of a normal space character.&lt;br /&gt;
&lt;br /&gt;
This happens with several versions of TYPO3 and Firefox, including the latest ones. So far I haven't been able to find the circumstances that trigger this behavior.</description>
<guid>http://bugs.typo3.org/view.php?id=13791</guid>
<author>Christian Hennecke &lt;Christian Hennecke@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13791#bugnotes</comments>
</item>
<item>
<title>0012157: Empty paragraphs contain &lt;br /&gt; in Firefox instead of i.e.&nbsp;</title>
<link>http://bugs.typo3.org/view.php?id=12157</link>
<description>When I enter twice in rte the empty line looks as follows:&lt;br /&gt;
FF: &lt;p&gt;&lt;br /&gt;&lt;/p&gt;&lt;br /&gt;
IE: &lt;p&gt;&nbsp;&lt;/p&gt;&lt;br /&gt;
&lt;br /&gt;
Sometimes in FF I also get an extra br-tag at the end of the last paragraph.&lt;br /&gt;
&lt;br /&gt;
Sorry, I can't evaluate if this ist due to my rte configuration or simply a bug.&lt;br /&gt;
&lt;br /&gt;
Typo3 4.2.4</description>
<guid>http://bugs.typo3.org/view.php?id=12157</guid>
<author>Propach &lt;Propach@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=12157#bugnotes</comments>
</item>
<item>
<title>0013795: htmlArea RTE: Extjize About window</title>
<link>http://bugs.typo3.org/view.php?id=13795</link>
<description>The attached patch rewrites the About dialogue as a ExtJS window.</description>
<guid>http://bugs.typo3.org/view.php?id=13795</guid>
<author>Stanislas Rolland &lt;Stanislas Rolland@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13795#bugnotes</comments>
</item>
<item>
<title>0013794: Problem with LIST2 view in standard template tt_news_v3_template.html</title>
<link>http://bugs.typo3.org/view.php?id=13794</link>
<description>If there is an odd number of news messages in LIST2 view in tt_news_v3_template.html a closing div tag is missing.</description>
<guid>http://bugs.typo3.org/view.php?id=13794</guid>
<author>Gerhard Rupp &lt;Gerhard Rupp@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13794#bugnotes</comments>
</item>
<item>
<title>0013052: New Content Element Wizard didn't load</title>
<link>http://bugs.typo3.org/view.php?id=13052</link>
<description>Hello,&lt;br /&gt;
&lt;br /&gt;
i was working on my typo3 site today, and at some point the new content element wizard stopped working.&lt;br /&gt;
&lt;br /&gt;
If i click on the &quot;create new element button&quot; only a blank page is shown. Sometimes it will work, most times there's only a blank page.&lt;br /&gt;
&lt;br /&gt;
What i've already found out:&lt;br /&gt;
&lt;br /&gt;
If i change the following line:&lt;br /&gt;
&lt;br /&gt;
		$this-&gt;content = $this-&gt;doc-&gt;insertStylesAndJS($this-&gt;content);&lt;br /&gt;
&lt;br /&gt;
to&lt;br /&gt;
&lt;br /&gt;
		$this-&gt;content .= $this-&gt;doc-&gt;insertStylesAndJS($this-&gt;content);&lt;br /&gt;
&lt;br /&gt;
on line 283 in mod1/db_new_content_el.php &lt;br /&gt;
it will work all the time, but output is broken (tabs are there 2 times)&lt;br /&gt;
&lt;br /&gt;
another thing: if i start firebug extension on my firefox and activate the network module, all files are reloaded all the time and bing -&gt; the problem is gone.&lt;br /&gt;
&lt;br /&gt;
so it looks like there is a caching problem or something.&lt;br /&gt;
&lt;br /&gt;
i'm using version 1.4.1 which is tagged in the svn. Same problem with trunk version.</description>
<guid>http://bugs.typo3.org/view.php?id=13052</guid>
<author>Sven H. &lt;Sven H.@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13052#bugnotes</comments>
</item>
<item>
<title>0012904: Exclude from speaking URL</title>
<link>http://bugs.typo3.org/view.php?id=12904</link>
<description>Under Typo3 4.3 'exclude from speaking URL' page property isn't working any more for the first subpage when its parents are shortcuts. Example:&lt;br /&gt;
&lt;br /&gt;
root (shortcut)&lt;br /&gt;
   |&lt;br /&gt;
   L  main content (shortcut)&lt;br /&gt;
          |&lt;br /&gt;
          L home (standard page) &lt;br /&gt;
&lt;br /&gt;
links to page home look like somedomain.com/home/ even though 'exclude from speaking URL' has been checked in the pages properties.</description>
<guid>http://bugs.typo3.org/view.php?id=12904</guid>
<author>Roman B?chler &lt;Roman B?chler@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=12904#bugnotes</comments>
</item>
<item>
<title>0013280: Exclude sysfolders from import for restricted users</title>
<link>http://bugs.typo3.org/view.php?id=13280</link>
<description>Although a user only has access to a specific db mount, all sysfolders for the group of the user are shown in the select box in the importer.&lt;br /&gt;
&lt;br /&gt;
We would be glad if you would review the attached patch and apply it to trunk.</description>
<guid>http://bugs.typo3.org/view.php?id=13280</guid>
<author>Manfred Egger &lt;Manfred Egger@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13280#bugnotes</comments>
</item>
<item>
<title>0013648: Plaintext newsletter - first element in bulletlist always empty</title>
<link>http://bugs.typo3.org/view.php?id=13648</link>
<description>When using the content element bulletlist the plaintext version of the newsletter always shows one additional element in front of the others, which is empty.&lt;br /&gt;
I added two lines of code which works for me.&lt;br /&gt;
in the function  breakBulletlist in file direct_mail/pi1/class.tx_directmail_pi1.php Line 405:&lt;br /&gt;
// [...]&lt;br /&gt;
$cParts = explode(chr(10),$str);&lt;br /&gt;
// just delete the first element if it is empty&lt;br /&gt;
if (is_array($cParts) and !$cParts[0])&lt;br /&gt;
    unset($cParts[0]);&lt;br /&gt;
reset($cParts);&lt;br /&gt;
// [...]</description>
<guid>http://bugs.typo3.org/view.php?id=13648</guid>
<author>Harald Oest &lt;Harald Oest@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=13648#bugnotes</comments>
</item>
<item>
<title>0004805: The plain text content could not be fetched. The HTML content could not be fetched.</title>
<link>http://bugs.typo3.org/view.php?id=4805</link>
<description>When I want fetch and compile the newsletter. I get the following error:&lt;br /&gt;
&quot;The plain text content could not be fetched.&lt;br /&gt;
The HTML content could not be fetched.&quot;&lt;br /&gt;
This problem was a topic in Typo3 bugtracker in the past (resolved) but there was no solution so far.&lt;br /&gt;
I clear the fe cache.</description>
<guid>http://bugs.typo3.org/view.php?id=4805</guid>
<author>Vincenzo &lt;Vincenzo@example.com&gt;</author>
<comments>http://bugs.typo3.org/view.php?id=4805#bugnotes</comments>
</item>
</channel>
</rss>
