TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-01T19:01:33ZTYPO3 Forge
Redmine TYPO3 Core - Feature #103241 (Resolved): Add file search to FileLinkHandlerhttp://forge.typo3.org/issues/1032412024-03-01T19:01:33ZSven Proffes.proffe@neusta.de
<p>I'd like to propose a search field for file names within FileLinkHandler, similar to the one that is used inside of \TYPO3\CMS\Filelist\ElementBrowser\FileBrowser.</p>
<p>Especially in large sites with lots of files it is quite troublesome to find files to be linked by only having the standard list at hand. And actually, it's pretty easy to take the search relevant code from FileBrowser and put it into the render() method of FileLinkHandler. Would be a nice improvement...</p>
<p>Cheers,<br />Sven</p> TYPO3 Core - Bug #103215 (New): PageContentErrorHandler attaches error output to current response...http://forge.typo3.org/issues/1032152024-02-27T14:57:22ZSven Proffes.proffe@neusta.de
<p>When a non-cacheable plugin throws a PropagateResponseException with the response of TYPO3\CMS\Frontend\Controller\ErrorController->pageNotFoundAction(), this response gets attached to the output of the originally requested page.</p>
<p><strong>Background:</strong> <br />Since TYPO3 v12 TYPO3\CMS\Core\Error\PageErrorHandler\PageContentErrorHandler uses a sub-request to render and fetch the content of the configured 404 page. In earlier versions of TYPO3 this was done with a curl request. TYPO3 v11 introduced an experimental and optional feature to use a sub-request (feature: <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Don't issue second HTTP request for error handling (Closed)" href="http://forge.typo3.org/issues/94402">#94402</a>), which was set as standard behaviour within TYPO3 v12 (<a class="external" href="https://forge.typo3.org/issues/98396">https://forge.typo3.org/issues/98396</a>).</p>
<p><strong>Problem:</strong> <br />Though the sub-request to fetch the 404 content is done as a new request, the underlying TYPO3\CMS\Core\Page\PageRenderer is a singleton. So, it still holds the already rendered (HTML) output of the original request in its property $bodyContent. During the process of rendering the sub-request, the content of the 404 page is then only added to this content. What is even more annoying: This faulty 404 content will be cached and then delivered whenever a 404 error occurs.</p>
<p><strong>Proposed solution:</strong> <br />Before sending the sub-request, PageContentErrorHandler should clear PageRenderer->bodyContent to make sure only the output of the 404 page is rendered. Perhaps like so:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">protected</span> <span class="k">function</span> <span class="n">sendSubRequest</span><span class="p">(</span><span class="kt">ServerRequestInterface</span> <span class="nv">$request</span><span class="p">,</span> <span class="kt">int</span> <span class="nv">$pageId</span><span class="p">,</span> <span class="kt">ServerRequestInterface</span> <span class="nv">$originalRequest</span><span class="p">):</span> <span class="kt">ResponseInterface</span>
<span class="p">{</span>
<span class="nv">$site</span> <span class="o">=</span> <span class="nv">$request</span><span class="o">-></span><span class="nf">getAttribute</span><span class="p">(</span><span class="s1">'site'</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="nv">$site</span> <span class="k">instanceof</span> <span class="nc">Site</span><span class="p">)</span> <span class="p">{</span>
<span class="nv">$site</span> <span class="o">=</span> <span class="nv">$this</span><span class="o">-></span><span class="n">siteFinder</span><span class="o">-></span><span class="nf">getSiteByPageId</span><span class="p">(</span><span class="nv">$pageId</span><span class="p">);</span>
<span class="nv">$request</span> <span class="o">=</span> <span class="nv">$request</span><span class="o">-></span><span class="nf">withAttribute</span><span class="p">(</span><span class="s1">'site'</span><span class="p">,</span> <span class="nv">$site</span><span class="p">);</span>
<span class="p">}</span>
<span class="nv">$request</span> <span class="o">=</span> <span class="nv">$request</span><span class="o">-></span><span class="nf">withAttribute</span><span class="p">(</span><span class="s1">'originalRequest'</span><span class="p">,</span> <span class="nv">$originalRequest</span><span class="p">);</span>
<span class="c1">// Reset already rendered content of the original request/response</span>
<span class="nv">$pageRenderer</span> <span class="o">=</span> <span class="nc">GeneralUtility</span><span class="o">::</span><span class="nf">makeInstance</span><span class="p">(</span><span class="nc">PageRenderer</span><span class="o">::</span><span class="n">class</span><span class="p">);</span>
<span class="nv">$pageRenderer</span><span class="o">-></span><span class="nf">setBodyContent</span><span class="p">(</span><span class="s1">''</span><span class="p">);</span>
<span class="k">return</span> <span class="nv">$this</span><span class="o">-></span><span class="n">application</span><span class="o">-></span><span class="nf">handle</span><span class="p">(</span><span class="nv">$request</span><span class="p">);</span>
<span class="p">}</span>
</code></pre>
<p>Another possible solution would be to reset the entire singleton instance of PageRenderer via GeneralUtility::removeSingletonInstance().</p>
<p><strong>To reproduce this problem:</strong></p>
<p>1. Have a non-cacheable (!) Extbase plugin that throws an Exception like this (FQDN only for not being ambiguous):</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">public</span> <span class="k">function</span> <span class="n">pageNotFoundAction</span><span class="p">():</span> <span class="kt">ResponseInterface</span>
<span class="p">{</span>
<span class="nv">$errorController</span> <span class="o">=</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">makeInstance</span><span class="p">(</span><span class="nc">\TYPO3\CMS\Frontend\Controller\ErrorController\ErrorController</span><span class="o">::</span><span class="n">class</span><span class="p">);</span>
<span class="nv">$response</span> <span class="o">=</span> <span class="nv">$errorController</span><span class="o">-></span><span class="nf">pageNotFoundAction</span><span class="p">(</span>
<span class="nv">$GLOBALS</span><span class="p">[</span><span class="s1">'TYPO3_REQUEST'</span><span class="p">],</span>
<span class="s1">'Content unavailable'</span><span class="p">,</span>
<span class="p">[</span>
<span class="s1">'code'</span> <span class="o">=></span> <span class="nc">\TYPO3\CMS\Frontend\Page\PageAccessFailureReasons\PageAccessFailureReasons</span><span class="o">::</span><span class="no">PAGE_NOT_FOUND</span><span class="p">,</span>
<span class="p">]</span>
<span class="p">);</span>
<span class="k">throw</span> <span class="k">new</span> <span class="nc">\TYPO3\CMS\Core\Http\PropagateResponseException\PropagateResponseException</span><span class="p">(</span><span class="nv">$response</span><span class="p">);</span>
<span class="k">return</span> <span class="nv">$this</span><span class="o">-></span><span class="nf">htmlResponse</span><span class="p">();</span>
<span class="p">}</span>
</code></pre>
<p>2. Place that plugin on a page</p>
<p>3. Inside your site config have a page based error handling for 404 errors like so</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">errorHandling</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">errorCode</span><span class="pi">:</span> <span class="m">404</span>
<span class="na">errorHandler</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">errorContentSource</span><span class="pi">:</span> <span class="s1">'</span><span class="s">t3://page?uid=xxxx'</span>
</code></pre>
<p>3. Make sure the entire TYPO3 cache has been cleared</p>
<p>4. Request the page containing the plugin with a client</p> TYPO3 Core - Bug #102751 (Resolved): AbstractUserAuthentication: Missing condition for empty chec...http://forge.typo3.org/issues/1027512024-01-04T12:48:25ZSven Proffes.proffe@neusta.de
<p>In TYPO3\CMS\Core\Authentication\AbstractUserAuthentication, line 919 reads (as of current main):</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">if</span> <span class="p">(</span><span class="nv">$this</span><span class="o">-></span><span class="n">checkPid</span> <span class="o">&&</span> <span class="nv">$this</span><span class="o">-></span><span class="n">checkPid_value</span> <span class="o">!==</span> <span class="kc">null</span><span class="p">)</span> <span class="p">{</span>
</code></pre>
<p>As $this->checkPid_value may be a string it may be empty, which is not checked. In that case TYPO3\CMS\Core\Authentication\AbstractAuthenticationService->fetchUserRecord() will end up with a corrupt SQL query containing a restriction like ... AND pid in ()...</p>
<p>So, I'd like to suggest to check for an empty string, as well.<br /><pre><code class="php syntaxhl" data-language="php"><span class="k">if</span> <span class="p">(</span><span class="nv">$this</span><span class="o">-></span><span class="n">checkPid</span> <span class="o">&&</span> <span class="nv">$this</span><span class="o">-></span><span class="n">checkPid_value</span> <span class="o">!==</span> <span class="kc">null</span> <span class="o">&&</span> <span class="nv">$this</span><span class="o">-></span><span class="n">checkPid_value</span> <span class="o">!==</span> <span class="s1">''</span><span class="p">)</span> <span class="p">{</span>
</code></pre></p> TYPO3 Core - Bug #102559 (New): CKEditor: RegExp rules in editor.config.htmlSupport not workinghttp://forge.typo3.org/issues/1025592023-11-29T16:04:58ZSven Proffes.proffe@neusta.de
<p>According to the docs of CKE/General HTML Support (see: <a class="external" href="https://ckeditor.com/docs/ckeditor5/latest/api/module_html-support_generalhtmlsupportconfig-GeneralHtmlSupportConfig.html#member-disallow">https://ckeditor.com/docs/ckeditor5/latest/api/module_html-support_generalhtmlsupportconfig-GeneralHtmlSupportConfig.html#member-disallow</a>) names, atrribute keys, CSS classes and so on for allow/disallow rules can be declared as regular expressions. Using such values in RTE YAML config files does not work, though (TYPO3 12.4.8). Such values seem to get passed as strings to the editor options and will then not be interpreted correctly by CKE:<br /><pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">editor</span><span class="pi">:</span>
<span class="na">config</span><span class="pi">:</span>
<span class="na">htmlSupport</span><span class="pi">:</span>
<span class="na">allow</span><span class="pi">:</span>
<span class="pi">-</span> <span class="pi">{</span>
<span class="nv">name</span><span class="pi">:</span> <span class="nv">/.+/</span><span class="pi">,</span>
<span class="nv">classes</span><span class="pi">:</span> <span class="pi">[</span>
<span class="nv">/my-icon-classes.*/</span>
<span class="pi">]</span>
<span class="nv">attributes</span><span class="pi">:</span> <span class="pi">[</span>
<span class="pi">{</span>
<span class="nv">key</span><span class="pi">:</span> <span class="nv">/^data-.+$/</span><span class="pi">,</span>
<span class="nv">value</span><span class="pi">:</span> <span class="nv">true</span>
<span class="pi">}</span>
<span class="pi">]</span>
<span class="pi">}</span>
</code></pre><br /> Expected behaviour: Regular expressions from YAML files in editor.config.htmlSupport.allow or .disallow will work in CKE</p> TYPO3 Core - Bug #100174 (Resolved): felogin: Recovery mail type mismatchhttp://forge.typo3.org/issues/1001742023-03-15T11:47:49ZSven Proffes.proffe@neusta.de
<p>TYPO3\CMS\FrontendLogin\Service\RecoveryService::prepareMail() creates an object of type TYPO3\CMS\Core\Mail\FluidEmail\FluidEmail but returns it as Symfony\Component\Mime\Email. This mistyped mail object is subsequently used in TYPO3\CMS\FrontendLogin\Event\SendRecoveryEmailEvent.</p>
<p>I would like to propose to use only FluidEmail within classes RecoveryService and SendRecoveryEmailEvent to make the code more consistent and avoid problems in code that listens to SendRecoveryEmailEvent to manipulate e.g. the contents of the password recovery email to be sent.</p> TYPO3 Core - Task #88706 (Closed): Streamline keys of locallang.xlfhttp://forge.typo3.org/issues/887062019-07-09T11:47:30ZSven Proffes.proffe@neusta.de
<p>Remove "ll_" prefixes from translation keys in locallang.xlf so that they share the same identifiers with the flexform settings for felogin content elements.<br />This is supposed to be a breaking change since individual _LOCAL_LANG TypoScript settings may have to be adjusted.</p> TYPO3 Core - Feature #88135 (Closed): Add new hooks for extbase pluginhttp://forge.typo3.org/issues/881352019-04-11T13:18:02ZSven Proffes.proffe@neusta.de
<p>Create hooks for the new extbase version of felogin that offer alternatives to the old piBase hooks.</p>
The hook alternatives should be:
<ul>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['beforeRedirect']</code></li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_confirmed']</code></li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['logout_confirmed']</code></li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['forgotPasswordMail']</code></li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['login_error']</code></li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['password_changed']</code></li>
</ul>
Existing hooks without new versions:
<ul>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['postProcContent']</code><br />Functionality should be replaced by appropriate fluid templating</li>
<li><code>$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['felogin']['loginFormOnSubmitFuncs']</code><br />Hidden fields and scripts should be inserted via fluid templating</li>
</ul> TYPO3 Core - Feature #88129 (Closed): Streamline existing flexform structurehttp://forge.typo3.org/issues/881292019-04-10T11:37:17ZSven Proffes.proffe@neusta.de
<p>Rename old flexform keys (e.g. 'showForgotPassword' => 'settings.showForgotPassword') so that they behave standard compliant.</p>
<ul>
<li>Adapt flexform file</li>
<li>Make piBase plugin read the new structure</li>
<li>Write upgrade wizard to migrate existing tt_content record sets of felogin from old ff keys to new</li>
</ul>