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 #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 #24681 (Closed): CSH tooltips should be placed nearer to the texthttp://forge.typo3.org/issues/246812011-01-20T13:39:57ZErnesto Baschnyeb@cron.eu
<p>Since <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: CSH tooltip often gets in the way of the field it is supposed to provide help for (Closed)" href="http://forge.typo3.org/issues/24578">#24578</a> the tooltips are on top of the labels, improving the usability. But they are some px too far away. Also the (?) icon in the docheader, the arrow pointing out to the tooltip is not placed aligned with the icon.</p>
<p>Solution is to offset the pointer -10px and also move the tooltip closer with some ExtJS magic.</p>
<p>(issue imported from #M17163)</p> TYPO3 Core - Bug #24571 (Closed): Backend search throws Exceptions / SQL errors when running as n...http://forge.typo3.org/issues/245712011-01-14T15:05:39ZErnesto Baschnyeb@cron.eu
<p>When a non-admin tries the BE live search, SQL errors are thrown (and you see them in the debug console if this is active). Only happens for non-admin users.</p>
<p>(issue imported from #M17032)</p> TYPO3 Core - Bug #23799 (Closed): Add IfModule mod_rewrite.c to misc/advanced.htaccesshttp://forge.typo3.org/issues/237992010-10-20T09:42:15ZErnesto Baschnyeb@cron.eu
<p>The introduction package creates its own .htaccess file which contains <IfModule mod_rewrite.c>.</p>
<p>I would like to have that IfModule in misc/advanced.htaccess so that the introduction package could ship with our misc/advanced.htaccess, instead of creating its own .htaccess file.</p>
<p>The usage of misc/advanced.htaccess will be then added to the intro-package packaging script.</p>
<p>I would like to commit this also for 4.4, so that we can also use this in the 4.4 introduction packaging script.<br />(issue imported from #M16075)</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 #23743 (Closed): Allow skins to register sprites through addIconSpritehttp://forge.typo3.org/issues/237432010-10-15T21:21:37ZErnesto Baschnyeb@cron.eu
<p>Currently, extensions can register sprites using t3lib_spriteManager::addIconSprite(). This requires an array of icons (which will be added to $TBE_STYLES['spritemanager']['spriteIconsAvailable']) and the CSS filename which contains the generated sprite.css.</p>
<p>A skin might also want to provide a different sprite, but the skin's CSS files are already loaded automatically from the registered directory. See <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Core lacks "current" flags (Closed)" href="http://forge.typo3.org/issues/23266">#23266</a> where t3skin wants to add a sprite for flags. After this fix, we will use the API to do so in t3skin, simply not passing the CSS filename, but just the array of images.</p>
<p>(issue imported from #M16007)</p> TYPO3 Core - Feature #23735 (Closed): Create a new API based on SwiftMailer to replace t3lib_html...http://forge.typo3.org/issues/237352010-10-15T11:00:25ZErnesto Baschnyeb@cron.eu
<p>t3lib_htmlmail is ugly and non-RFC conformant. Use existing library SwiftMailer to replace the functionality with a new API.</p>
<p>This is a work in progress, see <a class="external" href="http://forge.typo3.org/projects/typo3v45-projects/wiki/SwiftMailer">http://forge.typo3.org/projects/typo3v45-projects/wiki/SwiftMailer</a><br />(issue imported from #M15998)</p> TYPO3 Core - Bug #23482 (Closed): Change all core PHP files to UTF8 encodinghttp://forge.typo3.org/issues/234822010-08-30T20:48:59ZErnesto Baschnyeb@cron.eu
<p>We want to have UTF8 PHP files in order to give proper credit to authors containing non-ASCII characters in their names. This mostly affects PHP comments.</p>
<p>(issue imported from #M15601)</p> TYPO3 Core - Bug #23281 (Closed): Backend shortcut cannot be set in IE8http://forge.typo3.org/issues/232812010-07-27T20:39:25ZErnesto Baschnyeb@cron.eu
<p>When you add any item in backend as a shortcut (using the "star with a +") using IE8, the shortcut icon disappears and a JS error occurs. The current module is <strong>not</strong> added to the shortcut list</p>
<p>(issue imported from #M15252)</p> TYPO3 Core - Bug #22235 (Closed): "Show" clickmenu in page tree generates wrong URLhttp://forge.typo3.org/issues/222352010-03-04T09:19:32ZErnesto Baschnyeb@cron.eu
<p>If we don't have any sys_domain record in our page tree, the clickmenu "Show" will generate a link like:</p>
<p><a class="external" href="http://example.com//index.php?id=xx">http://example.com//index.php?id=xx</a></p>
<p>Note the double "//" before index.php. This won't work if you have realurl installed (it doesn't even need to be enabled for your site):</p>
<p>"Error!</p>
<p>Reason: "index.php" could not be found, closest page matching is<br />"</p>
<p>(issue imported from #M13740)</p> TYPO3 Core - Bug #22234 (Closed): "Show" clickmenu in page tree does not work for mount pageshttp://forge.typo3.org/issues/222342010-03-04T09:08:14ZErnesto Baschnyeb@cron.eu
<p>Clicking the "Show" on a page which is a mount point to somewhere else brings the error:</p>
<p>"The requested page didn't have a proper connection to the tree-root! (Illegal Mount Point found in rootline)"</p>
<p>(issue imported from #M13739)</p> TYPO3 Core - Bug #15902 (Closed): Calling PHP5-only iconv functions in PHP4http://forge.typo3.org/issues/159022006-03-27T10:58:03ZErnesto Baschnyeb@cron.eu
<p>A change in t3lib_cs that made it into RC2 (cvs diff -r 1.53 -r 1.54 t3lib/class.t3lib_cs.php) added some functions that are only available on PHP5 if the user chooses "iconv" (iconv_substr, iconv_strlen, iconv_strpos, iconv_strrpos). If using PHP4 with iconv support, I will get lots of errors:</p>
<p>Fatal error: Call to undefined function: iconv_strlen() in ....t3lib/class.t3lib_cs.php on line 1388</p>
<p>Attached patch checks if the functions are available before calling them.<br />(issue imported from #M2994)</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>