TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-25T05:45:44ZTYPO3 Forge
Redmine TYPO3 Core - Task #103477 (Under Review): Documentation for Link Validator searchFields says it i...http://forge.typo3.org/issues/1034772024-03-25T05:45:44ZSybille Peterssypets@gmx.de
<p>This is no longer true, Link Validator also checks fields if TCA is configured with "type" => "link".</p>
<blockquote>
<p>Currently, LinkValidator can only detect links for fields having at least one softref set in their TCA configuration.</p>
</blockquote>
<p><a class="external" href="https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/Configuration/Index.html#searchfields-key">https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/Configuration/Index.html#searchfields-key</a></p>
<p><strong>LinkAnalyzer.php:</strong></p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">if</span> <span class="p">((</span><span class="nv">$conf</span><span class="p">[</span><span class="s1">'type'</span><span class="p">]</span> <span class="o">??</span> <span class="s1">''</span><span class="p">)</span> <span class="o">===</span> <span class="s1">'link'</span> <span class="o">&&</span> <span class="k">empty</span><span class="p">(</span><span class="nv">$conf</span><span class="p">[</span><span class="s1">'softref'</span><span class="p">]))</span> <span class="p">{</span>
<span class="nv">$conf</span><span class="p">[</span><span class="s1">'softref'</span><span class="p">]</span> <span class="o">=</span> <span class="s1">'typolink'</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>patch can be backported up to v12.</p> TYPO3 Core - Bug #103476 (Under Review): Disrepancy of returned link type in LinktypeInternal::fe...http://forge.typo3.org/issues/1034762024-03-23T16:22:43ZSybille Peterssypets@gmx.de
<p>Currently, when calling fetchType for various link types differs if you change the order of the link types.</p>
<p>Also, InternalLinktype always returns "db" link type if the "db" link type is set by the softref parser even if it has no business doing so.</p>
<p>These link types are mutually exclusive:</p>
<p>- "db" => InternalLinktype<br />- "file" => FileLinktype<br />- "record" => RecordLinktype (introduced in patch via issue <a class="issue tracker-2 status-8 priority-3 priority-lowest" title="Feature: Make it possible to check custom record links with linkvalidator (Under Review)" href="http://forge.typo3.org/issues/103403">#103403</a>)</p>
<p>However, the softref parsers returns "db" for all of these.</p>
<p>Fixing this may avoid problems further down the line.</p>
<a name="Test-protocol-by-debugging-the-link-types"></a>
<h2 >Test protocol (by debugging the link types)<a href="#Test-protocol-by-debugging-the-link-types" class="wiki-anchor">¶</a></h2>
<p>file link: t3://file?uid=<uid><br />-------------------------------------</p>
<p>$softRefEntry<br />- value['type'] = 'db'<br />- value['recordRef'] = 'sys_file:94'<br />- value['tokenValue'] = 'file:94'</p>
<p>- result of fetchType: (order: db, file)<br /> - if class=InternatlLinktype => AbstactLinktype::fetchType: 'db'<br /> - if class=FileLinktype => FileLinkType::fetchType: 'file'</p>
<p>- after changing order: file,db<br /> - if class=FileLinktype => FileLinkType::fetchType: 'file'<br /> sets $value['type'] to 'file'<br /> - if class=InternatlLinktype => AbstactLinktype::fetchType: 'file'</p>
<p>!!!! discrepancy !!! effective type depends on order of evaluation!</p>
<blockquote><blockquote>
<p>if "file" type is not in "linktypes", file links will be checked with InteralLinktype</p>
</blockquote></blockquote>
BUT if "file" type is in "linktypes, file links will be checked with FileLinktype
<p>The result is in most cases still ok, because InternalLinktype refuses to check file links, but it is messy, makes troubleshooting difficult and may cause problems in some scenarios.</p> TYPO3 Core - Feature #103090 (Under Review): Add possibility to configure a language label for cu...http://forge.typo3.org/issues/1030902024-02-09T11:44:27ZSybille Peterssypets@gmx.de
<p>If you configure additional link types, the label which is display, will always be the link type (as used as identifier) because core LinkvalidatorController uses:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="s1">'label'</span> <span class="o">=></span> <span class="nv">$this</span><span class="o">-></span><span class="nf">getLanguageService</span><span class="p">()</span><span class="o">-></span><span class="nf">sL</span><span class="p">(</span><span class="s1">'LLL:EXT:linkvalidator/Resources/Private/Language/Module/locallang.xlf:hooks.'</span> <span class="mf">.</span> <span class="nv">$type</span><span class="p">)</span> <span class="o">?:</span> <span class="nv">$type</span><span class="p">,</span>
</code></pre>
<p>We could add another function to the LinktypeInterface to pass the language string.</p> TYPO3 Core - Feature #101935 (New): Better handling of curl error codes in linkvalidatorhttp://forge.typo3.org/issues/1019352023-09-17T14:38:56ZSybille Peterssypets@gmx.de
<p>Unfortunately, one curl error codes may be used for several different problems, e.g.</p>
<p>1. Certificate does not have matching target host name<br />2. Missing intermediate certificate - incomplete certificate chain</p>
<p>The text which is displayed by command line curl / or using Guzzle with libcurl does contain a different text in this case, but the error code is still the same (60 for the examples above).</p>
<p>A number of error codes were localized and the internal linkvalidator text is displayed, not the full error message supplied by curl.</p>
<a name="Solution"></a>
<h2 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h2>
<p>(preliminary ideas)</p>
<ul>
<li>We should find a way to make this configurable, so that the full curl error message will be displayed</li>
<li>show both (e.g. show shorter, localized message by default and show full message as detail view</li>
</ul>
<a name="Info"></a>
<h2 >Info<a href="#Info" class="wiki-anchor">¶</a></h2>
<ul>
<li>curl error codes: <a class="external" href="https://curl.se/libcurl/c/libcurl-errors.html">https://curl.se/libcurl/c/libcurl-errors.html</a></li>
<li>curl source code: <a class="external" href="https://github.com/curl/curl">https://github.com/curl/curl</a></li>
</ul>
<a name="Examples"></a>
<h2 >Examples<a href="#Examples" class="wiki-anchor">¶</a></h2>
<pre>
curl -LI "https://www.rea.ru"
curl: (60) SSL certificate problem: unable to get local issuer certificate
</pre>
<pre>
curl -I https://t3coredev13
curl: (60) SSL: no alternative certificate subject name matches target host name 't3coredev13'
</pre> TYPO3 Core - Task #101934 (Closed): Cleanup code for ContentObjectRenderer::listNum and add testshttp://forge.typo3.org/issues/1019342023-09-17T12:18:16ZSybille Peterssypets@gmx.de
<p>- Add unit tests for function ContentObjectRenderer::listNum.<br />- Improve code by renaming function argument ($char => $delimeter)<br />- Make sure arguments are always passed as strings (and not null)<br /> (as declared in PHPDoc)<br />- Improve clarity of description in PHPDoc</p>
<p>In the future typehints can be added for function arguments and<br />return type.</p> TYPO3 Core - Task #101716 (Closed): Improve changelog Breaking-100229-ConvertJSConfirmationToBitS...http://forge.typo3.org/issues/1017162023-08-20T08:45:00ZSybille Peterssypets@gmx.de
<p><a class="external" href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/13.0/Breaking-100229-ConvertJSConfirmationToBitSet.html">https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/13.0/Breaking-100229-ConvertJSConfirmationToBitSet.html</a></p>
<p>The improvements are pretty minimal and not strictly necessary (except for the formatting). Normally, I would not start a patch for this, but there is already a patch <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/80599">https://review.typo3.org/c/Packages/TYPO3.CMS/+/80599</a> where I first intended to make more changes (in particular the formatting of the bullet lists), but was deemed as too much.</p>
<p>1. bullet lists should have a newline before and after, otherwise they will not be rendered correctly, see <a class="external" href="https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/13.0/Breaking-100229-ConvertJSConfirmationToBitSet.html#impact">https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/13.0/Breaking-100229-ConvertJSConfirmationToBitSet.html#impact</a>: matches, setValue and isValid is a list</p>
<p>2. \TYPO3\CMS\Core\Type\Bitmask\JSConfirmation::method should be \TYPO3\CMS\Core\Type\Bitmask\JSConfirmation?</p>
<p>3. "calling public methods methods" should be "calling public methods"</p>
<p>4. The part for BackendUserAuthentication->jsConfirmation() in "Affected installations" could be rephrased for "affected installations"</p> TYPO3 Core - Task #101715 (Closed): Fix syntax for lists in .rst fileshttp://forge.typo3.org/issues/1017152023-08-20T08:18:19ZSybille Peterssypets@gmx.de
<p><a class="external" href="https://docs.typo3.org/m/typo3/docs-how-to-document/main/en-us/WritingReST/CommonPitfalls/Lists.html">https://docs.typo3.org/m/typo3/docs-how-to-document/main/en-us/WritingReST/CommonPitfalls/Lists.html</a></p> TYPO3 Core - Bug #101674 (Resolved): Improve user interface for selecting linktypes via checkboxe...http://forge.typo3.org/issues/1016742023-08-13T16:38:40ZSybille Peterssypets@gmx.de
<p>The linkvalidator linktypes checkbox selector can be a bit tedious to use.</p>
<p>On initially using linkvalidator, all linktypes are usually deactivated by default. So you would have to activate them all, clicking 3 or more times (there may be more custom linktypes configured).</p>
<p>Also, if not just the Reports but the Check view is enabled, you have to repeat this again.</p>
<a name="Possible-improvement"></a>
<h2 >Possible improvement<a href="#Possible-improvement" class="wiki-anchor">¶</a></h2>
<p>Add a "Toggle all" checkbox as is already used in the SelectCheckBoxElement FormEngine renderType. (the FormEngine version can be looked at using the styleguide extension: list view, page "elements select"):</p>
<p><img src="http://forge.typo3.org/attachments/download/37927/formengine_select_checkboxes.png" alt="" loading="lazy" /></p>
<a name="Screenshots"></a>
<h2 >Screenshots<a href="#Screenshots" class="wiki-anchor">¶</a></h2>
<p>before:</p>
<p><img src="http://forge.typo3.org/attachments/download/37915/linkvalidator_linktypes_checkboxes_current.png" alt="" loading="lazy" /></p>
<p>after:</p>
<p><img src="http://forge.typo3.org/attachments/download/37914/linkvalidator_linktypes_checkboxes_with_toggle_all.png" alt="" loading="lazy" /></p>
<a name="Implementation-details"></a>
<h2 >Implementation details<a href="#Implementation-details" class="wiki-anchor">¶</a></h2>
<p>Since Linkvalidator uses Fluid for the view, we would probably have to write that from scratch.</p>
<p>Implement like FormEngine type="select", renderType="selectCheckBox".</p>
<p>Behaviour:</p>
<ul>
<li>"Toggle all" gets checked as soon as all checkboxes are checked</li>
<li>"Toggle all" gets unchecked when not all checkboxes are checked</li>
<li>"Toggle all: if clicked will change state, e.g. if unchecked will change to checked and all checkboxes will be checked</li>
</ul> TYPO3 Core - Task #101673 (Resolved): Explain how to replace existing linktypes in linkvalidatorhttp://forge.typo3.org/issues/1016732023-08-13T14:28:38ZSybille Peterssypets@gmx.de
<p>Previously, it used to be possible to replace and override an existing linktype without XCLASS.</p>
<p>With the change <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/73568">https://review.typo3.org/c/Packages/TYPO3.CMS/+/73568</a>, the linktypes are automatically registered so it is not possible to deactivate or replace one of them directly. (It is still possible with XCLASS).</p>
<p>- check what is current best practice for doing this<br />- document it</p>
<p>Currently we have an example for creating a <strong>new</strong> custom type: <a class="external" href="https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/Development/LinkTypeImplementation.html">https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/Development/LinkTypeImplementation.html</a></p>
<p><del>AFAIK the identifier of the linktype must correspond to the link type returned by the link parsers, so we can't just use a different identifier.</del></p>
<p>A different identifier must be used for the new custom class.</p>
<p>Since we recommend to "override the ExternalLinktype class" as one possibility in <a href="https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/KnownProblems/Index.html" class="external">Known problems</a>, this should also be documented.</p> TYPO3 Core - Task #101671 (Closed): Disable external linktypes by default in linkvalidatorhttp://forge.typo3.org/issues/1016712023-08-13T10:40:54ZSybille Peterssypets@gmx.de
There are several known problems, most of them related to external link checking, see
<ul>
<li>open issues: e.g. <a class="issue tracker-1 status-1 priority-4 priority-default child" title="Bug: Linkvalidator reports some external URLs as "false positives" (New)" href="http://forge.typo3.org/issues/101670">#101670</a> (false positives)</li>
<li>docs: "Known problems": <a class="external" href="https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/KnownProblems/Index.html">https://docs.typo3.org/c/typo3/cms-linkvalidator/main/en-us/KnownProblems/Index.html</a></li>
</ul>
<p>We propose to deactive the external link checking by default, in order to:</p>
<p>1. have reliable out-of-the-box functionality: functionality which is on by default should work <br />2. make people more aware of problem (so they can work around it by creating their custom ExternalLinktype or leave external link checking inactive)<br />3. motivate people to contribute ...</p>
<p>This way people can still use external link checking but there is a visible caveat / disclaimer to raise awareness.</p> TYPO3 Core - Bug #101360 (Resolved): Some attributes for <a> element are not persisted (class, re...http://forge.typo3.org/issues/1013602023-07-15T07:19:47ZSybille Peterssypets@gmx.de
<p>Since TYPO3 v12 (ckeditor 5) some attributes for element a are not persisted.</p>
<p>Specifically:</p>
<p>- class<br />- rel<br />- target</p>
<a name="Reproduce"></a>
<h2 >Reproduce<a href="#Reproduce" class="wiki-anchor">¶</a></h2>
<p>Enter something like this in Source mode of RTE and switch to non-Source mode:</p>
<pre>
<p>
<a class="hallo" href="https://sdfsfsd.de" title="hallo" target="_top" rel="nofollow">link</a>
</p>
</pre>
<p>The additional attributes class,target and rel are then removed, which should not happen.</p>
<p>I used the following TSConfig:</p>
<pre>
RTE.default.preset = full
</pre> TYPO3 Core - Bug #101357 (Resolved): Broken links are not marked in RTE anymore (affects linkvali...http://forge.typo3.org/issues/1013572023-07-14T18:29:54ZSybille Peterssypets@gmx.de
<p>Seems to be the case since v12</p>
<ul>
<li>the event BrokenLinkAnalysisEvent is correctly dispatched in RteHtmlParser</li>
<li>$attributes['data-rte-error'] is set in RteHtmlParser</li>
<li>BUT, the ckeditor removes the data-rte-error attribute</li>
<li>also, the style is missing (css / sass)</li>
</ul>
<a name="Reproduce-simple-only-using-RTE"></a>
<h2 >Reproduce (simple, only using RTE)<a href="#Reproduce-simple-only-using-RTE" class="wiki-anchor">¶</a></h2>
<p>1. Insert this in the RTE in Source mode:</p>
<pre>
<p><a data-rte-error="Broken link" href="https:/iambroken.org/yesreally">link</a></p>
</pre><br />2. switch to wysiwyg mode
<p>The attribute data-rte-error is removed. This should not happen.</p>
<a name="Reproduce-with-linkvalidator"></a>
<h2 >Reproduce (with linkvalidator)<a href="#Reproduce-with-linkvalidator" class="wiki-anchor">¶</a></h2>
<ol>
<li>install linkvalidator</li>
<li>create one or more broken links</li>
<li>check links with linkvalidator (linkvalidator module)</li>
<li>in list of broken links, click pencil icon</li>
</ol>
<p>The broken links should now be marked in RTE with yellow background and red border. Also, if in source mode of RTE, you should see the attribute 'data-rte-error' in the "a" HTML elements for the broken links.</p> TYPO3 Core - Task #101260 (Closed): In redirects docs "Known problem" link to issues with categor...http://forge.typo3.org/issues/1012602023-07-06T10:43:40ZSybille Peterssypets@gmx.de
<p>Redirects now have their own category "Redirects Handling" (id 1687), so we should link to that on page "Known problems", not category "Link Handling, Site Handling & Routing" (which was correct previously).</p> TYPO3 Core - Bug #101243 (Resolved): Fix in linkvalidator PagesRepository::doesRootLineContainHid...http://forge.typo3.org/issues/1012432023-07-05T12:25:36ZSybille Peterssypets@gmx.de
<p>PagesRepository::doesRootlineContainHiddenPages() calls itself. It fetches fields from the DB without "pid" and passes the results to itself, then checks the value of pid, but this is always empty.</p>
<p><a href="https://github.com/TYPO3/typo3/blob/main/typo3/sysext/linkvalidator/Classes/Repository/PagesRepository.php" class="external">PagesRepository code</a>:</p>
<pre>
42 public function doesRootLineContainHiddenPages(array $pageInfo): bool
43 {
44 $pid = (int)($pageInfo['pid'] ?? 0);
....
59 $row = $queryBuilder
60 ->select('uid', 'title', 'hidden', 'extendToSubpages')
....
72 return $this->doesRootLineContainHiddenPages($row);
</pre>
<p>Also, it is not necessary to get the title here</p> TYPO3 Core - Bug #101113 (Resolved): System reports will show that there are no redirects conflic...http://forge.typo3.org/issues/1011132023-06-17T11:51:35ZSybille Peterssypets@gmx.de
<p><strong>Update</strong> : the implementation in the patch is a little different than described here: We create an <strong>additional</strong> status if checkintegrity was not run or is outdated. The status which shows ok or redirects is still displayed.</p>
<hr />
<p>Ideally the "reports" checks if checkintegrity was run lately (e.g. within last 24 hours) and</p>
<ul>
<li>if checkintegrity was run and no conflicts: OK</li>
<li>no redirects exist: OK</li>
<li>if checkintegrity was not run (lately) and no conflicts (known): WARNING or INFO, e.g. "there are no known redirect conflicts, please run checkintegrity" </li>
<li>if there are conflicts: WARNING (as before)</li>
</ul>
<a name="Reproduce"></a>
<h2 >Reproduce<a href="#Reproduce" class="wiki-anchor">¶</a></h2>
<p>1. Create conflicts (e.g. rename slug of page twice)<br />2. confirm conflict by loading the page and check TYPO3 log (in case of redirect to self there will be something like " Redirect /styleguide-demo-1/test/redrects points to itself! Aborting" in log<br />3. look in report: will show OK. No indication that this is incorrect or something needs to be done.<br />4. confirm checkintegrity finds something (will show 1 conflict):</p>
<pre>
php typo3/sysext/core/bin/typo3 redirects:checkintegrity
</pre>
<p>I expect a WARNING instead of OK status in report if there are conflicts and checkintegrity was never used or not used recently.</p>
<a name="Screenshots-current-core-version"></a>
<h2 >Screenshots (current core version)<a href="#Screenshots-current-core-version" class="wiki-anchor">¶</a></h2>
<p>Status: "Ok" (blissfully unaware of pending doom)</p>
<p><img src="http://forge.typo3.org/attachments/download/37745/redirects_report_ok.png" alt="" loading="lazy" /></p>
<p>Status: after running checkintegrity</p>
<p><img src="http://forge.typo3.org/attachments/download/37746/redirect_reports_conflicts.png" alt="" loading="lazy" /></p>
<p>also, the text is weird, but that's another issue.</p>
<a name="Screenshot-implementation-see-patch"></a>
<h2 >Screenshot (implementation, see patch)<a href="#Screenshot-implementation-see-patch" class="wiki-anchor">¶</a></h2>
<p>This is current version in patch, not in core!:</p>
<p><img src="http://forge.typo3.org/attachments/download/37747/redirect_reports_patch.png" alt="" loading="lazy" /></p>