TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-28T09:22:02ZTYPO3 Forge
Redmine TYPO3 Core - Task #103496 (Under Review): Use ISO date format by defaulthttp://forge.typo3.org/issues/1034962024-03-28T09:22:02ZMathias Brodalambrodala@pagemachine.de
<p>The configuration option <code>SYS/ddmmyy</code> is set to <code>d-m-y</code> which has issues:</p>
<p>1. Date display can be ambiguous if a 2-digit year could also be a day in a month, e.g. <em>21-04-23</em> could be <em>2021-04-23</em> or <em>2023-04-21</em><br />2. Date display can be unclear for dates in a different century, e.g. <em>21-04-71</em> could be <em>2071-04-21</em> or <em>1971-04-21</em><br />3. The current format is kind-of-German where <code>d.m.y</code> or <code>d.m.Y</code> would be used. Given that TYPO3 targets an internal audience, a bias like this should be removed.</p>
<p>For these reasons the usual ISO date format <code>Y-m-d</code> should be used by default to solve these issues.</p>
<p>Also see <a class="external" href="https://en.wikipedia.org/wiki/List_of_date_formats_by_country">https://en.wikipedia.org/wiki/List_of_date_formats_by_country</a> where basically all countries prefer a 4-digit year to avoid the above mentioned ambiguities.</p> TYPO3 Core - Bug #103202 (Resolved): TODO comments in FileInterface::setContents() cut offhttp://forge.typo3.org/issues/1032022024-02-26T11:56:46ZMathias Brodalambrodala@pagemachine.de
<p>Currently <code>FileInterface::setContents()</code> looks like this:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="cd">/**
* Replace the current file contents with the given string.
*
* @TODO : Consider to remove this function from the interface, as its
* @TODO : At the same time, it could be considered whether to make the whole
* @return $this
*/</span>
<span class="k">public</span> <span class="k">function</span> <span class="n">setContents</span><span class="p">(</span><span class="kt">string</span> <span class="nv">$contents</span><span class="p">):</span> <span class="kt">self</span><span class="p">;</span>
</code></pre>
<p>The TODO comments are cut off since the dreaded <code>[TASK] Move and Namespace (sic!) classes</code> commit. (<a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Namespace switch core main patch (Closed)" href="http://forge.typo3.org/issues/40096">#40096</a>)</p>
<p>These should be restored for the time being.</p> TYPO3 Core - Bug #103177 (New): Inconsistent behavior in MathUtility::canBeInterpretedAsInteger()...http://forge.typo3.org/issues/1031772024-02-22T11:52:58ZMathias Brodalambrodala@pagemachine.de
<p>The behavior of <code>MathUtility::canBeInterpretedAsInteger()</code> is inconsistent:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre>
<p>Assuming that the common <code>true</code> = <code>1</code>, <code>false</code> = <code>0</code> logic applies, the behavior should be fixed to accept both boolean values. Both can be coerced into integers and thus interpreted a such:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // true
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // true
</pre>
<p>Alternatively both boolean values should be rejected for consistency:</p>
<pre>
var_dump(MathUtility::canBeInterpretedAsInteger(true)); // false
var_dump(MathUtility::canBeInterpretedAsInteger(false)); // false
</pre> TYPO3 Core - Feature #103072 (New): Manage translation DB fieldshttp://forge.typo3.org/issues/1030722024-02-07T10:59:45ZMathias Brodalambrodala@pagemachine.de
<p>Currently the TCA of TYPO3 knows these <code>ctrl</code> options to enable and manage translation behavior for tables:</p>
<p>- <code>languageField</code> (<code>sys_language_uid</code> by convention)<br />- <code>transOrigPointerField</code> (<code>l10n_parent</code> by convention, <code>l18n_parent</code> in <code>tt_content</code>)<br />- <code>translationSource</code>(<code>l10n_source</code> by convention)<br />- <code>transOrigDiffSourceField</code> (<code>l10n_diffsource</code> by convention, <code>l18n_diffsource</code> in <code>tt_content</code>)</p>
<p>Each of these have 2 purposes:</p>
<p>1. Enable translations or a related feature<br />2. Tell TYPO3 which DB field to use in queries</p>
<p>This by itself is a problem but the main question is whether the names of these DB fields need to be configurable at all.</p>
<p>There are recently a lot of consolidations and simplifications in TCA. The same could be applied here:</p>
<p>- Turn these options from <code>string</code> to <code>bool</code>, thus only enable/disable the feature. TYPO3 would then use fixed DB field names and thus fully manage these.<br />- Consolidate/merge these options with better and clearer names, e.g. <code>'enableTranslations' => true</code>, <code>'trackTranslationDifferences' => true</code> or similar.</p> TYPO3 Core - Bug #103057 (Resolved): Text as page ID silently convertedhttp://forge.typo3.org/issues/1030572024-02-06T08:02:50ZMathias Brodalambrodala@pagemachine.de
<p>Given you do a request like <code>/index.php?id=foobar</code>, thus a text instead of a number as <code>id</code> then you will see the start page of your site.</p>
<p>Also number-like texts like <code>/index.php?id=2step</code> will try to use the number part of the <code>id</code>, in this case <code>/index.php?id=2</code>.</p>
<p>In all of these cases the frontend should throw a 404 instead.</p>
<p>Especially since there is no more support for page aliases since <a class="issue tracker-4 status-5 priority-4 priority-default closed child" title="Task: Remove pages.alias database field (Closed)" href="http://forge.typo3.org/issues/87356">#87356</a></p> TYPO3 Core - Bug #102374 (Resolved): Missing null check in redirect slug update hookhttp://forge.typo3.org/issues/1023742023-11-15T09:10:28ZMathias Brodalambrodala@pagemachine.de
<p>With <a class="issue tracker-4 status-5 priority-4 priority-default closed" title="Task: Unneeded pseudo-uncertain instanceof usage (Closed)" href="http://forge.typo3.org/issues/102140">#102140</a> various <code>instanceof</code> checks where removed. In case of the <code>DataHandlerSlugUpdateHook</code> of EXT:redirects this check also did ensure that unprocessable items are skipped. This is not the case anymore which can cause an error like this:</p>
<p><a class="external" href="https://github.com/pagemachine/typo3-flat-urls/actions/runs/6874052335/job/18695061932#step:3:476">https://github.com/pagemachine/typo3-flat-urls/actions/runs/6874052335/job/18695061932#step:3:476</a></p>
<blockquote>
<p>Error: Call to a member function withChanged() on null</p>
</blockquote> TYPO3 Core - Bug #102083 (Resolved): Validation triggered for fields in fieldsets disabled by var...http://forge.typo3.org/issues/1020832023-10-04T10:03:41ZMathias Brodalambrodala@pagemachine.de
<p>Given fields are placed in a fieldset and that fieldset is disabled using variants. Also given that these fields have validators.</p>
<p>Now if one tries to submit the form, it is displayed again without explanation. Inspection of the validation results shows that the validators of the fields have been triggered and couldn't validate the input of the fields. These fields could not be filled by the user since they are disabled together with their fieldset.</p>
<p>Validators of fields within disabled fieldsets should be ignored.</p> TYPO3 Core - Feature #102077 (Closed): Custom default value for getFormValue() function in varian...http://forge.typo3.org/issues/1020772023-10-02T09:20:30ZMathias Brodalambrodala@pagemachine.de
<p>The "form" extension provides a <code>getFormValue()</code> function to be used in variant conditions. It allows accessing form values without triggering an "undefined array index" error in PHP.</p>
<p>However, it unconditionally returns <code>null</code> in case a form value is undefined. This should be extended to optionally provide a custom default/fallback value. This would shorten conditions considerably, e.g. when checking for values of a <code>MultiCheckbox</code> field:</p>
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td> getFormValue("multiCheckboxField") && "foo" in getFormValue("multiCheckboxField") </td>
<td> "foo" in getformValue("multiCheckboxField", []) </td>
</tr>
</table> TYPO3 Core - Bug #102055 (Under Review): Form runtime next/previous page ignores variantshttp://forge.typo3.org/issues/1020552023-09-28T08:06:46ZMathias Brodalambrodala@pagemachine.de
<p>Given a form with conditional pages variants are not respected when the navigation is built. Example:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">type</span><span class="pi">:</span> <span class="s">Form</span>
<span class="na">prototypeName</span><span class="pi">:</span> <span class="s">standard</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">multi-step-form</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Muli step form</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">First step</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Checkbox</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">checkbox-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Check this and the 2nd step will be skipped</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-2</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Second step</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">0'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">true</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-3</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Third step</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">1'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">true</span>
</code></pre>
<p>Enabling the checkbox on the 1st page and going to the next page will show the 3rd page and a "Submit" button.</p>
<p>Not enabling the checkbox on the 1st page and going to the next page will show the 2nd page and a "Next Page" button. However, there is no next page here. In this case the button should also say "Submit".</p>
<p>The example above generally disables all subsequent pages and conditionally enables them which is a logical approach IMO. Especially because it allows you to have conditions which match their page 1:1. The reverse logic as <a href="https://docs.typo3.org/c/typo3/cms-form/main/en-us/I/Concepts/Variants/Index.html?highlight=steps#hide-steps" class="external">suggested by the docs</a> also doesn't work however:</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">type</span><span class="pi">:</span> <span class="s">Form</span>
<span class="na">prototypeName</span><span class="pi">:</span> <span class="s">standard</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">multi-step-form</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Muli step form</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">First step</span>
<span class="na">renderables</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Checkbox</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">checkbox-1</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Check this and the 2nd step will be skipped</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-2</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Second step</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">1'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
<span class="pi">-</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Page</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">page-3</span>
<span class="na">label</span><span class="pi">:</span> <span class="s">Third step</span>
<span class="na">variants</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">identifier</span><span class="pi">:</span> <span class="s">variant-2</span>
<span class="na">condition</span><span class="pi">:</span> <span class="s1">'</span><span class="s">traverse(formValues,</span><span class="nv"> </span><span class="s">"checkbox-1")</span><span class="nv"> </span><span class="s">==</span><span class="nv"> </span><span class="s">0'</span>
<span class="na">renderingOptions</span><span class="pi">:</span>
<span class="na">enabled</span><span class="pi">:</span> <span class="kc">false</span>
</code></pre> TYPO3 Core - Task #97873 (Closed): Named handlers in HTTP stackhttp://forge.typo3.org/issues/978732022-07-08T08:57:25ZMathias Brodalambrodala@pagemachine.de
<p>Since <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: RequestFactory respects Guzzle Middleware/Handler configuration from TYPO3_CONF_VARS (Closed)" href="http://forge.typo3.org/issues/88871">#88871</a> one can add custom middlewares/handlers to the handler stack used by Guzzle within TYPO3 via <code>$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']</code>.</p>
<p>These are pushed onto the handler stack without name. Chances are high that a name is available in the <code>$GLOBALS['TYPO3_CONF_VARS']['HTTP']['handler']</code> array so this should be pushed together with the middleware/handler.</p>
<p>Benefit: easier debugging.</p> TYPO3 Core - Bug #97522 (Closed): Word "new" in command "description" breaks DIhttp://forge.typo3.org/issues/975222022-04-29T16:44:01ZMathias Brodalambrodala@pagemachine.de
<p>Given a command definition like this ...</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">services</span><span class="pi">:</span>
<span class="na">_defaults</span><span class="pi">:</span>
<span class="na">autowire</span><span class="pi">:</span> <span class="kc">true</span>
<span class="na">autoconfigure</span><span class="pi">:</span> <span class="kc">true</span>
<span class="na">public</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">Acme\Foo\</span><span class="pi">:</span>
<span class="na">resource</span><span class="pi">:</span> <span class="s1">'</span><span class="s">../Classes/*'</span>
<span class="na">Acme\Foo\Command\BarCommand</span><span class="pi">:</span>
<span class="na">tags</span><span class="pi">:</span>
<span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">console.command</span>
<span class="na">command</span><span class="pi">:</span> <span class="s">example:bar</span>
<span class="na">description</span><span class="pi">:</span> <span class="s">Build a new bar</span>
<span class="na">schedulable</span><span class="pi">:</span> <span class="kc">false</span>
<span class="na">Acme\Foo\Command\QuxCommand</span><span class="pi">:</span>
<span class="na">tags</span><span class="pi">:</span>
<span class="pi">-</span> <span class="na">name</span><span class="pi">:</span> <span class="s">console.command</span>
<span class="na">command</span><span class="pi">:</span> <span class="s">example:qux</span>
<span class="na">description</span><span class="pi">:</span> <span class="s">Do something</span>
<span class="na">schedulable</span><span class="pi">:</span> <span class="kc">false</span>
</code></pre>
<p>... you get an error like this:</p>
<pre>
[ ParseError ]
syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM), expecting '('
Exception trace:
#0 ()
var/cache/code/di/DependencyInjectionContainer_<hash>.php:<line>
...
</pre>
<p>The generated service in the DI cache file:</p>
<pre><code class="php syntaxhl" data-language="php"> <span class="cd">/**
* Gets the public 'Acme\Foo\Command\BarCommand' shared autowired service.
*
* @return \Acme\Foo\Command\BarCommand
*/</span>
<span class="k">protected</span> <span class="k">function</span> <span class="n">getBarCommandService</span><span class="p">()</span>
<span class="p">{</span>
<span class="nv">$this</span><span class="o">-></span><span class="n">services</span><span class="p">[</span><span class="s1">'Acme\\Foo\\Command\\BarCommand'</span><span class="p">]</span> <span class="o">=</span> <span class="nv">$instance</span> <span class="o">=</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">makeInstanceForDi</span><span class="p">(</span><span class="nc">\Acme\Foo\Command\BarCommand</span><span class="o">::</span><span class="n">class</span><span class="p">,</span> <span class="nc">\TYPO3\CMS\Core\Utility\GeneralUtility</span><span class="o">::</span><span class="nf">makeInstanceForDi</span><span class="p">(</span><span class="nc">\Acme\Foo\Security\BarDependency</span><span class="o">::</span><span class="n">class</span><span class="p">));</span>
<span class="nv">$instance</span><span class="o">-></span><span class="nf">setName</span><span class="p">(</span><span class="s1">'example:bar'</span><span class="p">);</span>
<span class="nv">$instance</span><span class="o">-></span><span class="nf">setDescription</span><span class="p">(</span><span class="s1">'Build a \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstanceForDi(bar'</span><span class="p">);</span>
<span class="k">return</span> <span class="nv">$instance</span><span class="p">;</span>
<span class="p">}</span>
<span class="cd">/**
* Gets the public 'Acme\Foo\Command\QuxCommand' shared autowired service.
*
* @return \Acme\Foo\Command\QuxCommand
*/</span>
<span class="k">protected</span> <span class="k">function</span> <span class="n">getQuxCommandService</span><span class="p">::</span><span class="kt">class</span><span class="p">)</span>
<span class="p">{</span>
<span class="c1"># ...</span>
<span class="p">}</span>
</code></pre>
<p>This is very likely caused by the rather simple replacement here:</p>
<p><a class="external" href="https://github.com/TYPO3/typo3/blob/6f7514f51634fd98a4d4def818c3f16e28aff538/typo3/sysext/core/Classes/DependencyInjection/ContainerBuilder.php#L166">https://github.com/TYPO3/typo3/blob/6f7514f51634fd98a4d4def818c3f16e28aff538/typo3/sysext/core/Classes/DependencyInjection/ContainerBuilder.php#L166</a></p>
<pre><code class="php syntaxhl" data-language="php"><span class="nv">$code</span> <span class="o">=</span> <span class="nb">preg_replace</span><span class="p">(</span><span class="s1">'/new ([^\(\s]+)\(/'</span><span class="p">,</span> <span class="s1">'\\TYPO3\\CMS\\Core\\Utility\\GeneralUtility::makeInstanceForDi(\\1::class, '</span><span class="p">,</span> <span class="nv">$code</span><span class="p">);</span>
</code></pre> TYPO3 Core - Bug #96929 (Closed): TCA / TCA overrides with variable leakshttp://forge.typo3.org/issues/969292022-02-16T15:38:05ZMathias Brodalambrodala@pagemachine.de
<p>All TCA and TCA overrides files are included without any scoping. This means that variables defined in these files can leak into the following files.</p>
<p>Also all variables defined in <code>ExtensionManagementUtility::buildBaseTcaFromSingleFiles()</code> exist in TCA and TCA override files and could even be manipulated.</p>
<p>See <a class="external" href="https://github.com/TYPO3/typo3/blob/35f7bbb381514efd483b9bfe1570229fc454dd8f/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php#L1477">https://github.com/TYPO3/typo3/blob/35f7bbb381514efd483b9bfe1570229fc454dd8f/typo3/sysext/core/Classes/Utility/ExtensionManagementUtility.php#L1477</a></p>
<p>Possible solution: wrap the <code>require</code> calls for TCA / TCA override files with a closure.</p> TYPO3 Core - Task #96267 (New): Add dedicated error for class construction without dependencieshttp://forge.typo3.org/issues/962672021-12-07T09:29:03ZMathias Brodalambrodala@pagemachine.de
<p>Right now if <code>GeneralUtility::makeInstance()</code> is used to construct a class which uses constructor dependency injection and has not being marked as <code>public</code>, a low-level <code>\ArgumentCountError</code> is thrown by PHP.</p>
<p>This should be improved by catching this case and replacing the error with a custom one (e.g. <code>MissingDependenciesError</code>). Either that custom error already hints at possible solutions or its dedicated error code is used to link to the docs with more details. The docs could then suggest to mark the class as <code>public</code> or manually pass the dependencies as arguments.</p> TYPO3 Core - Feature #96055 (Closed): Let the command "language:update" issue warningshttp://forge.typo3.org/issues/960552021-11-23T09:57:29ZMathias Brodalambrodala@pagemachine.de
<p>Currently the CLI command <code>language:update</code> fails hard if translations could not be fetched. (No matter if for a private extension or a public extension without translations, see <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: CLI command language:update fails due to packages without translation packs (Closed)" href="http://forge.typo3.org/issues/95700">#95700</a>)</p>
<p>It would be useful if these where warnings instead by default since failed translations are updates are usually not that important and low priority.</p>
<p>An optional CLI option could be added to turn these warnings into errors again which would be useful for CI systems.</p> TYPO3 Core - Bug #96054 (Closed): Command "language:update" does not log error on missing transla...http://forge.typo3.org/issues/960542021-11-23T09:53:47ZMathias Brodalambrodala@pagemachine.de
<p>The CLI command <code>language:update</code> invokes <code>LanguagePackService::languagePackDownload()</code> for each active extension. Here a HTTP request is performed on the translation server which can fail with an exception on 404.</p>
<p>The <code>RequestFactory::request()</code> call here should be adjusted to include <a href="https://docs.guzzlephp.org/en/stable/request-options.html#http-errors" class="external"><code>['http_errors' => false]</code></a> to have Guzzle return the 404 response instead of throwing an exception. This would allow for logging this as a regular warning.</p>