TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692022-10-17T21:51:58ZTYPO3 Forge
Redmine TYPO3 Core - Bug #98642 (Rejected): Remove dependency injection from resource controllerhttp://forge.typo3.org/issues/986422022-10-17T21:51:58ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #97669 (Rejected): Handle COA_INT in config.pageTitle TypoScript assignmenthttp://forge.typo3.org/issues/976692022-05-21T16:27:41ZOliver Haderoliver.hader@typo3.org
<p>Using deferred content rendering for the page title does not work, since <code>@ will be HTML-encoded in @PageRenderer</code> and corresponding post-processors in <code>TypoScriptFrontendController</code> are not considering <code>&lt--INT_SCRIPT.12345 --&gt</code>.</p>
<pre>
config {
noPageTitle = 1
pageTitle.cObject = COA_INT
pageTitle.cObject {
10 = TEXT
10.value = Page Title created during content rendering
}
}
</pre> TYPO3 Core - Bug #96179 (Rejected): Ensure URIs are parsed using plain POSIX/C localehttp://forge.typo3.org/issues/961792021-12-01T14:19:49ZOliver Haderoliver.hader@typo3.org
<p>Using <code>parse_url</code> on unicode characters and not using a plain POSIX/C locale might lead to negative side-effects, destroying the unicode sequence of those special characters.</p>
<p>See attached <code>locale.php</code> to local locale testing.</p>
<a name="References"></a>
<h3 >References<a href="#References" class="wiki-anchor">¶</a></h3>
<ul>
<li><a class="external" href="https://bugs.php.net/bug.php?id=52923">https://bugs.php.net/bug.php?id=52923</a></li>
<li><a class="external" href="https://github.com/TYPO3/testing-framework/pull/313">https://github.com/TYPO3/testing-framework/pull/313</a></li>
</ul> TYPO3 Core - Feature #94067 (Rejected): Introduce f:condition.isInstanceOf view-helperhttp://forge.typo3.org/issues/940672021-05-04T21:01:48ZOliver Haderoliver.hader@typo3.org
<p>This view-helper implementation has been taken from<br /><a class="external" href="https://viewhelpers.fluidtypo3.org/fluidtypo3/vhs/2.1.2/Condition/Type/IsInstanceOf.html">https://viewhelpers.fluidtypo3.org/fluidtypo3/vhs/2.1.2/Condition/Type/IsInstanceOf.html</a></p> TYPO3 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 #91432 (Rejected): PageRepository PageRepository_hidDelWhere cache should consid...http://forge.typo3.org/issues/914322020-05-18T21:58:18ZOliver Haderoliver.hader@typo3.org
<p>Looking into <code>PageRepository::enableFields</code> reveals that the cache-identifier probably should have more information, e.g. some "state-hash" of the currently applied Context.</p>
<a name="Currently-considered"></a>
<h3 >Currently considered<a href="#Currently-considered" class="wiki-anchor">¶</a></h3>
<ul>
<li>show-hidden - context:visibility/includeHiddenPages</li>
<li>workspace ID - context.workspace.id</li>
</ul>
<a name="Probably-not-considered"></a>
<h3 >Probably not considered<a href="#Probably-not-considered" class="wiki-anchor">¶</a></h3>
<ul>
<li>starttime/endtime - context:date/accessTime</li>
<li><del>fe_group - context:frontend.user/groupIds (has it's own cache - but does not modify <code>PageRepository_hidDelWhere</code> cache identifier)</del>
<ul>
<li>not affected, since excluded with <code>$ignore_array</code> in <code>init</code> method</li>
</ul></li>
</ul>
<a name="Expected-impact"></a>
<h3 >Expected impact<a href="#Expected-impact" class="wiki-anchor">¶</a></h3>
<p>Using <code>PageRepository</code> without taking these two additional aspects into account, it might happen that invoking <code>PageRepository</code> multiple times with different contexts (having different aspects for date and frontend.user) leads to unexpected results - basically, the first <code>PageRepository</code> invocation defined the where clause.</p> TYPO3 Core - Bug #89311 (Rejected): Flaws in site configuration when creating new page on root-levelhttp://forge.typo3.org/issues/893112019-09-30T12:07:51ZOliver Haderoliver.hader@typo3.org
<p>Scenario: Create a new site on root-level, which leads to auto-generation of site configurationin typo3conf/sites/ (or config/sites/ in composer mode)</p>
<ul>
<li>site configuration is not created for (nested) page having <code>is_siteroot</code> enabled (compare with SlugHelper)</li>
<li>creating a sys folder on root-level (pid: 0) and changing page type to standard later does not create site configuration</li>
</ul> TYPO3 Core - Bug #87303 (Rejected): Disable autocomplete for login formshttp://forge.typo3.org/issues/873032018-12-27T14:12:09ZOliver Haderoliver.hader@typo3.org
<p>In order to apply strong security defaults it is suggested to disable autocomplete of login forms.</p>
References:
<ul>
<li><a class="external" href="https://portswigger.net/kb/issues/00500800_password-field-with-autocomplete-enabled">https://portswigger.net/kb/issues/00500800_password-field-with-autocomplete-enabled</a></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 #85000 (Rejected): Cannot add image using element browserhttp://forge.typo3.org/issues/850002018-05-14T15:40:54ZOliver Haderoliver.hader@typo3.org
<a name="Steps"></a>
<h2 >Steps<a href="#Steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>backend, edit tt_content in FormEngine of type text/image</li>
<li>open add new image dialog</li>
<li>after selecting image (SVG in this case) console error is shown</li>
</ul>
<a name="Misbehavior"></a>
<h2 >Misbehavior<a href="#Misbehavior" class="wiki-anchor">¶</a></h2>
<p>Console error <code>Uncaught TypeError: Cannot read property 'data-52-tt_content-472-image-sys_file_reference' of undefined</code><br />Refers to <code>jsfunc.inline.js</code> in method <code>getContext: function(objectId)</code></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 #78743 (Rejected): Wrong translation behavior for pages/pages_language_overlayhttp://forge.typo3.org/issues/787432016-11-18T13:30:30ZOliver Haderoliver.hader@typo3.org
<ol>
<li>on localizing a page, references of <code>pages.media</code> are not copied to <code>pages_language_overlay.media</code> in DataHandler if <code>localizeChildrenAtParentLocalization</code> is defined in TCA</li>
<li>RootlineUtility is not capable of resolving overlays correctly, ignores <code>l10n_mode</code> and uses custom reference queries -> RelationHandler could be used here</li>
</ol> TYPO3 Core - Bug #28955 (Rejected): Flushing database caches truncates table before dropping ithttp://forge.typo3.org/issues/289552011-08-12T21:38:37ZOliver Haderoliver.hader@typo3.org
<p>The database backend of the caching framework first truncates tables before dropping them.<br />This happens on calling the flush() method there and seems not to be required at all.</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>