TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-04-08T08:46:18ZTYPO3 Forge
Redmine TYPO3 Core - Task #93879 (Rejected): Use named export for BroadcastService modulehttp://forge.typo3.org/issues/938792021-04-08T08:46:18ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Task #93103 (Rejected): Migrate backend context menu to lit-htmlhttp://forge.typo3.org/issues/931032020-12-17T23:09:49ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #92985 (Rejected): Cannot show record history of pages anymore in TYPO3 v10.4.10http://forge.typo3.org/issues/929852020-12-04T08:59:10ZOliver Haderoliver.hader@typo3.org
<blockquote>
<p>(1/3) Doctrine\DBAL\Exception\InvalidFieldNameException<br />An exception occurred while executing 'SELECT `uid` FROM `tx_impexp_presets` WHERE `pid` = ?' with params > [81]: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'pid' in 'where clause'</p>
<p>...</p>
<p>at TYPO3\CMS\Core\Database\Query\QueryBuilder->execute()<br />typo3/sysext/backend/Classes/History/RecordHistory.php line 328</p>
</blockquote>
<p>How to reproduce:</p>
<ul>
<li>(update TYPO3 v10.4.9 to v10.4.10)</li>
<li>(impexp system extension must be enabled)</li>
<li>use context menu in page-tree to show record history</li>
</ul>
<p>Reasons:</p>
<ul>
<li>looks like <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/66582">https://review.typo3.org/c/Packages/TYPO3.CMS/+/66582</a> changes database definition and introduces new TCA table</li>
<li>records history iterates over all TCA tables - applying <code>pid</code> constraint for <code>pages</code></li>
<li><code>pid</code> column does not exist unless database migration in Install Tool was executed (which should not be required for patch level releases)</li>
<li>affects TYPO3 v10 only</li>
</ul> TYPO3 Core - Bug #85950 (Rejected): Preview URL in backend is invalidhttp://forge.typo3.org/issues/859502018-08-23T18:40:46ZOliver Haderoliver.hader@typo3.org
Scenario:
<ul>
<li>not having site configuration</li>
<li>not having pseudo-site (no sys_domain configuration)</li>
<li>generate preview URL using record's context menu "view"</li>
</ul>
Result:
<ul>
<li><code>http://http//ip9.local/index.php?id=205</code></li>
</ul>
Expectation:
<ul>
<li><code>http://ip9.local/index.php?id=205</code></li>
</ul> TYPO3 Core - Feature #85051 (Rejected): Add possibility to deny setting cookies on client sidehttp://forge.typo3.org/issues/850512018-05-19T14:22:19ZOliver Haderoliver.hader@typo3.org
<p>In the scope of GDPR and ePrivacy regulations inside the EU it become required that users provide agreement before any cookies are set.<br />Since the TYPO3 core sets a couple of cookie automatically it is required to introduce an API that is capable of individually allow/deny cookies by individual handlers that might be provided by one or some 3rd party extensions.</p> TYPO3 Core - Bug #84503 (Rejected): Streamline RsaAuth login behaviorhttp://forge.typo3.org/issues/845032018-03-21T08:32:21ZOliver Haderoliver.hader@typo3.org
<a name="Short-summary"></a>
<h2 >Short summary<a href="#Short-summary" class="wiki-anchor">¶</a></h2>
<ul>
<li>regression in TYPO3 v7.6.25 and v8.7.11 when trying to log into the backend using a regular workflow (fill form, click login button)</li>
<li>basically affects Firefox (except macOS version) browsers - e.g. Chrom is not affected by this misbehavior</li>
</ul>
<a name="TYPO3-releases"></a>
<h2 >TYPO3 releases<a href="#TYPO3-releases" class="wiki-anchor">¶</a></h2>
<p>Updated TYPO3 versions 7.6.26 and 8.7.12 (to substitute 7.6.25 and 8.7.11) are planned to be released on Thursday, March 22nd, 2018.</p>
<a name="Side-note-on-RsaAuth"></a>
<h2 >Side note on RsaAuth<a href="#Side-note-on-RsaAuth" class="wiki-anchor">¶</a></h2>
<p>System extension "rsaauth" provides a public/private key encryption mechanism to for user credentials that are submitted using an insecure channel (e.g. plain HTTP on port 80). In case a web site is using secure channels (e.g. HTTPS on port 443) the system extension "rsaauth" can be disabled completely in combination with changing the <code>loginSecurityLevel</code> setting in the install tool for frontend and backend from <code>rsa</code> to <code>normal</code> - RsaAuth is superfluous in case the communication to the server is secured via TLS (HTTPS) already.</p>
<p>In general it's suggested to use HTTPS instead of RsaAuth!</p>
<a name="Explanation"></a>
<h2 >Explanation<a href="#Explanation" class="wiki-anchor">¶</a></h2>
<p>The fix for issue <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: rsaauth does not submit the name of the submit-button (Rejected)" href="http://forge.typo3.org/issues/76120">#76120</a> - which was targeted to work-around situations when a login form has two submit buttons with different meanings/actions - introduce a regression which lead to the situation that users could not login anymore into the TYPO3 backend.<br />The mentioned regression was handled in issue <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: BE Login with 8.7.11 and Firefox Quantum Browser Version 59.0 not possible anymore (Closed)" href="http://forge.typo3.org/issues/84253">#84253</a> which introduced a work-around for the TYPO3 backend part.</p>
A short summary what happened in the JavaScript part handling the login process:
<ul>
<li>extensions like sr_feuser_register combine different actions by using different name attributes on submit buttons in the same containing form element - in general using different endpoint actions would be suggested instead of combining the meaning in the same form</li>
<li>the mentioned first work-around change tries to preserve the name attribute of the clicked button to be send with the very same form - this was necessary since the button gets disabled once it was clicked (to prevent resubmission and clicking multiple times) - disabled form element are not delivered in the <code>application/x-www-form-urlencoded</code> part of the HTTP message to the server</li>
<li>the change that introduced the first regression was focusing on button that has been clicked by checking the <code>:focus</code> state of the button and tried to click that again - since the button already became disabled, it also cannot be clicked again and wont actually send the form contents to the server</li>
<li>the behavior basically affects FIrefox (excluding macOS versions, see below)
<ul>
<li>Firefox does not support <code>click</code> events on disabled form elements, see <a class="external" href="https://developer.mozilla.org/en-US/docs/Web/Events/click#Browser_compatibility">https://developer.mozilla.org/en-US/docs/Web/Events/click#Browser_compatibility</a> - this applies e.g. to Edge as well</li>
<li>several browsers set the <code>:focus</code> state when clicking an element, except Firefox and Safari on macOS</li>
<li>the combination of these criteria lead to the mentioned misbehavior and explain why e.g. Chrome is not affected, see <a class="external" href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus">https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus</a></li>
</ul></li>
</ul>
To streamline the behavior the following has to be done:
<ul>
<li>revert both changes, the one that introduced the regression and the other that fixed the regression in the backend scope</li>
<li>(optionally) re-implement the initial bug fix for <a class="issue tracker-1 status-6 priority-4 priority-default closed" title="Bug: rsaauth does not submit the name of the submit-button (Rejected)" href="http://forge.typo3.org/issues/76120">#76120</a> without touching the backend part and only focussing carefully on the frontend part</li>
</ul> TYPO3 Core - Bug #39968 (Rejected): Collections use t3lib_BEfunchttp://forge.typo3.org/issues/399682012-08-19T15:43:17ZOliver Haderoliver.hader@typo3.org
<p>t3lib_collections use e.g. t3lib_BEfunc calls that won't work in the frontend.</p> TYPO3 Core - Feature #38233 (Rejected): Add event handling to bootstrap mechanismhttp://forge.typo3.org/issues/382332012-06-20T19:58:14ZOliver Haderoliver.hader@typo3.org
<p>Add several events like "database is initialized", "bootstrap is initialized", etc. to the whole bootstrap mechanism.<br />The concrete situation to be solved is the registration of Extbase Signal Slots in ext_localconf.php - which fails since autoloader and caching framework are not yet initialized at the time the ext_localconf.php gets executed.</p> TYPO3 Core - Feature #38088 (Rejected): Enhance Bootstrap contextshttp://forge.typo3.org/issues/380882012-06-15T16:13:41ZOliver Haderoliver.hader@typo3.org
<p>The Typo3_Bootstrap mechanism shall be extended to reflect the accordant contexts:</p>
<ul>
<li>Typo3_Bootstrap_Abstract (abstract)</li>
<li>Typo3_Bootstrap_Backend</li>
<li>Typo3_Bootstrap_Frontend</li>
<li>Typo3_Bootstrap_Install</li>
<li>Typo3_Bootstrap_Cli</li>
</ul> TYPO3 Core - Task #38087 (Rejected): Streamline typo3/classes naminghttp://forge.typo3.org/issues/380872012-06-15T16:09:26ZOliver Haderoliver.hader@typo3.org
<p>Streamline typo3/classes naming to be typo3/Classes</p> TYPO3 Core - Feature #25223 (Rejected): Enable TCA property displayCond for IRRE child recordshttp://forge.typo3.org/issues/252232011-03-02T14:54:11ZOliver Haderoliver.hader@typo3.org
<p>Imagine that particular fields of an IRRE child record shall only be shown depending on a value in the parent record. Currently there is no easy way to access evaluate the parent record and define a behaviour.</p>
<p>For Flexforms a similiar solution with displayCond is available, e.g.:<br /><pre>FIELD:parentRec.header:REQ:true</pre></p>
<p>However, it's problematic if the parent record is brand new and was not saved yet. In that case the field values of the parent should be transfered to the server side with the accordant AJAX request.</p>
<p>(issue imported from #M17824)</p> TYPO3 Core - Bug #23521 (Rejected): Flash Uploader does not work if cookieHttpOnly is enabledhttp://forge.typo3.org/issues/235212010-09-09T13:10:57ZOliver Haderoliver.hader@typo3.org
<p>The Flash Uploader does not work if the TYPO3_CONF_VARS setting "cookieHttpOnly" is enabled. After uploading a file, the uploader just shows a "303" error.</p>
<p>"303" is a HTTP status code and tells that there was a redirect since the backend user could not be authorized to have access to the TYPO3 backend.</p>
<p>(issue imported from #M15673)</p> TYPO3 Core - Feature #20605 (Rejected): Add more information to logoff() method in user authentic...http://forge.typo3.org/issues/206052009-06-10T12:06:08ZOliver Haderoliver.hader@typo3.org
The TYPO3 user authentication (t3lib_userAuth) has a method logoff() that is called at several places but has no information what kind of "logoff" happens:
<ul>
<li>regular logoff, since user requested it (status=logout)</li>
<li>automatic logoff from old session when a new frontend user logs in</li>
<li>automatic logoff if session of logged in frontend user expired or no frontend user is logged in at all</li>
</ul>
Tasks:
<ul>
<li>constants shall be integrated and added to the logoff-calls, e.g. logoff(self::LOGOFF_ByUser)</li>
<li>logoff-status must be transferred to affected hooks in the logoff() method</li>
</ul>
<p>(issue imported from #M11313)</p> TYPO3 Core - Bug #16741 (Rejected): typoLink doesn't use "type" correctly with simulateStaticDocu...http://forge.typo3.org/issues/167412006-11-27T10:35:06ZOliver Haderoliver.hader@typo3.org
<p>Imagine a TypoScript configuration like the following and simulateStaticDocuments enabled:</p>
<p>page.10 = TEXT<br />page.10 {<br /> stdWrap = 1<br /> stdWrap.typolink {<br /> returnLast = url<br /> useCacheHash = 1<br /> parameter.data = tsfe:id<br /> additionalParams = &type=5<br /> }<br />}</p>
<p>You would get something like this as link-URL:</p>
<p>SomePage.13+M5bd9214a8c2.0.html?&type=5</p>
<p>If a user clicks that link, he isn't forward to typeNum "5" as defined, but to the regular typeNum "0". So we would expect to have a link like the following one:</p>
<p>SomePage.13.5.html</p>
<p>The MD5-Part is missing here because it was used for the "&type=5" param only.</p>
<p>The attached patch file is exactly doing this by adding an additional check to tslib_cObj::typoLink.</p>
<p>It's not only a 4.1-beta1a issue. This exists since a long time... ;-)<br />(issue imported from #M4564)</p> TYPO3 Core - Feature #16482 (Rejected): Extending $TCA[$table]['ctrl']['thumbnail'] to use more t...http://forge.typo3.org/issues/164822006-08-21T13:41:38ZOliver Haderoliver.hader@typo3.org
<p>Generally the thumbnail field in the TCA ctrl section is used like this:</p>
<p>$TCA["tx_myext"] = Array (<br /> "ctrl" => Array (<br /> ...<br /> 'thumbnail' => 'image',<br /> ...<br /> ),<br />);</p>
<p>This diff provides a solution, to use more fields, separated by comma, e.g.</p>
<p>$TCA["tx_myext"] = Array (<br /> "ctrl" => Array (<br /> ...<br /> 'thumbnail' => 'image,map,icon',<br /> ...<br /> ),<br />);</p>
<p>See the following diff file.</p>
<p>(issue imported from #M4079)</p>