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 - Task #56941 (Closed): Return the 1-2-3 step icons in the step installerhttp://forge.typo3.org/issues/569412014-03-15T19:52:56ZErnesto Baschnyeb@cron.eu
<p>The 1-2-3 step installer could get the step icons back to visualize where the user is in the process of installation.</p>
<p>See <a class="external" href="https://redpen.io/xdk5sg">https://redpen.io/xdk5sg</a></p> TYPO3 Core - Bug #56770 (Closed): Install Tool flash messages in Step Installerhttp://forge.typo3.org/issues/567702014-03-11T16:51:49ZErnesto Baschnyeb@cron.eu
<p>The Step Installer sometimes want to present some "flash messages" which are passed over from one controller to the next through the session. Currently these messages are displayed over Step installer box.</p>
<p>And this looks ugly:</p>
<p><img src="http://forge.typo3.org/attachments/download/26211/install-tool-message-original.png" alt="" loading="lazy" /></p>
<p>This looks especially ugly in the first step of the Step Installer if the install tool tries to create the directory structure and fails on every single directory due to permission problems.</p>
<p>This is just a tiny adaptation to make it "less ugly", could be turned over again later on if we find an even better solution.</p>
<p>My pragmatic suggestion for now looks like this:</p>
<p><img src="http://forge.typo3.org/attachments/download/26212/install-tool-message-new.png" alt="" loading="lazy" /></p> TYPO3 Core - Feature #52440 (Closed): Disable certain tools in Install Tool if "LocalConfiguratio...http://forge.typo3.org/issues/524402013-10-01T17:21:26ZErnesto Baschnyeb@cron.eu
<p>If you go to All Configuration or Configuration Presets while your LocalConfiguration.php file is not writeable, you will end up in the redirect to the "Extension check", which is misleading and doesn't help the user understand the problem.</p>
<p>We should</p>
<p>a) provide a Folder Structure check to see if LocalConfiguration.php is indeed writable and display an Error (red badge) if not</p>
<p>b) disable with a Warning / Error box all tools which somehow need to write to the LocalConfiguration in some way. The "ActionInterface" could provide a method to declare if "needs localconfiguration" write access and depending on that display the warning instead of handling the action as usual.</p> TYPO3 Core - Feature #52090 (Closed): Merge Save Buttonshttp://forge.typo3.org/issues/520902013-09-17T22:40:56ZErnesto Baschnyeb@cron.eu
<p>To remove visual clutter it'd be great to merge the different save buttons into a split button drop down. Suggested to the UX team, designed and approved by Jens:</p>
<p><img src="http://forge.typo3.org/attachments/download/25002/TYPO3-Save-Selectbox-1.png" alt="" loading="lazy" /></p>
<p><img src="http://forge.typo3.org/attachments/download/25003/TYPO3-Save-Selectbox-2.png" alt="" loading="lazy" /></p>
<p><img src="http://forge.typo3.org/attachments/download/25004/TYPO3-Save-Selectbox-3.png" alt="" loading="lazy" /></p>
<hr />
<p>The CSS for this:</p>
<p>Arrow: <img src="http://forge.typo3.org/attachments/download/25005/small-arrow-down-8bit.png" alt="" loading="lazy" /> (inactive) = small-arrow-down-8bit.png</p>
<pre><code class="css syntaxhl" data-language="css"><span class="nc">.select-box-inactive-bg</span> <span class="p">{</span>
<span class="nl">border</span><span class="p">:</span> <span class="m">1px</span> <span class="nb">solid</span> <span class="m">#b3b3b3</span><span class="p">;</span> <span class="c">/* stroke */</span>
<span class="nl">background-color</span><span class="p">:</span> <span class="m">#cbcbcb</span><span class="p">;</span> <span class="c">/* color overlay */</span>
<span class="p">}</span>
</code></pre>
<pre><code class="css syntaxhl" data-language="css"><span class="nc">.select-box-hover-btn</span> <span class="p">{</span>
<span class="nl">border</span><span class="p">:</span> <span class="m">1px</span> <span class="nb">solid</span> <span class="m">#7b7b7b</span><span class="p">;</span>
<span class="nl">background-image</span><span class="p">:</span> <span class="n">-moz-linear-gradient</span><span class="p">(</span><span class="nb">bottom</span><span class="p">,</span> <span class="m">#d5d5d5</span> <span class="m">0%</span><span class="p">,</span> <span class="m">#f5f5f5</span> <span class="m">100%</span><span class="p">);</span>
<span class="nl">background-image</span><span class="p">:</span> <span class="n">-o-linear-gradient</span><span class="p">(</span><span class="nb">bottom</span><span class="p">,</span> <span class="m">#d5d5d5</span> <span class="m">0%</span><span class="p">,</span> <span class="m">#f5f5f5</span> <span class="m">100%</span><span class="p">);</span>
<span class="nl">background-image</span><span class="p">:</span> <span class="n">-webkit-linear-gradient</span><span class="p">(</span><span class="nb">bottom</span><span class="p">,</span> <span class="m">#d5d5d5</span> <span class="m">0%</span><span class="p">,</span> <span class="m">#f5f5f5</span> <span class="m">100%</span><span class="p">);</span>
<span class="nl">background-image</span><span class="p">:</span> <span class="n">linear-gradient</span><span class="p">(</span><span class="nb">bottom</span><span class="p">,</span> <span class="m">#d5d5d5</span> <span class="m">0%</span><span class="p">,</span> <span class="m">#f5f5f5</span> <span class="m">100%</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
<hr />
<p>Arrow: <img src="http://forge.typo3.org/attachments/download/25006/small-arrow-down-act-8bit.png" alt="" loading="lazy" /> (active) = small-arrow-down-act-8bit.png</p>
<pre><code class="css syntaxhl" data-language="css"><span class="nc">.select-box-contextmenu-active</span> <span class="p">{</span>
<span class="nl">border</span><span class="p">:</span> <span class="m">1px</span> <span class="nb">solid</span> <span class="m">#7b7b7b</span><span class="p">;</span>
<span class="nl">background-color</span><span class="p">:</span> <span class="m">#f7f7f7</span><span class="p">;</span>
<span class="nl">-moz-box-shadow</span><span class="p">:</span> <span class="m">0</span> <span class="m">1px</span> <span class="m">4px</span> <span class="n">rgba</span><span class="p">(</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">.69</span><span class="p">);</span>
<span class="nl">-webkit-box-shadow</span><span class="p">:</span> <span class="m">0</span> <span class="m">1px</span> <span class="m">4px</span> <span class="n">rgba</span><span class="p">(</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">.69</span><span class="p">);</span>
<span class="nl">box-shadow</span><span class="p">:</span> <span class="m">0</span> <span class="m">1px</span> <span class="m">4px</span> <span class="n">rgba</span><span class="p">(</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">0</span><span class="p">,</span><span class="m">.69</span><span class="p">);</span>
<span class="p">}</span>
</code></pre> TYPO3 Core - Feature #51730 (Closed): EM should only install extensions compatible with current T...http://forge.typo3.org/issues/517302013-09-04T16:01:54ZErnesto Baschnyeb@cron.eu
<p>When the EM fetches the "latest extension version" it should also consider the typo3 dependency constrain so that only extension versions compatible with the current TYPO3 version are considered.</p>
<p>This goes in line with the <a href="http://typo3.org/news/article/announcing-ter-cleanup-process/" class="external">TER cleanup initiative</a></p>
<p>It would also allow extension authors to provide extension versions for different TYPO3 releases.</p>
<p>Some issues / conflicts could still arise with this, like:</p>
<p>Extension A compatible with TYPO3 6.2 depends on Extension B which does not have a TYPO3 6.2 compatible version (yet).</p>
<p>So maybe there should still be "some way" to overrule this compatibility check in cases where the admin is sure of what he's doing.</p> TYPO3 Core - Bug #51698 (Closed): Delete sys_file entry when a file is deletedhttp://forge.typo3.org/issues/516982013-09-03T22:22:40ZErnesto Baschnyeb@cron.eu
<p>In order to keep sys_file as much in sync with the real file system as possible we should delete the relevant sys_file entry as soon as a file is deleted.</p>
<p>This is part of the "plan" in <a class="issue tracker-4 status-5 priority-4 priority-default closed parent" title="Task: Handling of deleted files in FAL (Closed)" href="http://forge.typo3.org/issues/50876">#50876</a> and should also be backported to 6.0/6.1 to keep the API straight and uniform throughout the releases.</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 - Feature #43477 (Closed): Better error handling on dummy without permissions (instead...http://forge.typo3.org/issues/434772012-11-30T10:02:08ZErnesto Baschnyeb@cron.eu
<p>If you unpack the dummy package in a blank vhost, but the webserver has no permissions to create files (under typo3temp etc) you get a PHP "Fatal Error" like this:</p>
<p>Fatal error: Uncaught exception 'RuntimeException' with message 'Could not create directory "/.../typo3temp/Cache/Code/cache_core/"!' in /.../typo3_src/typo3/sysext/core/Classes/Cache/Backend/SimpleFileBackend.php on line 197</p>
<p>While this is all true, this is probably the first impression a newby user will get from TYPO3's "usability".</p>
<p>Better would be at this situation output a nice instruction page (or a link to a Wiki page) on how to proceed (i.e. how to change permissions, which directories needs to have "write permissions" etc..).</p> TYPO3 Core - Task #24900 (Closed): "Version Compatibility" Upgrade Wizard should not be displayed...http://forge.typo3.org/issues/249002011-01-31T10:47:55ZErnesto Baschnyeb@cron.eu
<p>The "Version Compatibility" wizard will always show up, even if nothing was changed to the FE rendering. So the user is left with a dialog which is pretty confusing (see screenshot upgrade-wizard-compatVersion.png).</p>
<p>Solution: only call this wizard if there is there is something to do.<br />(issue imported from #M17415)</p> TYPO3 Core - Feature #24850 (Rejected): After the last Upgrade Wizard, a link to "COMPARE" should...http://forge.typo3.org/issues/248502011-01-27T11:27:34ZErnesto Baschnyeb@cron.eu
<p>After the last Upgrade Wizard is through, we should present a last Next button which links to the "COMPARE" screen.</p>
<p>This could even be integrated in a standalone "Wizard" so that the DB compare is done cleanly in the Upgrade Wizard path, so that after that the user is presented with a "Congratulation" message and some other nice words.</p>
<p>(issue imported from #M17354)</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 - 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 #14914 (Closed): config.disableImgBorderAttr should override anythinghttp://forge.typo3.org/issues/149142005-08-08T14:32:13ZErnesto Baschnyeb@cron.eu
<p>The fix added to 3.8.0 for <a class="external" href="http://bugs.typo3.org/view.php?id=797">http://bugs.typo3.org/view.php?id=797</a> had a bug in that the disableImgBorderAttr was checked wrongly. Now there is a fix for it in CVS, but it still isn't right:</p>
<p>class.tslib_content.php, line 2518:</p>
<pre><code>if (!t3lib_div::inList('xhtml_strict,xhtml_11,xhtml_2',$GLOBALS['TSFE']->config['config']['doctype']) || !$GLOBALS['TSFE']->config['config']['disableImgBorderAttr']) {<br /> return $borderAttr;<br /> }</code></pre>
<p>I would like the disableImgBorderAttr attribute to override any other setting, so that I could turn off the border-tags even if my doctype is xhtml_trans. This is not possible. A simple solution would be to change the logic in the test from OR (||) to AND (&&).</p>
<p>(issue imported from #M1360)</p>