TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-27T17:18:45ZTYPO3 Forge
Redmine TYPO3 Core - Bug #103494 (Under Review): Linkvalidator uses tstamp field directly without checkin...http://forge.typo3.org/issues/1034942024-03-27T17:18:45ZSybille Peterssypets@gmx.de
<p><strong>This should be merged before <a class="external" href="https://review.typo3.org/c/Packages/TYPO3.CMS/+/83612">https://review.typo3.org/c/Packages/TYPO3.CMS/+/83612</a></strong></p>
<p>TCA should be used to determine which field is relevant for tstamp (and if there is such a field) before using it for a DB query</p>
<p>$GLOBALS['TCA'][$table]['ctrl']['tstamp']</p>
<a name="Reproduce"></a>
<h2 >Reproduce<a href="#Reproduce" class="wiki-anchor">¶</a></h2>
<ol>
<li>Change configuration to mod.linkvalidator.searchFields.sys_redirect.target</li>
<li>check links (with a broken redirect target)</li>
<li>in the list of broken links, click pencil to edit redirect target field</li>
<li>close edit field</li>
</ol>
<p>Now, exception is thrown.</p> TYPO3 Core - Bug #101119 (Closed): SoftReferenceParserFactory has 2 required constructor argument...http://forge.typo3.org/issues/1011192023-06-19T10:17:11ZSybille Peterssypets@gmx.de
<p><strong>Update</strong> : It should be possible to get an instance of an object with GeneralUtility::makeInstance which is instantiated with DI without the constructor arguments (at least from looking at makeInstance).</p>
<p>I am still investigating how to reproduce this, what is exactly the problem and if it is a core bug ....</p>
<hr />
<p>core SoftReferenceParserFactory.php constructor has 2 arguments, but is instantiated without arguments in ReferenceIndex.php if object not passed in constructor.</p>
<p>This occurred after installation of causal/extractor and only in combination with specific other extensions. I have not been able to narrow it down. The exception appears when opening "Extension Configuration".</p>
<p>Anyhow, the code in the core looks wrong:</p>
<p>in /typo3/sysext/core/Classes/Database/ReferenceIndex.php line 126</p>
<pre>
$this->softReferenceParserFactory = $softReferenceParserFactory ?? GeneralUtility::makeInstance(SoftReferenceParserFactory::class);
</pre>
<p>typo3/sysext/core/Classes/DataHandling/SoftReference/SoftReferenceParserFactory.php line 33</p>
<pre>
public function __construct(FrontendInterface $runtimeCache, LoggerInterface $logger)
</pre>
<p>instantiated in FileIndexRepository line 339</p>
<pre>
public function updateRefIndex($id)
{
$refIndexObj = GeneralUtility::makeInstance(ReferenceIndex::class);
</pre>
<a name="Versions"></a>
<h2 >Versions<a href="#Versions" class="wiki-anchor">¶</a></h2>
<ul>
<li>reproduced with 11.5.28, not checked with v12 / main</li>
</ul>
<a name="Exception-stack-trace"></a>
<h2 >Exception stack trace<a href="#Exception-stack-trace" class="wiki-anchor">¶</a></h2>
<p>see file exception_extconf.txt (linked below)</p> TYPO3 Core - Task #99772 (Closed): Deprecate TCA renderType="inputLink" at some pointhttp://forge.typo3.org/issues/997722023-01-31T14:09:48ZSybille Peterssypets@gmx.de
<p>The type="input", renderType="inputLink" was replaced in TYPO3 v12 with type="link", however the inputLink still works. At some point it can be deprecated and removed.</p>
<p>typo3/sysext/backend/Migrations/Code/ClassAliasMap.php:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">return</span> <span class="p">[</span>
<span class="s1">'TYPO3\\CMS\\Backend\\Form\\Element\\InputLinkElement'</span> <span class="o">=></span> <span class="nc">\TYPO3\CMS\Backend\Form\Element\LinkElement</span><span class="o">::</span><span class="n">class</span><span class="p">,</span>
</code></pre> TYPO3 Core - Task #93428 (Closed): Rename function getHeaderFlashMessagesForCurrentPid() in PageL...http://forge.typo3.org/issues/934282021-02-04T07:54:53ZSybille Peterssypets@gmx.de
<p>see explanation in</p>
<blockquote>
<p>- flash messages: those are normally shown after an action, e.g saving something was succesful<br />- callouts: give the user permanent feedback</p>
</blockquote>
<p><a class="external" href="https://forge.typo3.org/issues/93422#note-2">https://forge.typo3.org/issues/93422#note-2</a></p>
<p>Could be renamed to getCalloutsForCurrentPid().</p>
<p>Since PageLayoutController is non-internal I assume this is a breaking change, so cannot be done until v12.</p> TYPO3 Core - Bug #92972 (New): Softref parsers should take syntax format of field into accounthttp://forge.typo3.org/issues/929722020-12-02T11:08:42ZSybille Peterssypets@gmx.de
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>make it possible to always set "format" for TCA column type "text" and "input" </li>
<li>use the format in the softref parsers</li>
</ul>
<a name="Explanation"></a>
<h2 >Explanation<a href="#Explanation" class="wiki-anchor">¶</a></h2>
<p>Currently, AFAIK, the softref parser does not evaluate what format the field has. Possible formats can be HTML (e.g. tt_content.bodytext), plain text, TypoScript (e.g. sys_template.config, sys_template.constants), comma separated list.</p>
<p>The <a href="https://docs.typo3.org/m/typo3/reference-tca/master/en-us/ColumnsConfig/Type/textT3editor.html#format" class="external">format</a> can already (partly) be set in TCA, but only if type is 'text' and 'renderType' is 't3editor', for example as 'typoscript' for sys_template.config.</p>
<p>Since t3editor is used only for typoscript it does not really seem to make sense that the format can be set for this renderType but not for renderType default.</p>
<blockquote>
<p>renderType='t3editor': System extension “t3editor” provides an enhanced textarea for TypoScript input</p>
</blockquote>
<blockquote>
<p>format: The value specifies the language t3editor should handle. Allowed values: css, html, javascript, php, typoscript, xml</p>
</blockquote>
<p>For tt_content.bodytext neither renderType nor format are set.</p>
<p>If this is handled consistently, you would not have to pass 'linklist' to the softref parser, but read this from format as well (e.g. for findRef_typolink()).</p>
<p>By being able to handle the formatting consistently in all softref parsers, it might be possible to simplify things and also avoid inconsistencies.</p>
<a name="Examples"></a>
<h1 >Examples:<a href="#Examples" class="wiki-anchor">¶</a></h1>
<p>Currently, URLs <strong>in comments</strong> in sys_template config or constants are added to the reference index, e.g.</p>
<pre>
sys_template.config:
# https://example.org
</pre>
<p>When saved, this record is created:</p>
<pre>
+----------------------------------+--------------+--------+--------+-------------+-------------+------------+---------+---------+-----------+-----------+---------+---------------------+
| hash | tablename | recuid | field | flexpointer | softref_key | softref_id | sorting | deleted | workspace | ref_table | ref_uid | ref_string |
+----------------------------------+--------------+--------+--------+-------------+-------------+------------+---------+---------+-----------+-----------+---------+---------------------+
| a7ad94098b4c8ea1293af92fcd8be9b5 | sys_template | 2 | config | | url | 2 | -1 | 0 | 0 | _STRING | 0 | https://example.org |
+----------------------------------+--------------+--------+--------+-------------+-------------+------------+---------+---------+-----------+-----------+---------+---------------------+
</pre>
<p>If TypoScript were parsed correctly, this should not happen.</p>
<p>(Not sure why URLs in TypoScript are added to reference index in the first place and whether this has any benefit).</p> TYPO3 Core - Bug #92546 (Closed): Misleading errror message for pagetree if user has no access to...http://forge.typo3.org/issues/925462020-10-12T14:31:31ZSybille Peterssypets@gmx.de
<pre><code class="text syntaxhl" data-language="text">Page tree error
Got unexpected response from the server. Please check logs for details.
</code></pre>
<a name="Reproduce"></a>
<h2 >Reproduce<a href="#Reproduce" class="wiki-anchor">¶</a></h2>
<ol>
<li>Create user / group which has no access to the pages, e.g. the page belongs to different user / group and "Everybody" has no access:</li>
</ol>
<p><img src="http://forge.typo3.org/attachments/download/35523/permissions.png" alt="" loading="lazy" /></p>
<a name="Expected"></a>
<h2 >Expected<a href="#Expected" class="wiki-anchor">¶</a></h2>
<p>It is correct that the user has no access but the error message is misleading.</p> TYPO3 Core - Bug #92541 (New): Text of flash message is misleading for JavaScript errorshttp://forge.typo3.org/issues/925412020-10-12T11:53:07ZSybille Peterssypets@gmx.de
<p>Example: Page tree error message</p>
<pre><code class="text syntaxhl" data-language="text">Page tree error
Got unexpected response from the server. Please check logs for details.
</code></pre>
<p>When I get this type of error, the logs are usually empty. This is usually a JavaScript error displayed in browser console.</p>
<p>It would be great if error message which recommends to look in logs is only given if error has been logged.</p>
<p>Would be great if user got a different hint if there has been a JavaScript error.</p> TYPO3 Core - Feature #92193 (New): Make console commands (directly) visible in list of scheduler ...http://forge.typo3.org/issues/921932020-09-04T09:55:26ZSybille Peterssypets@gmx.de
<p>When you create a new task in the scheduler, you can see a list of available tasks in Class.</p>
<p><img src="http://forge.typo3.org/attachments/download/35430/scheduler1.png" alt="" loading="lazy" /></p>
<p>Here, you have to select "Execute console commands" to see a list of the console commands.</p>
<p>This makes the usability a bit clunky, because you do not have a full list of what is available. You have to choose "console command" and only then do you see the console commands (or not).</p>
<p>Extension authors may want to make their schedulable tasks available as console commands because this adds more flexibility (as they can be called on the console or via cron directly). However, having the commands then be a bit hidden is a downside of this.</p>
<a name="Possible-solution"></a>
<h2 >Possible solution<a href="#Possible-solution" class="wiki-anchor">¶</a></h2>
<ul>
<li>add the console commands to the list of scheduler tasks to be visible like any other scheduler task.</li>
</ul> TYPO3 Core - Task #91904 (Accepted): Unify naming of "Install tool" vs "Admin Tool" vs. "System T...http://forge.typo3.org/issues/919042020-07-30T14:57:27ZSybille Peterssypets@gmx.de
<p>"Install Tool" was renamed to "Admin Tool", see <a class="external" href="https://docs.typo3.org/m/typo3/guide-installation/master/en-us/In-depth/TheInstallTool/Index.html">https://docs.typo3.org/m/typo3/guide-installation/master/en-us/In-depth/TheInstallTool/Index.html</a></p>
<blockquote>
<p>The Admin tool was called “Install Tool” in earlier versions, you will likely still see that term in some places.</p>
</blockquote>
<p>When logged in, you will see "Admin tool" in the top left.</p>
<p>There are still some places in the core, where install tool is still used. Might avoid confusion if this is cleaned up.</p>
<p>1. Message, when Install tool is locked:</p>
<blockquote>
<p>The <strong>Install Tool</strong> is locked To enable the <strong>Install Tool</strong>, the file ENABLE_INSTALL_TOOL must be created in the directory typo3conf/. The file must be writable by the web server user. The filename is case-sensitive but the file itself can be empty.</p>
</blockquote>
<blockquote>
<p>Security note: When you are finished with the <strong>Install Tool</strong>, you should rename or delete this file. It will automatically be deleted if you log out of the Install Tool or if the file is older than one hour.</p>
</blockquote>
<p>2. Don't know if we want to change the filename too ENABLE_INSTALL_TOOL. Might cause more problems than it solves.</p>
<p>3. various places in core</p>
<p>4. Some more occurrences in official docs (e.g. install guide).</p>
<p>--</p>
<p><strong>Update:</strong> See also <a class="issue tracker-1 status-1 priority-4 priority-default" title="Bug: Naming of admin vs. system maintainer privilege levels and modules is confusing (New)" href="http://forge.typo3.org/issues/88810">#88810</a> which suggests it should rather be named "System Tool" than "Admin Tool"</p> TYPO3 Core - Feature #91018 (Accepted): Automatically convert Links with "external" URLs to same ...http://forge.typo3.org/issues/910182020-04-14T10:10:03ZSybille Peterssypets@gmx.de
<p>I think it is a common phenomenon, that editors copy URLs out of the site and use it for the links. This may be especially true for large sites where it is tedious to click through the page tree in the link wizard.</p>
<p>The downside is:</p>
<ul>
<li>these links will break if the URL changes. Even if there are redirects, it is not necessary to redirect in this case and it does have an unnecessary performance and load impact.</li>
<li>these URLs are more permanent. The page id will not change, the URL may change. </li>
<li>will not work for translated pages, e.g. when the content is translated you have to change the links. If these were page links they would automatically already point to the translated page</li>
</ul>
<p>There is already an extension which does these conversions but it currently does not work for RTE: <a class="external" href="https://github.com/georgringer/uri2link/">https://github.com/georgringer/uri2link/</a></p>
<p>Also, I am wondering, why do this at a later point? Why not do it when the link is created:</p>
<ul>
<li>e.g. in the Link wizard. Either automatically convert the external URL link to page link in the link wizard or via a button. Make this configurable if this should always be done, be done in control of the editor or not at all.</li>
<li>or, on RTE -> DB transformation</li>
</ul>
<p>The conversion should work for RTE field and non-RTE fields.</p>
<p>In any case it would be good to additionally have a wizard or command line tool which does the conversion for old content.</p> TYPO3 Core - Task #90848 (Accepted): No longer possible to enter several pids in linkvalidator sc...http://forge.typo3.org/issues/908482020-03-27T07:07:13ZSybille Peterssypets@gmx.de
<p>TYPO3 10,9,8 ...</p>
<p>I am not sure when this was changed:</p>
<p>In the scheduler task for linkvalidator it is no longer possible to enter several page ids in "Start page (uid)"</p>
<p>This used to be possible which was very helpful if you had several sites. In that case, you would get an aggregated report in the mail with information per site.</p>
<p>Also, you could exclude inactive sites this way. Now you can only enter startpage of one site or 0. (Of course, you can always enter several scheduler tasks).</p>
<p>In some cases, sites that are being updated will most likely have problems and need to change this. (Not sure if the old behaviour will still work with several pids).</p>
<p><img src="http://forge.typo3.org/attachments/download/35011/linkvalidator_scheduler.png" alt="" loading="lazy" /></p>
<p>Anyhow, it is no longer possible to enter several pids, separated by comma, which used to be possible.</p>
<p>(I would actually prefer an option to determine this automatically, based on sites configuration)</p> TYPO3 Core - Task #87394 (Closed): composer gerrit:setup should be available for all platformshttp://forge.typo3.org/issues/873942019-01-11T08:51:38ZSybille Peterssypets@gmx.de
<p>I am currently updating the Contribution Guide. I would like to simplify the setup.</p>
<p>composer gerrit:setup sets up both commit hooks: commit-msg and pre-commit. The pre-commit hook currently may not run on Windows.</p>
<p>For this reason, you can't just write: just run composer gerrit:setup to setup commit hooks. You have to write: for windows do ..., for Linux / Mac do ...</p>
<p>So, it might be useful to do one of the following:</p>
<ol>
<li>make the pre-commit hook portable</li>
<li>only copy the commit-msg hook with gerrit:setup</li>
<li>or check before copying if it will run on current system in <a href="https://github.com/TYPO3/TYPO3.CMS/blob/master/Build/Scripts/composer/InstallerScripts.php" class="external">InstallerScripts:enablePreCommitHook</a></li>
</ol> TYPO3 Core - Task #85007 (Closed): Remove setting style for broken links in RteHtmlParser::markBr...http://forge.typo3.org/issues/850072018-05-15T09:05:14ZSybille Peterssypets@gmx.de
<p>Once patch <a class="external" href="https://review.typo3.org/c/56943/">https://review.typo3.org/c/56943/</a> is merged, setting the style for broken links in RteHtmlParser should be removed in master.</p> TYPO3 Core - Bug #84887 (Closed): pageTSconfig subpage level is not considered in Linkvalidatorhttp://forge.typo3.org/issues/848872018-04-27T16:36:40ZSybille Peterssypets@gmx.de
<p>Currently, linkvalidator is highly configurable, the settings can be applied via TSconfig for a page / user / group.</p>
<p>When checking links however, only the page TSconfig of the current start page is considered. Different page TSconfig on a subpage is not considered. It does not override the settings.</p>
<a name="Steps-to-Reproduce"></a>
<h1 >Steps to Reproduce<a href="#Steps-to-Reproduce" class="wiki-anchor">¶</a></h1>
<ol>
<li>Create 2 pages with 1 tt_content element each, with a broken link each in in tt_content.header and tt_content.bodytext. I page is parent of the other</li>
<li>Set the TSconfig on the first page to scan bodytext and header</li>
<li>Set the TSconfig of the child page to only scan bodytext</li>
<li>Start "Check links" from the parent page and view report</li>
<li>Start "Check links" from the child page and view report</li>
</ol>
<a name="Expected-result"></a>
<h1 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h1>
<p>Get same number of broken links for child page: 1 (only bodytext)</p>
<a name="Actual-result"></a>
<h1 >Actual result<a href="#Actual-result" class="wiki-anchor">¶</a></h1>
<p>If "Check links" is started on child page, the result is correct.</p>
<p>If "Check links" is started on parent page, the result is 2 links for child page (not correct)</p>
<a name="Solution"></a>
<h1 >Solution<a href="#Solution" class="wiki-anchor">¶</a></h1>
<p>Either:</p>
<ul>
<li>keep current behaviour and document this (I think having a different configuration on a subpage is highly unlikely to ever be required)</li>
<li>change behaviour to check for configuration on subpages</li>
</ul> TYPO3 Core - Task #84840 (Closed): Document EXT:filemetadatahttp://forge.typo3.org/issues/848402018-04-23T16:28:06ZSybille Peterssypets@gmx.de
<p>Migrated from Core API docs project on Forge (<a class="external" href="https://forge.typo3.org/issues/52769">https://forge.typo3.org/issues/52769</a>)</p>