TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-14T17:36:06ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103400 (Under Review): Avoid mapping route values that are out of scopehttp://forge.typo3.org/issues/1034002024-03-14T17:36:06ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #102057 (New): W3C validator complains about base64 values in CSPhttp://forge.typo3.org/issues/1020572023-09-28T09:21:37ZOliver Haderoliver.hader@typo3.org
<p>From <a class="external" href="https://validator.w3.org/nu/">https://validator.w3.org/nu/</a></p>
<blockquote>
<p>Warning: Content-Security-Policy HTTP header: Bad content security policy: Invalid base64-value (should be multiple of 4 bytes: 54)</p>
</blockquote>
<p>From the specs at <a class="external" href="https://www.w3.org/TR/CSP3/#framework-directive-source-list">https://www.w3.org/TR/CSP3/#framework-directive-source-list</a></p>
<blockquote>
<p>; Nonces: 'nonce-[nonce goes here]'<br />nonce-source = "'nonce-" base64-value "'"</p>
<p>The base64-value grammar allows both base64 and base64url encoding. These encodings are treated as equivalant when processing hash-source values. Nonces, however, are strict string matches: we use the base64-value grammar to limit the characters available, and reduce the complexity for the server-side operator (encodings, etc), but the user agent doesn’t actually care about any underlying value, nor does it do any decoding of the nonce-source value.</p>
</blockquote>
<hr />
<p>For context, the used nonce value was <code>'nonce-GFsVtSG1EzqppYEFujbWjoMJS2r8FDH_Y8mRjRl-sKg9L0sLpQqsrA'</code></p>
<ul>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH_Y8mRjRl-sKg9L0sLpQqsrA</code> in base64web</li>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH/Y8mRjRl+sKg9L0sLpQqsrA</code> in base64 (shortened)</li>
<li>that's <code>GFsVtSG1EzqppYEFujbWjoMJS2r8FDH/Y8mRjRl+sKg9L0sLpQqsrA==</code> in base64 (complete, 56 chars, 56 mod 4 = 0)</li>
</ul> TYPO3 Core - Epic #77562 (Accepted): Misbehaviors with datetime values and timezoneshttp://forge.typo3.org/issues/775622016-08-21T21:00:33ZOliver Haderoliver.hader@typo3.org
<p>This issue serves as an umbrella collector.</p>
<p>We can do little to fix stuff in v7, but we shall fix a lot in v8.</p>
<p>The goals for v8 are:</p>
<ul>
<li>Same DB content as in v7</li>
<li>Values written to FormEngine must contain the server's timezone in the ISO-format</li>
<li>FormEngine JS must be aware of the timezone used in BE to write back correct values</li>
</ul> TYPO3 Core - Bug #61719 (Closed): Warnings on flushing whole workspace with localizationshttp://forge.typo3.org/issues/617192014-09-18T15:46:45ZOliver Haderoliver.hader@typo3.org
<p>Flushing a whole workspace in the workspace, which contains record localizations, shows warnings like this in the workspace module:<br /><cite>Attempt to reset workspace for record failed: No record</cite></p>
<p>The reason for that is simple, the record already has been flushed since it's a localization.</p>
<p>Thus, either the warning can be omitted by tracking already processed elements or record localizations need to be processed before the default record.</p> TYPO3 Core - Bug #59851 (Closed): Image thumbnails sometimes in backend not shownhttp://forge.typo3.org/issues/598512014-06-24T15:41:39ZOliver Haderoliver.hader@typo3.org
<p>Sometime the image thumbnails in the page module are not shown in the TYPO3 backend.<br />The reason for that could be missing reference count values in tt_content.image.</p>
<p>A work-around is to update those counters in SQL (don't use if workspaces are enabled and used):<br /><code><br />UPDATE tt_content<br />SET image=(SELECT COUNT(*) FROM sys_file_reference<br />WHERE uid_foreign = tt_content.uid) WHERE uid IN (SELECT uid_foreign FROM sys_file_reference);<br /></code></p> TYPO3 Core - Task #58637 (Closed): Purge language packs in language modulehttp://forge.typo3.org/issues/586372014-05-08T17:35:51ZOliver Haderoliver.hader@typo3.org
<p>The language module in the backend offers the possibility to select and unselect language packs to be available.<br />If unselecting a pack that previously has been loaded, it would be nice if this pack could be removed from typo3conf/l10n/<locale>/ as well - maybe with an additional "purge" button.</p> TYPO3 Core - Task #56707 (Closed): Add functional tests for TCA types select and group/dbhttp://forge.typo3.org/issues/567072014-03-10T08:51:30ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #55454 (Closed): Buttons for explicit translation are not shownhttp://forge.typo3.org/issues/554542014-01-30T13:19:39ZOliver Haderoliver.hader@typo3.org
Steps:
<ul>
<li>enable $GLOBALS['TYPO3_CONF_VARS']['BE']['explicitConfirmationOfTranslation'] in Install Tool</li>
<li>e.g. create or modify a record in the backend</li>
<li>the additional translation buttons are not rendered correctly</li>
</ul>
<p><img src="http://forge.typo3.org/attachments/download/25925/translation_buttons.png" alt="" loading="lazy" /></p>
<p>I'm not sure whether this feature is used or documented at all.<br />It seems, that the original commit for this feature was this:<br /><a class="changeset" title="* Feature added to disable automatic update of diff data for translation when saving records. Ins..." href="http://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/a19fb26a51243b4a74d2f8d13f882900fc12df99">a19fb26a51243b4a74d2f8d13f882900fc12df99</a></p> TYPO3 Core - Bug #50531 (Closed): Deleted state is not persisted in file objectshttp://forge.typo3.org/issues/505312013-07-29T18:53:05ZOliver Haderoliver.hader@typo3.org
<p>The deleted state of file objects of the file abstraction layer is not persisted and thus to carried to the database.<br />Since the concept of using the deleted flag is not used at all, additional checks and processors to set and unset the state need to be integrated.</p> TYPO3 Core - Bug #48451 (Closed): Backend Layouts not visualizedhttp://forge.typo3.org/issues/484512013-05-22T14:16:21ZOliver Haderoliver.hader@typo3.org
<p>Backend Layouts columns are not shown in the Web>Page view.</p> TYPO3 Core - Feature #26514 (Rejected): Add possibility to include files for the global variable ...http://forge.typo3.org/issues/265142011-04-29T19:42:36ZOliver Haderoliver.hader@typo3.org
<p>Since many global statements have been cleaned-up for TYPO3 4.6, a generic way to include files is required by respecting the possible global context.<br />The new functionality shall behave similar to t3lib_div::requireOnce().</p> TYPO3 Core - Feature #9754 (Rejected): Module: Implement Workspaces List tabhttp://forge.typo3.org/issues/97542010-09-16T12:01:32ZOliver Haderoliver.hader@typo3.org
<p>Implement Workspaces List tab</p> TYPO3 Core - Bug #21726 (Closed): Updating translations from repository in extension manager fail...http://forge.typo3.org/issues/217262009-11-28T15:53:33ZOliver Haderoliver.hader@typo3.org
<p>Updating translations from repository in extension manager fails in Safari 4.0.4 on Mac OS X. Just a white page is shown - after a while, when all packages have been downloaded, suddenly the full status appears. Thus, showing the process dynamically does not work.</p>
<p>In Firefox everything works as expected.</p>
<p>(issue imported from #M12822)</p> TYPO3 Core - Feature #20294 (Closed): Integrate possibility to validate custom links for RTEhtmla...http://forge.typo3.org/issues/202942009-04-08T13:12:09ZOliver Haderoliver.hader@typo3.org
<p>In RTEhtmlarea there's a possibility to define custom links, e.g. by using a link handler. It might happen, that the name of the linkhandler (defined in $TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_content.php']['typolinkLinkHandler']) is different to the used link prefix (e.g. "linkhandler" vs. "myOwnLinkhandler:"). Furthermore it can happen that those custom links are not defined using a linkhandler at all.<br />Links that could not be validated by the current strict mechanism are shown as invalid in RTEhtmlarea.</p>
<p>The solution is to integrate a new hook that can take care of that validation in general.</p>
<p>(issue imported from #M10872)</p> TYPO3 Core - Feature #1835 (Closed): Recycler: Integrate recursive recoveringhttp://forge.typo3.org/issues/18352008-10-26T22:26:02ZOliver Haderoliver.hader@typo3.org
Imagine the following structure of deleted pages:
<ul>
<li>"First Level" (id: 1, deleted: 1)
<ul>
<li>"Second Level" (id: 2, deleted: 1)
<ul>
<li>"Third Level" (id: 3, deleted: 1)</li>
</ul></li>
</ul></li>
</ul>
<p>If the "Third Level" (id: 3) shall be recovered, it would be required that all deleted ancestors get recovered as well.</p>
On a per-user basis it shall be possible to define the following:
<ol>
<li>User is allowed to execute recursive recovering data structures (in the example, if page with id 3 gets recovered, also the ids 2 and 1 get recovered automatically)</li>
<li>User is not allowed to execute recursive recovering - thus, the record (e.g. page with id 3) isn't displayed with the possibility to be recovered in the recycler</li>
</ol>
<p>"Per-user basis" means User TSconfig and User setup module. Additionally there must be a configurable system default to that behaviour.</p>