TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692023-09-28T10:21:50ZTYPO3 Forge
Redmine TYPO3 Core - Bug #102058 (New): Meta tags rendered as XHTMLhttp://forge.typo3.org/issues/1020582023-09-28T10:21:50ZOliver Haderoliver.hader@typo3.org
<pre>
<meta name="generator" content="TYPO3 CMS" />
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />
<meta name="robots" content="index,follow" />
...
<meta property="og:image:type" content="image/png" />
<meta property="og:title" content="IN.DIE.musik e.V." />
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@InDieMusik" />
</pre>
<p><a class="external" href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/MetaTag/AbstractMetaTagManager.php#L226-L239">https://github.com/TYPO3/typo3/blob/main/typo3/sysext/core/Classes/MetaTag/AbstractMetaTagManager.php#L226-L239</a></p>
<pre>
$metaTags[] = '<meta ' .
htmlspecialchars($nameAttribute) . '="' . htmlspecialchars($property) . '" ' .
htmlspecialchars($contentAttribute) . '="' . htmlspecialchars($propertyItem['content']) . '" />';
</pre> TYPO3 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 - Bug #101415 (New): Cannot localize page in backendhttp://forge.typo3.org/issues/1014152023-07-22T17:59:04ZOliver Haderoliver.hader@typo3.org
<p>(Actions performed as admin user)</p>
<p>Error message in JavaScript console:</p>
<pre>
Uncaught TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at InputTransformer.flattenObject (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:641)
at input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:770
at Array.reduce (<anonymous>)
at InputTransformer.flattenObject (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:649)
at InputTransformer.toSearchParams (input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:481)
at AjaxRequest.withQueryArguments (ajax-request.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:352)
at Localization.localizeRecords (localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:6623)
at Object.callback (localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:5597)
at Wizard.runSlideCallback (wizard.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13:3552)
flattenObject @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
(anonymous) @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
flattenObject @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
toSearchParams @ input-transformer.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
withQueryArguments @ ajax-request.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
localizeRecords @ localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
(anonymous) @ localization.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
runSlideCallback @ wizard.js?bust=f9d9bd3aaf0d3feb0db376ef46b9f751eb2d2929:13
</pre>
<p>The reason is, that in <code>localization.ts</code>, the corresponding <code>action</code> is still <code>null, since there are two @availableLocalizationModes</code> (<code>copy</code> and <code>translate</code>), but the handling just expects to have one...</p>
<pre>
<a href="#" class="btn btn-default btn-sm t3js-localize" title=""
data-page="[Translate to Dansk:] 404" data-has-elements="0"
data-allow-copy="1" data-allow-translate="1" data-table="tt_content"
data-page-id="6" data-language-id="1" data-language-name="Dansk">
...
Translate
</a>
</pre> TYPO3 Core - Bug #100904 (New): Fallback to script-src and style-srchttp://forge.typo3.org/issues/1009042023-05-20T11:24:22ZOliver Haderoliver.hader@typo3.org
<p>Using CSP in the wild still shows several browsers not supporting the <code>-attr</code> or <code>-elem</code> (CSP level 3) variants of <code>script-src</code> and <code>style-src</code> (CSP level 1). Therefore it seems to be required, to introduce an internal merge/fall-back possibility, but still keeping the specific <code>-attr</code> or <code>-elem</code> declarations for the future.</p>
<p>Thus, when instructed, the <code>-attr</code> or <code>-elem</code> declarations shall be merged into their parent <code>script-src</code> and <code>style-src</code> directives. The instruction might be different for each scope (backend, frontend, frontend-site).</p> TYPO3 Core - Bug #98190 (Accepted): Extbase fails to resolve chained validationshttp://forge.typo3.org/issues/981902022-08-23T12:51:19ZOliver Haderoliver.hader@typo3.org
<pre>
use TYPO3\CMS\Extbase\Annotation\Validate;
class Parent extends AbstractEntity
{
protected Child $child;
}
class Child extends AbstractEntity
{
/**
* @Validate("StringLength", options={"minimum": 1, "maximum": 80})
*/
public string $title = '';
}
class ParentController extends ActionController
{
public function showAction(Parent $parent): ResponseInterface
{
// ...
}
}
</pre>
<p>Action <code>Parent.show</code> gets argument of type <code>Parent</code>, which has a non-accessible property to type <code>Child</code>, which has a validation rule of a property. Following the validation chain is correct in general, unless some part of it cannot be accessed (which is protected property <code>Parent::$child</code> in this example).</p>
<p>The result is a corresponding exception:</p>
<pre>
(1/1) #1546632293 RuntimeException
Could not get value of property "Olly\Model\Domain\Model\Parent::child",
make sure the property is either public or has a getter getChild(), a hasser hasChild() or an isser isChild().
</pre>
<p>In case validation for internal values is desired/expected, this probably would be something for reflection.<br />In case developers would "need to adjust their code", current <code>RuntimeException</code> (<code>#1546632293</code>) is semantically wrong, it has to be a <code>LogicException</code> instead.</p> TYPO3 Core - Bug #96435 (New): Apply rate limiter to mail formshttp://forge.typo3.org/issues/964352021-12-27T18:09:10ZOliver Haderoliver.hader@typo3.org
<p>In order to limit sending forms again and again (which can be automated e.g. by using Selenium or similar techniques), sending out a particular form should be rate-limited (available since TYPO3 v11).</p> TYPO3 Core - Bug #95725 (New): Title shown twice with pdfinfo using PDF/X fileshttp://forge.typo3.org/issues/957252021-10-21T18:44:48ZOliver Haderoliver.hader@typo3.org
<p>The following report has been sent to me via mail by Josef Sigritz, I'm just dumping it here:</p>
<hr />
<p>wir haben ein Problem mit dem FileContentParser der Indexed_Search: pdfinfo gibt bei PDF/X-Dateien zweimal den Title aus. Dadurch wird der eigentliche Title überschrieben.</p>
<p>Beispiel:<br />pdfinfo test.pdf</p>
<pre>
*Title: BAA010718_Broschüre_Chancen_bieten_V2.indd*
Creator: Adobe InDesign CC 13.0 (Macintosh)
Producer: Adobe PDF Library 15.0
CreationDate: Thu Feb 22 15:51:27 2018 CET
ModDate: Mon Mar 12 12:12:12 2018 CET
Tagged: no
UserProperties: no
Suspects: no
Form: none
JavaScript: no
Pages: 20
Encrypted: no
Page size: 595.276 x 841.89 pts (A4)
Page rot: 0
File size: 2292621 bytes
Optimized: yes
PDF version: 1.3
PDF subtype: PDF/X-3:2002
*Title: ISO 15930 - Electronic document file format for prepress digital data exchange (PDF/X)*
Abbreviation: PDF/X-3:2002
Subtitle: Part 3: Complete exchange suitable for colour-managed workflows (PDF/X-3)
Standard: ISO 15930-3
</pre>
<p>Verbesserungsvorschlag:<br />Klasse: typo3/typo3/sysext/indexed_search/Classes/FileContentParser.php, function splitPdfInfo</p>
<pre>
public function splitPdfInfo($pdfInfoArray)
{
$res = [];
if (is_array($pdfInfoArray)) {
foreach ($pdfInfoArray as $line) {
$parts = explode(':', $line, 2);
if (count($parts) > 1 && trim($parts[0])) {
if (!array_key_exists(strtolower(trim($parts[0])), $res)){
$res[strtolower(trim($parts[0]))] = trim($parts[1]);
}
$res[strtolower(trim($parts[0]))] = trim($parts[1]);
}
}
}
return $res;
}
</pre> TYPO3 Core - Bug #92372 (Needs Feedback): Duplicates when copying a page having moved elements in...http://forge.typo3.org/issues/923722020-09-22T16:53:41ZOliver Haderoliver.hader@typo3.org
<a name="Steps"></a>
<h2 >Steps<a href="#Steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>in live
<ul>
<li>having a page</li>
<li>having three content elements A, B, C on that page</li>
<li>having page localization of that page</li>
<li>having all three content elements localized (in connected mode)</li>
</ul>
</li>
<li>in workspace
<ul>
<li>move content element A after B</li>
<li>copy that page as new sibling on same level</li>
</ul></li>
</ul>
<a name="Bugs"></a>
<h2 >Bugs<a href="#Bugs" class="wiki-anchor">¶</a></h2>
<ul>
<li>localized version of moved record (having move-placeholders in workspace) are duplicated
<ul>
<li>→ localized version of element A is show twice in backend</li>
<li>→ in the frontend there is just one record rendered, no duplicates</li>
</ul>
</li>
<li>copied content elements in that page are not reflecting the proper order
<ul>
<li>→ should be B, A, C</li>
<li>→ actually is A, B, C since order was taken from live workspace, move-placeholders were ignored when copying the page</li>
</ul></li>
</ul>
<p>Tests at <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/8457e82596fe232b7699fdd660dd18be8bb7c800/typo3/sysext/workspaces/Tests/Functional/DataHandling/Regular/Modify/DataSet/changeContentSortingAndCopyDraftPage.csv#L36">https://github.com/TYPO3/TYPO3.CMS/blob/8457e82596fe232b7699fdd660dd18be8bb7c800/typo3/sysext/workspaces/Tests/Functional/DataHandling/Regular/Modify/DataSet/changeContentSortingAndCopyDraftPage.csv#L36</a> (starting in line 36 with uids 335+) unfortunately contain this misbehaviour...</p> TYPO3 Core - Bug #91572 (New): Streamline install tool API usagehttp://forge.typo3.org/issues/915722020-06-03T19:06:31ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #88613 (New): Replace ObjectStorage & LazyObjectStorage with symfony/collectionhttp://forge.typo3.org/issues/886132019-06-21T21:37:23ZOliver Haderoliver.hader@typo3.org
<p>For regular ObjectStorage deserialization most probably would work - however there are inconsitencies concerning object integrity due to ObjectStorage using spl_object_hash() internally. In a result it would not be possible to detach an object retrieved from repository from some deserialized ObjectStorage - basically uid should be used as identifier here which would turn ObjectStorage into EntityStorage. So, we could live with serialization of ObjectStorage.</p>
<p>For LazyObjectStorage things are getting more difficult since serialization of it would mean to serialize backreferences to parent object as well as DataMapper state, ObjectManager state and in the end class Reflection state - that turns out to be a massive collection of serialized data.</p>
<p>Thus, we experience most pain with LazyObjectStorage and its current implementation.</p> TYPO3 Core - Bug #86231 (New): Distinguish between free-mode localization and chained translationhttp://forge.typo3.org/issues/862312018-09-12T08:51:28ZOliver Haderoliver.hader@typo3.org
<p>Based on my note <a class="external" href="https://forge.typo3.org/issues/86141#note-5">https://forge.typo3.org/issues/86141#note-5</a> when analyzing the behavior</p>
<a name="TLDR"></a>
<h2 >TL;DR<a href="#TLDR" class="wiki-anchor">¶</a></h2>
<p>When skimming over the examples below, focus and compare the values in <code>l10n_parent</code> and realize that <code>l10n_source</code> is <strong>optional</strong>.</p>
<a name="Usage"></a>
<h2 >Usage<a href="#Usage" class="wiki-anchor">¶</a></h2>
<p>Localizations can be created using the graphical backend interface (e.g. page module) or by invoking direct commands to DataHandler [1]. Thus even if the page module is only valid for <code>tt_content</code> records, it does not prevent records from being translated or localized explicitly. That's why this analysis used <code>element</code> instead of <code>tt_conent</code> a pointer to a database table holding relevant records.</p>
<a name="Terminology"></a>
<h2 >Terminology<a href="#Terminology" class="wiki-anchor">¶</a></h2>
<a name="Connected-Mode"></a>
<h3 >Connected Mode<a href="#Connected-Mode" class="wiki-anchor">¶</a></h3>
<p>When translating elements, each element is bound to it's relative ancestor. This results into a chain (that can be used for language fallbacks etc.).<br />The following example illustrates that, <code>l10n_parent</code> always points to the initial record in default language, <code>l10n_source</code> points to it's relative translation ancestor - that's the record a new translation is based on. All records are connected in a chain.</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1, l10n_source=2
</pre>
<a name="Free-Mode"></a>
<h3 >Free Mode<a href="#Free-Mode" class="wiki-anchor">¶</a></h3>
<p>When localizing elements in free-mode, the previously mentioned translation chain is broken up, thus "free-mode localizaion elements" are in a specific language, but are not related to any relative ancestor and thus are idependent. The following example uses <code>element:3</code> as "free-mode localization", <code>l10n_parent</code> is set to <code>0</code>, but <code>l10n_source</code> still points to it's relative localization ancestor (just as information, not as a strict relation in like a "composition" [2] would have been).</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2
</pre>
<a name="The-Challenge"></a>
<h2 >The Challenge<a href="#The-Challenge" class="wiki-anchor">¶</a></h2>
<a name="Translation-from-existing-localization"></a>
<h3 >Translation from existing localization<a href="#Translation-from-existing-localization" class="wiki-anchor">¶</a></h3>
<p>It is possible, to create a new localization directly, that does not have a record in default language - or as alternative start a translation based on a "free-mode localization element".<br />The example shows, that the "English (Default)" record is now missing - the translation chain should(!) start with "French Translation" as first chain link. Since no record in default language s involved <code>l10n_parent</code> stay empty with <code>0</code>, only <code>l10n_source</code> point to their according relative ancestor records.</p>
<pre>
+ element:2 - French Translation - language:1, l10n_parent=0, l10n_source=1 # <- translation chain or free-mode localization?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2 # <- translation chain or free-mode localization?!
</pre>
<p>When comparing the "Franco-Canadian Translation" here to the one shown in the "Free Mode" section, it cannot be distinguished anymore, whether the record is part of a "translation chain" or has been created as "free-mode localization".</p>
<a name="The-information-in-l10n_source-is-not-mandatory"></a>
<h3 >The information in <code>l10n_source</code> is not mandatory<a href="#The-information-in-l10n_source-is-not-mandatory" class="wiki-anchor">¶</a></h3>
<p>Besides that, the information stored in the <code>l10n_source</code> field is optional and has to be configured in the control section of <code>$TCA</code> using the <code>translationSource</code> property. Thus, that information might not be available at all. The following examples show persisted results without having the <code>l10n_source</code> information.</p>
<a name="Connected-Mode-without-l10n_source"></a>
<h4 >Connected Mode without <code>l10n_source</code><a href="#Connected-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1 # <- part of a translation chain, which one?!
</pre>
<p>It is not possible anymore to determine at all, whether a record is part of a translation chain - since the relative ancestor is missing.</p>
<a name="Free-Mode-without-l10n_source"></a>
<h4 >Free Mode without <code>l10n_source</code><a href="#Free-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0 # <- translation chain or free-mode localization?!
</pre>
<p>It is (like in section "Translation from existing localization") not possible to distinguish between "connected translations" and "free-mode localizations".</p>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<p>[1]: DataHandler commands "localize" and "copyToLanguage": <a class="external" href="https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values">https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values</a><br />[2]: Association, Aggregation, Composition in UML: <a class="external" href="https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/">https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/</a></p> TYPO3 Core - Bug #81689 (On Hold): allowLanguageSynchronization does not work with FlexFormshttp://forge.typo3.org/issues/816892017-06-23T13:25:50ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #81552 (New): Disable creating new inline child records if allowLanguageSynchron...http://forge.typo3.org/issues/815522017-06-12T13:14:29ZOliver Haderoliver.hader@typo3.org
<p><img src="http://forge.typo3.org/attachments/download/32533/81552.png" alt="" loading="lazy" /><br /><img src="http://forge.typo3.org/attachments/download/32538/81552_2.png" alt="" loading="lazy" /></p>
<p>If allowLanguageSynchronization is active for inline child elements, the "create new" buttons and any other interaction shall be disabled for localized parent records - since these child records. Otherwise there's the possibility to create inconsistent and non-synchronized scenarios.</p> TYPO3 Core - Bug #78849 (New): Show logged records of DatabaseWriter in ext:beloghttp://forge.typo3.org/issues/788492016-12-01T12:33:34ZOliver Haderoliver.hader@typo3.org
<p>Log entries that have been persisted using the logging-framework are not visualized in ext:belog.<br />The reason is, that the logging-framework uses different field names for the sys_log table that are not considered.</p> TYPO3 Core - Bug #70921 (Accepted): Really resolve meaning of FlexForm fields in version dependen...http://forge.typo3.org/issues/709212015-10-21T18:28:36ZOliver Haderoliver.hader@typo3.org