TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692014-07-27T15:34:20ZTYPO3 Forge
Redmine TYPO3 Core - Task #60622 (Rejected): Deprecate getUrl, curlProxyServer and encourage usage of HTT...http://forge.typo3.org/issues/606222014-07-27T15:34:20ZErnesto Baschnyeb@cron.eu
<p>The SYS.curl* settings are being used by GeneralUtility::getUrl and openid. And probably other extensions are using that too.</p>
<p>Since 6.0 we have the nice HttpRequest adapter for the PEAR HTTP_Request2 component, which is a full replacement of what our old getUrl does.</p>
<p>So we want to deprecate getUrl along with the curl* settings.</p> TYPO3 Core - Bug #53940 (Rejected): Extension name is not case insensitive in anymorehttp://forge.typo3.org/issues/539402013-11-25T15:30:01ZErnesto Baschnyeb@cron.eu
<p>The extension "abaticker" for example contains something like:</p>
<pre>
t3lib_extMgm::addPlugin(Array("LLL:EXT:abaTicker/locallang_db.php:tt_content.list_type_pi1", $_EXTKEY."_pi1"),"list_type");
</pre>
<p>In 6.2 this now fails with:</p>
<p>"TYPO3 Fatal Error: Extension key "abaTicker" is NOT loaded" (Exception 1365429656)</p>
<p>So the ExtensionManagementUtil API doesn't seem to be backwards compatible yet (i.e. extPath() etc), as it doesn't seem to expect different CaSe for the passed extension key.</p> TYPO3 Core - Task #52814 (Closed): Don't throw Exception if "/Packages" cannot be created in Doc-...http://forge.typo3.org/issues/528142013-10-14T20:59:31ZErnesto Baschnyeb@cron.eu
<p>When the new package management takes over throught the Install Tool it tries to create a "Packages" subdirectory directly in PATH_site. This might fail due to no writing rights on this level.</p>
<p>This is not unusual, as TYPO3 never really needed to write anything here, so many installations have hardened their instances by not allowing doc-root-writing.</p>
<p>So we should instead not fatal with an exception, but accept that it wasn't created and not bother about it.</p> TYPO3 Core - Bug #45834 (Closed): Detection of curlProxyServer settings buggy on upgrade to 6.0http://forge.typo3.org/issues/458342013-02-25T19:24:39ZErnesto Baschnyeb@cron.eu
<p>In <a class="issue tracker-2 status-5 priority-3 priority-lowest closed behind-schedule" title="Feature: Include HTTP Request2 for better HTTP handling (Closed)" href="http://forge.typo3.org/issues/28344">#28344</a> "HTTP Request2" API was included. It supports detecting old school "curlProxyServer" settings and transfer these to the "new" setting under HTTP:</p>
<pre>
$proxyParts = explode(':', $GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'], 2);
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = $proxyParts[0];
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = $proxyParts[1];
</pre>
<p>This code ended up in Core/Bootstrap::transferDeprecatedCurlSettings() after namespace and bootstrapification.</p>
<p>I have always set up this setting like this:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['SYS']['curlProxyServer'] = 'http://proxy:3128';
</pre>
<p>I guess the implementator of the transferDeprecatedCurlSettings was only thinking about the "proxy:3128" kind of syntax. I end up with:</p>
<pre>
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_host'] = 'http'
$GLOBALS['TYPO3_CONF_VARS']['HTTP']['proxy_port'] = '//proxy:3128;
</pre>
<p>Other than that, I would also auto-set ['HTTP']['adapter'] to 'curl' if legacy 'curlUse' = TRUE.</p> TYPO3 Core - Bug #43331 (Closed): "Strict standards: Declaration of "CompatbilityClassLoaderPhpBe...http://forge.typo3.org/issues/433312012-11-27T09:27:34ZErnesto Baschnyeb@cron.eu
<p>On PHP < 5.3 I get this warning on top of the login screen (and also in the whole backend, making it completely unusable):</p>
<p>Strict standards: Declaration of TYPO3\CMS\Core\Compatibility\CompatbilityClassLoaderPhpBelow50307::requireClassFileOnce() should be compatible with that of TYPO3\CMS\Core\Core\ClassLoader::requireClassFileOnce() in /.../typo3_src/typo3/sysext/core/Classes/Core/SystemEnvironmentBuilder.php on line 239</p>
<p>Acording to git bisect this got broken with change <a class="issue tracker-4 status-5 priority-3 priority-lowest closed" title="Task: Protect bootstrap methods (Closed)" href="http://forge.typo3.org/issues/43285">#43285</a>.</p>
<p>Indeed the declaration of the methods differ:</p>
<pre>
class ClassLoader {
...
static protected function requireClassFileOnce($classPath) {
...
</pre>
<pre>
class CompatbilityClassLoaderPhpBelow50307 extends \TYPO3\CMS\Core\Core\ClassLoader {
...
static public function requireClassFileOnce($classPath, $className) {
...
</pre>
<p>And by the way, the classname CompatbilityClassLoaderPhpBelow50307 is misspelled (misses an "i" in Compat*i*bility).</p> TYPO3 Core - Bug #25772 (Closed): Resizeable textareas: scrollbar sticks to mousehttp://forge.typo3.org/issues/257722011-04-05T17:05:00ZErnesto Baschnyeb@cron.eu
<p>If you have resizeable textareas enabled and you try to use the scrollbar to scroll in your content with Internet Explorer 8, the re-sizing feature "sticks" to your mouse pointer (even after releasing the mouse button).</p>
<p>You can try it out with PageTS field in Page properties.</p> TYPO3 Core - Bug #25771 (Closed): Resizeable textareas with Internet Explorer (IE8): random jumps...http://forge.typo3.org/issues/257712011-04-05T17:03:08ZErnesto Baschnyeb@cron.eu
<p>Since 4.4 (?) textareas (e.g. PageTS field in the Page settings) are resizeable. With Internet Explorer there are some problems with it:</p>
<p>If in the user settings you disable the entry "Make Textareas Resizeable", you are not able to click on any line without causing the scrollbar to randomly jump around the content, thus making it very difficult to edit content in these fields.</p> TYPO3 Core - Bug #24914 (Closed): Upgrade Wizard "Install Outsourced System Extensions" should on...http://forge.typo3.org/issues/249142011-02-01T12:11:22ZErnesto Baschnyeb@cron.eu
<p>The Upgrade Wizard "Install Outsourced System Extensions" (tx_coreupdates_installsysexts) suggests the user to install all system extensions, even those which are already installed. This is confusing to the user that is doing a "new installation" based on the intro package for example, where all those extensions are already installed by default.</p>
<p>Solution would be to do the same logic as we have in "tx_coreupdates_installnewsysexts", which checks every extension if they are installed (and if all are installed, don't present the wizard at all!).</p>
<p>(issue imported from #M17429)</p> TYPO3 Core - Feature #24147 (Closed): Remove Internet Explorer 6 supporthttp://forge.typo3.org/issues/241472010-11-20T13:04:01ZErnesto Baschnyeb@cron.eu
<p>Internet Explorer 6 will be last supported in 4.5 (Long Term Release), thus we decided to get rid of all specific IE6 (and related ancient browsers) starting in 4.6 already.</p>
<p>(issue imported from #M16490)</p> TYPO3 Core - Bug #23798 (Closed): Add new API t3lib_befunc::helpTextArray and use it in the ExtDi...http://forge.typo3.org/issues/237982010-10-20T09:30:50ZErnesto Baschnyeb@cron.eu
<p>Currently the ExtDirect which fetches the tooltip fetches the information on its own from the $TCA_DESCR array. It will also render "TYPO3 Inline Help" as a default header if none is given and will not render an "arrow" which used to symbolize a link to a popup in its content.</p>
<p>This patch adds a new API function t3lib_befunc::helpTextArray which is then used by t3lib_befunc::helpText and also the new ExtDirect call to fetch the information. The tooltips now won't have a title anymore if there is no "alttitle" defined.</p>
<p>Almost none CSH uses "alttile", so usually you won't see any. There are some examples in the Extension manager (e.g. the main titles "Loaded Extensions" etc).<br />(issue imported from #M16074)</p> TYPO3 Core - Feature #19889 (Closed): displayErrors=2 and no errors on CLIhttp://forge.typo3.org/issues/198892009-01-22T16:41:30ZErnesto Baschnyeb@cron.eu
<p>Many sites set displayErrors=2 and have devIPmask to a list of IPs from the developer. This won't disturb the public, but the developer gets PHP errors, which is nice.</p>
<p>Unfortunately this also disables PHP errors from being outputted when running CLI scripts. This is particularly important if I set some cronjob running a CLI which can "break".</p>
<p>So suggested is a new setting displayErrorsForceOnCLI (boolean) which will enable error output on CLI, even if displayErrors=2.</p>
<p>(issue imported from #M10228)</p> TYPO3 Core - Bug #17412 (Closed): parseFunc tags.XXX for single tags doesn't workhttp://forge.typo3.org/issues/174122007-06-22T16:58:39ZErnesto Baschnyeb@cron.eu
<p>parseFunc "tags" doesn't work if the tag is a single tag which has attributes. E.g. the following:</p>
<p>lib.parseFunc_RTE {<br /> tags.img = TEXT<br /> tags.img {<br /> current = 1<br /> case = upper<br /> }<br />}</p>
<p>Won't handle: <img src="..." ... /><br />Will handle: <img/><br />Will handle: <img src="..." ...></img></p>
<p>So currently one cannot write a parseFunc for such an img tag.</p>
<p>This can be used for example for the click-enlarge rendering of images embedded in RTE, as Stanislau alterady added to rtehtmlarea code a year ago, but marked as "EXPERIMENTAL" because of this core bug. See related bug report <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Click-enlarge for Images (Closed)" href="http://forge.typo3.org/issues/14605">#14605</a><br />(issue imported from #M5841)</p> TYPO3 Core - Bug #15510 (Closed): UTF-8 sites display garbled chars in select-fields (in BE)http://forge.typo3.org/issues/155102006-01-26T16:50:33ZErnesto Baschnyeb@cron.eu
<p>Steps to reproduce (TCEforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Login to the backend, create a usergroup called "ÄÄÄ" (or any other non-ascii-char)<br />3) Create a user and add the group to the user (clicking on the right box). Upon adding, the group-name is add correctly to the left box.<br />4) Save the form and look at the result. Instead of "ÄÄÄ" you have a 6 bytes-string</p>
<p>Other place where it occurs (flexforms):</p>
<p>1) Set forceCharSet = utf-8.<br />2) Add tt_news extension<br />3) Create a News Category called "ÖÖÖ" <br />4) Add a News-Plugin as a content element, and tell it to display only elements in the category "ÖÖÖ".<br />5) Save and look at the displayed value in the left category box, its garbled again.</p>
<p>The attached minor patch (to latest 4.0-CVS) seems to solve it. But I think more thinking has to be done here.</p>
<p>The only change the patch does is that LANG->sL() won't try to convert from the encoding specified for the current users language (e.g. iso-latin-1) to UTF-8. In the case of values coming from the DB, they are already UTF-8, so this would cause double-encoding.</p>
<p>There might be side-effects, because sL() is also used for the "language-splitted" labels, but they are obsolete anyway. And I cannot imagine any latin-1 encoded string to enter this part of the function if the site is set to forceCharSet=utf8.</p>
<p>Non-forceCharSet-sites aren't affected by this change, because hscAndCharConv won't don anything other than htmlspecialchars, which I still do in my change.</p>
<p>Initially reported for TYPO3 4.0<br />(issue imported from #M2396)</p> TYPO3 Core - Feature #15324 (Closed): Clean-up in mailform code: more TypoScript flexibilityhttp://forge.typo3.org/issues/153242005-12-29T00:28:50ZErnesto Baschnyeb@cron.eu
<p>This relates to the changes applied by <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: XHTML and accessibility of FORM cObj (Closed)" href="http://forge.typo3.org/issues/14921">#14921</a>. This new patch enhances the features that have already been integrated into 4.0beta1 with the following:</p>
<p>The admin now can configure all tags from a mailform via TypoScript. There are now just very few tags hardcoded into PHP, mainly the tags that represent the fields for the FORM. The TypoScript code has been reorganized to be easier to understand and to adapt. The static TypoScript that comes with css_styled_content has been adapted for this.</p>
<p>- no more "accessibility=1" setting. All "accessible" settings are done just by configuring the tags and parameters in TypoScript itself. The default included TypoScript is now accessible out-of-the-box.<br />- all settings that are related to a specific element type (e.g. RADIO, SELECT, etc) are now organized into respective setting groups. See the new default static TypoScript to see what it means. But all "old" settings are still valid for backwards compatibility.<br />- the hardcoded "<label>" in accessibility-mode is now part of the TypoScript setup (labelWrap.wrap with ###ID### that gets replaced with appropriate ID). The user can override this per element-type (e.g. for LABEL type there is no <label>|</label> wrapping.<br />- labelWrap.wrap and REQ.labelWrap.wrap can now both be overridden in a specific element-type</p>
<p>Specific for RADIO-element:</p>
<p>- the user is now free to layout the radio-items appearance (used to be hardcoded to "[radio][label][br/]")<br />- static TypoScript used to have a "testform_radio" id for all radio-fieldsets, this was not only wrong, but also invalid if you have more than one radio-fieldset. Now the ID gets set correctly ("###ID###") according to the field-name.<br />- also the hardcoded "<legend>" is now part of the TypoScript setup, so it can be removed/changed/etc.</p>
<p>New settings (where XXX is the name of the element-type in UPPER-case):</p>
<p>- RADIO.item.layout with markers ###RADIO### (the radio-button) and ###RADIO_LABEL### (the corresponding label, stdWrapped in RADIO.item.labelWrap)<br />- RADIO.item.addParams with marker ###RADIO_ID### (the id of this specific item)<br />- RADIO.item.labelWrap with marker ###RADIO_ID### (the id of this specific item)<br />- XXX.addParams with marker ###ID### (the id of this field). This are attributes that will get added to the tag (input, select, textarea, ...) for this field in the FORM.<br />- XXX.labelWrap.wrap with marker ###ID### (the id of this field)<br />- XXX.REQ.labelWrap.wrap with marker ###ID### (the id of this field)</p>
<p>Obsolete (but still supported) settings and new equivalents:</p>
<p>params.xxx = XXX.addParams<br />radioWrap = RADIO.item.labelWrap<br />accessibility=1 = all accessible stuff can now be done directly in TypoScript</p>
<p>(issue imported from #M2119)</p> TYPO3 Core - Bug #15287 (Closed): Illegal SGML characters in outputhttp://forge.typo3.org/issues/152872005-12-15T21:00:15ZErnesto Baschnyeb@cron.eu
<p>Hi,</p>
<p>the "non SGML character number 128" is probably the most annoying validation error that TYPO3-sites hit when users from the Windows world copy&paste input some field which will go right through to the frontend.</p>
<p>THE PROBLEM<br />---------------</p>
<p>The origin of the problem comes from the fact that the ISO-Latin-1 character table specifies every character from the decimal range 32 up to 255, but has a gap in the range from 128 to 159 (see [1]). This range is (mis?)used by Microsoft in the so called "Windows-Latin-1" for various characters. The most frequently chars are the EURO-sign, the emdash ("langer Gedankenstrich", which MS-Word creates automatically if you type an hyphen with spaces around it) and opening-double-quotes (bottom) (also created by Word in German if you start some quotation).</p>
<p>So outputting these characters for the Web in "charset=iso-8859-1" mode is not "valid", because they are not part of this charset (which is also why the W3C-validator chokes on them). The very good article in [2] present some alternatives on how to output them in a generic way.</p>
<p>SOME TYPO3 SOLUTIONS<br />------------------------</p>
<p>Some time in the past I've written "cron_rte_cleanenc", which will remap those characters from the RTE into proper numerical entities (which is what the article [2] suggests as the most widely used method). This is nice, but later I figured out that these characters can also be pasted into fields that are not RTE-enabled (e.g. Title, Subtitle, etc), so my processing also works on some cases.</p>
<p>Later versions of qcom_htmlcleaner include the switch "Remap illegal chars" (clean_chars), which will translation any "high ASCII" character to a proper entity. Two problems I see with the current approach:</p>
<p>1. it only applies to XHTML_clean(), while the problem also exists in<br /> HTML mode. <br />2. it translates <strong>all</strong> characters >127 into entities, which is not<br /> needed. The range 128-159 is sufficient here, as Ä can be<br /> represented by a proper ISO-Latin-1 character already.</p>
<p>MY GOAL/AIM<br />--------------</p>
<p>I want this translation to happen in TYPO3-core, without needing any extention. Our goal has been XHTML-validity, and this is a major issue in this commitment. This is not a "xhtml_cleaning" problem, but a generic charset problem. We have proven solutions to the problem, we just need to see if they are generic enough not to hurt and add them in a meaningful way to the core.</p>
<p>HOW TO PROCEED<br />-----------------</p>
<p>We need to find out in which character sets this is a problem. If I set my site to "forceCharSet=utf-8", the problem doesn't exist, because all pasted input will have corresponding UTF-8 entities which are valid. So maybe some charset expert around could tell us a bit about it, and if noone is available, I would do some research on it. I suspect every ISO-Latin-x variant has this problem.</p>
<p>Then we need to create some patches to correct the situation.</p>
<p>[1] <a class="external" href="http://www.htmlhelp.com/reference/charset/">http://www.htmlhelp.com/reference/charset/</a><br />[2] <a class="external" href="http://www.cs.tut.fi/~jkorpela/www/windows-chars.html">http://www.cs.tut.fi/~jkorpela/www/windows-chars.html</a></p>
<p>(issue imported from #M2048)</p>