TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692020-12-22T12:19:25ZTYPO3 Forge
Redmine TYPO3 Core - Bug #93154 (Closed): Text media with image enlarge on clickhttp://forge.typo3.org/issues/931542020-12-22T12:19:25ZFrank Buijzeadmin@frajaweb.nl
<p>The following error occurs when enlarge on click is on within a testmedia element. Disabling this option does not trigger this error. The type of image does not matter (svg, png tested, same result)</p>
<pre>
Core: Exception handler (WEB): Uncaught TYPO3 Exception: Argument 1 passed to TYPO3\CMS\Core\Imaging\ImageManipulation\Area::__construct() must be of the type float, null given, called in /home/dashboard/domains/usersense.io/typo3_src-10.4.11/typo3/sysext/core/Classes/Resource/Processing/LocalCropScaleMaskHelper.php on line 209 | TypeError thrown in file /home/dashboard/domains/usersense.io/typo3_src-10.4.11/typo3/sysext/core/Classes/Imaging/ImageManipulation/Area.php in line 50.
</pre> TYPO3 Core - Bug #92351 (Closed): Schedulerhttp://forge.typo3.org/issues/923512020-09-20T20:52:57ZFrank Buijzeadmin@frajaweb.nl
<p>Using wrong directory when typo3_src is symlinked.</p>
<p>Resulting in tasks that cannot be found when job is automated via scheduler</p>
<p>See screenshots.</p> TYPO3 Core - Bug #90999 (Closed): selectMultipleSideBySide adds non selected itemshttp://forge.typo3.org/issues/909992020-04-11T11:16:54ZFrank Buijzeadmin@frajaweb.nl
<p>Since 9.5.15 selectMultipleSideBySide fails. It adds non-selected items on saving an object via Backend. It works fine with 9.5.13.</p>
<p>Steps<br />1. Create a new object with a MM relation (to a translatable object)<br />2. Add an item by selecting it from the selectMultipleSideBySide view<br />3. Save the item</p>
<p>The saving is correct, but the rendering adds a random item from the list. On next save the automatically added item is stored as well, resulting in an unwanted link to an additional object.</p> TYPO3 Core - Bug #90948 (New): Object translation broken if object outside Site Configurationhttp://forge.typo3.org/issues/909482020-04-04T16:17:05ZFrank Buijzeadmin@frajaweb.nl
<p>When Objects are placed outside a Site Configuration (root tree of site), translation fails to work. This was not an issue TYPO3 9.</p>
<p>It is common to share translatable objects between different site configurations. It seems to be related to the selection of sys_languages. Inside a site-tree all available languages are available. Outside a site-tree only the main language is availble. Hence, no translation.</p>
<a name="Screenshots"></a>
<h3 ><strong>Screenshots</strong><a href="#Screenshots" class="wiki-anchor">¶</a></h3>
<a name="Image-1-my-site-configuration"></a>
<h4 >Image 1: my site configuration<a href="#Image-1-my-site-configuration" class="wiki-anchor">¶</a></h4>
<p><img src="http://forge.typo3.org/attachments/download/35040/image1.jpg" title="my site configuration" alt="my site configuration" loading="lazy" /></p>
<a name="Image-2-website-languages-global"></a>
<h4 >Image 2: website languages (global)<a href="#Image-2-website-languages-global" class="wiki-anchor">¶</a></h4>
<p><img src="http://forge.typo3.org/attachments/download/35039/image2.jpg" title="website languages (global)" alt="website languages (global)" loading="lazy" /></p>
<a name="Image-3a-and-b-outside-site-tree-not-working"></a>
<h4 >Image 3a and b: outside site tree (not working)<a href="#Image-3a-and-b-outside-site-tree-not-working" class="wiki-anchor">¶</a></h4>
<p><img src="http://forge.typo3.org/attachments/download/35038/image3a.jpg" title="outside site tree (not working)" alt="outside site tree (not working)" loading="lazy" /><br /><img src="http://forge.typo3.org/attachments/download/35037/image3b.jpg" title="outside site tree (not working)" alt="outside site tree (not working)" loading="lazy" /></p>
<a name="Image-4a-and-b-inside-site-tree-working"></a>
<h4 >Image 4a and b: inside site tree (working)<a href="#Image-4a-and-b-inside-site-tree-working" class="wiki-anchor">¶</a></h4>
<p><img src="http://forge.typo3.org/attachments/download/35036/image4.jpg" title="inside site tree (working)" alt="inside site tree (working)" loading="lazy" /><br /><img src="http://forge.typo3.org/attachments/download/35035/image4b.jpg" title="inside site tree (working)" alt="inside site tree (working)" loading="lazy" /></p> TYPO3 Core - Bug #88391 (Closed): chash not generated in f:widget.paginate ViewHelperhttp://forge.typo3.org/issues/883912019-05-18T22:10:53ZFrank Buijzeadmin@frajaweb.nl
<p>chash is not generated for links in f:widget.paginate. useCacheHash argument is missing and not passed to f:widget.link resulting in a non working Paginate in combination with Extbase</p>
<p>Updates required in:<br />- Arguments of viewhelper, add useCacheHash<br />- Provide the useCacheHash to f:widget:link in Index.html</p> TYPO3 Core - Bug #84568 (Closed): chash not generatedhttp://forge.typo3.org/issues/845682018-03-30T21:35:06ZFrank Buijzeadmin@frajaweb.nl
<p>The following problem occurs if one creates a plugin with multiple controller, action combinations.</p>
<p>If one generates a link without additional arguments for the first action in the first controller in the configuration no chash will be generated. This in turn causes a "cHash empty" error if a POST ajax call is made to the generated url.</p>
<p>If one inserts a fake action before the first action in the list a cHash will be generated for the now second action. When a call is made to this new url everything works as expected and the "cHash empty" message is gone.</p>
<p>Four possible solutions:<br />- Adjust the chash check for this particular situation. No arguments, no cHash check (probably the preferred one)<br />- Generate a cHash for the first action as well<br />- Introduce an option to force the generation of a cHash in Fluid, even if it's the default action<br />- Describe this situation in the documentation</p>
<p><f:uri.action action="getUsersViaAjaxAdmin" controller="User" pageType="500"/></p>
<p>ext_localconf.php</p>
<p>\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(<br /> 'FraJaWeB.'.$_EXTKEY,<br /> 'AjaxAdmin',<br /> array(<br /> 'User' => 'getUsersViaAjaxAdmin',<br /> 'Customer' => 'getCustomersViaAjaxAdmin',<br /> ),<br /> // non-cacheable actions<br /> array(<br /> 'User' => 'getUsersViaAjaxAdmin,<br /> 'Customer' => 'getCustomersViaAjaxAdmin',<br /> )<br />);</p>
<p>My temporary fix:</p>
<p>\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(<br /> 'FraJaWeB.'.$_EXTKEY,<br /> 'AjaxAdmin',<br /> array(<br /> 'User' => 'bogus,getUsersViaAjaxAdmin',<br /> 'Customer' => 'getCustomersViaAjaxAdmin',</p>
<pre><code>),<br /> // non-cacheable actions<br /> array(<br /> 'User' => 'getUsersViaAjaxAdmin,<br /> 'Customer' => 'getCustomersViaAjaxAdmin',<br /> )<br />);</code></pre> TYPO3 Core - Bug #83425 (Closed): Custom validatorshttp://forge.typo3.org/issues/834252017-12-25T22:02:25ZFrank Buijzeadmin@frajaweb.nl
<p>Parsing goes wrong in case of @validate in combination with a custom validator. The problem is that the $ sign gets stripped (in tags), resulting in a failure of the parseValidatorAnnotation function in TYPO3/CMS/Extbase/Classes/Validation/ValidatorResolver.php. The function is called from the new getMethodValidateAnnotations in the same class.</p>
<p>Apparently this function still uses the tags and not the new annotations approach. The validators array annotations/contains the correct value.</p>
<p>If I dump the ClassSchema I see the following:<br /><pre>
[tags] => Array
(
[param] => Array
(
[0] => \FraJaWeB\FwCore\Domain\Model\User $user
[1] => string $username
)
[validate] => Array
(
[0] => user \FraJaWeB\FwCore\Domain\Validator\User2Validator
)
)
[annotations] => Array
(
[validators] => Array
(
[0] => $user \FraJaWeB\FwCore\Domain\Validator\User2Validator
)
)
</pre></p> TYPO3 Core - Bug #71568 (Closed): always_populate_raw_post_data=http://forge.typo3.org/issues/715682015-11-13T20:44:20ZFrank Buijzeadmin@frajaweb.nl
<p>Warning in Install Tool</p>
<p>--<br />PHP always_populate_raw_post_data is deprecated</p>
<p>always_populate_raw_post_data=<br />PHP is configured to automatically populate $HTTP_RAW_POST_DATA.<br />Warning: Expect fatal errors in central parts of the CMS if the value is not changed to:<br />always_populate_raw_post_data=-1<br />--</p>
<p>always_populate_raw_post_data switch is not available in PHP 7. Setting this value is impossible, resulting in numerous error and odd behaviour.</p> TYPO3 Core - Bug #71567 (Closed): FAL FileReferencehttp://forge.typo3.org/issues/715672015-11-13T20:40:17ZFrank Buijzeadmin@frajaweb.nl
<p>The following error occurs when switching from PHP 5.6 to PHP 7 in combination with TYPO3 7.6 LTS</p>
<p>1: PHP Warning: Declaration of TYPO3\CMS\Extbase\Domain\Model\FileReference::setOriginalResource(TYPO3\CMS\Core\Resource\FileReference $originalResource) should be compatible with TYPO3\CMS\Extbase\Domain\Model\AbstractFileFolder::setOriginalResource(TYPO3\CMS\Core\Resource\ResourceInterface $originalResource) in ***/typo3_src-7.6.0/typo3/sysext/extbase/Classes/Domain/Model/FileReference.php line 22</p> TYPO3 Core - Bug #22178 (Closed): Deprecated function sql_regcase in cms/tslib/class.tslib_pagege...http://forge.typo3.org/issues/221782010-02-24T17:38:28ZFrank Buijzeadmin@frajaweb.nl
<p>The function pagegenInit() in typo3/sysext/cms/tslib/class.tslib_pagegen.php is using the function sql_regcase() which is deprecated in PHP 5.3.</p>
<p>The default front-end search form is using this function. At least if a link in the result set is clicked.</p>
<p>Possible solution:</p>
<p>Add an additional function to replace sql_regcase:</p>
<p><?php<br />function mb_sql_regcase($string,$encoding='auto'){<br /> $max=mb_strlen($item,$encoding);<br /> for ($i = 0; $i < $max; $i++) {<br /> $char=mb_substr($item,$i,1,$encoding);<br /> $up=mb_strtoupper ($char,$encoding);<br /> $low=mb_strtolower($char,$encoding);<br /> $ret.=($up!=$low)?'['.$up.$low.']' : $char;<br /> }<br /> return $ret;<br />}<br />?></p>
<p>(issue imported from #M13649)</p>