TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-11-14T08:19:47ZTYPO3 Forge
Redmine TYPO3 Core - Bug #86922 (Closed): Save modal does not appear for some input typeshttp://forge.typo3.org/issues/869222018-11-14T08:19:47ZDaniel Siepmanncoding@daniel-siepmann.de
<p>How I reproduce this:</p>
<p>1) Add new Content Element "Menu > Pages" <br />2) Select a page through wizard.<br />3) Click "View"</p>
<p>The modal is not shown. The preview is opened in a new tab. The form is submitted. The record is not saved but still "NEW" in the bottom right corner.</p>
<p>You can repeat as long as you want, the record is not saved, nor a modal is shown.</p>
<p>Until you fill in something within "header" click on "View". Afterwards you can remove the value from "Header" and it works as expected.</p>
<p>I can reproduce this with the above field and flexforms.</p> TYPO3 Core - Bug #86592 (Closed): Argument 2 passed to TYPO3\CMS\Extbase\Routing\ExtbasePluginEnh...http://forge.typo3.org/issues/865922018-10-08T10:06:19ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Given the following routing configuration:<br /><pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">routeEnhancers</span><span class="pi">:</span>
<span class="na">ExamplePlugin</span><span class="pi">:</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">Extbase</span>
<span class="na">extension</span><span class="pi">:</span> <span class="s">ExampleExtension</span>
<span class="na">plugin</span><span class="pi">:</span> <span class="s">Address</span>
<span class="na">defaultController</span><span class="pi">:</span> <span class="s1">'</span><span class="s">Address::index'</span>
<span class="na">routes</span><span class="pi">:</span>
<span class="pi">-</span>
<span class="na">routePath</span><span class="pi">:</span> <span class="s1">'</span><span class="s">/edit/{address}'</span>
<span class="na">_controller</span><span class="pi">:</span> <span class="s1">'</span><span class="s">Address::edit'</span>
<span class="na">_arguments</span><span class="pi">:</span>
<span class="s1">'</span><span class="s">address'</span><span class="err">:</span> <span class="s1">'</span><span class="s">address'</span>
<span class="pi">-</span>
<span class="na">routePath</span><span class="pi">:</span> <span class="s1">'</span><span class="s">/update'</span>
<span class="na">_controller</span><span class="pi">:</span> <span class="s1">'</span><span class="s">Address::update'</span>
<span class="na">aspects</span><span class="pi">:</span>
<span class="na">address</span><span class="pi">:</span>
<span class="na">type</span><span class="pi">:</span> <span class="s">PersistedPatternMapper</span>
<span class="na">tableName</span><span class="pi">:</span> <span class="s1">'</span><span class="s">tx_exampleextension_domain_model_address'</span>
<span class="na">routeFieldPattern</span><span class="pi">:</span> <span class="s1">'</span><span class="s">^(?P<company_name>.+)-(?P<uid>\d+)$'</span>
<span class="na">routeFieldResult</span><span class="pi">:</span> <span class="s1">'</span><span class="s">{company_name}-{uid}'</span>
</code></pre></p>
<p>and submitting the edit form, results in the url <em><a class="external" href="https://workshop-extension.at.localhost/plugin/update">https://workshop-extension.at.localhost/plugin/update</a></em> and the error:<br /><pre>
Argument 2 passed to TYPO3\CMS\Extbase\Routing\ExtbasePluginEnhancer::applyControllerActionValues() must be of the type array, null given
</pre></p> TYPO3 Core - Bug #85587 (Closed): Configured mime types do not prevent form processinghttp://forge.typo3.org/issues/855872018-07-18T13:18:08ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The configured mime types for file uploads are added as validator for the TypoConverter. This only prevents file upload and creates an <em>TYPO3\CMS\Extbase\Error\Error</em>. This will not prevent further processing if no other validation error occurs.</p> TYPO3 Core - Bug #85586 (Closed): translateElementError-ViewHelper does not work with TYPO3\CMS\E...http://forge.typo3.org/issues/855862018-07-18T12:58:23ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Under some circumstances an <em>TYPO3\CMS\Extbase\Error\Error</em> is rendered instead of an <em>TYPO3\CMS\Extbase\Validation\Error</em>, which is extending the <em>Error\Error</em>.</p>
<p>This is not supported. There are checks for <em>Validation\Error</em> to retrieve the code.</p>
<p>These circumstances are for example:<br />Non complete file uploads, e.g. to server settings and file size.<br />Non allowed mime type.</p> TYPO3 Core - Bug #85456 (New): columnsOverrides not possible for type grouphttp://forge.typo3.org/issues/854562018-07-02T17:38:34ZDaniel Siepmanncoding@daniel-siepmann.de
<p>It's not possible to overwrite configuration of columns of type group via <em>columnsOverrides</em>.<br />It partially works, but not for the data source.</p>
<p>Due to configuration in <em>formEngine.formDataGroup.tcaDatabaseRecord</em> the order is wrong.</p>
<p><em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaColumnsOverrides::class</em> is called after <em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaGroup::class</em>.<br />While it would be easy to adjust order, it's in fact not. <em>TcaColumnsOverrides</em> does need <em>\TYPO3\CMS\Backend\Form\FormDataProvider\DatabaseRecordTypeValue</em> which in turn needs <em>\TYPO3\CMS\Backend\Form\FormDataProvider\TcaGroup::class</em> again.</p>
<p>This way one can not re-use the <em>records</em> column of <em>tt_content</em> for any other record. While it works while selecting entries, it does not work either for suggest nor for re-display in backend. As always the original <em>tt_content</em> records are fetched for persisted IDs.</p> TYPO3 Core - Bug #82978 (Closed): Core Extension felogin prevents Helmut Hummel secure web approachhttp://forge.typo3.org/issues/829782017-11-12T14:45:09ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The extension felogin does conflict with Helmut Hummel approach of secure web folder structure.</p>
<p>The extension uses TSFE->tmpl to fetch the tempalte file. This way it's always relative to the document root where no private files are available.<br />This needs to be adjusted to template files are searched within the typo3 folder.</p>
<p>The issue is the following line: <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/v8.7.8/typo3/sysext/felogin/Classes/Controller/FrontendLoginController.php#L145">https://github.com/TYPO3/TYPO3.CMS/blob/v8.7.8/typo3/sysext/felogin/Classes/Controller/FrontendLoginController.php#L145</a><br />Bu using the TemplateService it will always be relative to document root.<br />As <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/v8.7.8/typo3/sysext/core/Classes/TypoScript/TemplateService.php#L1351">https://github.com/TYPO3/TYPO3.CMS/blob/v8.7.8/typo3/sysext/core/Classes/TypoScript/TemplateService.php#L1351</a> tells to</p>
<blockquote>
<p>Returns the reference used for the frontend inclusion, checks against allowed paths for inclusion.</p>
</blockquote>
<p>This is definitively the wrong API usage, as templates are not frontend inclusions.</p>
<p>Therefore some other API should be used.</p> TYPO3 Core - Bug #82762 (Closed): It' not possible to provide render types for passthroughhttp://forge.typo3.org/issues/827622017-10-14T12:09:03ZDaniel Siepmanncoding@daniel-siepmann.de
<p>As passthrough is the only field not processed for database, it's the only possible TCA type to implement custom information display without adding non existing columns to list view.</p>
<p>Therefore it should be either possible to add custom render types to implement custom renderings for passthrough, or to add a switch to tca type `user` to prevent it from being fetched from database.</p>
<p>Usecase:<br />We want to add a google map to a record. This map is generated using two additional columns `lat` and `lng`. Also we need to register a new column in TCA to render the map itself, which is not available in database as nothing is stored.<br />We either can use a new `renderMode` or a TCA column of type `user`.<br />Both get fetched from database in list view when editor selects the field, which is possible.</p>
<p>It's not possible to select `passthrough` fields in this view. So either there should be a switch for `user` to prevent columns from being processed, or process `passthrough` as usual by node factory, exactly <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/typo3/sysext/backend/Classes/Form/Container/SingleFieldContainer.php#L79">https://github.com/TYPO3/TYPO3.CMS/blob/TYPO3_8-7/typo3/sysext/backend/Classes/Form/Container/SingleFieldContainer.php#L79</a> .</p> TYPO3 Core - Bug #76662 (Rejected): Drag and Drop in Page module for new content elements ignores...http://forge.typo3.org/issues/766622016-06-16T15:14:49ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Using the click version of the wizard works as expected. Using drag and drop ignores the configured default values. Instead the ctype is selected by the provided key, all other values are ignored completely.</p> TYPO3 Core - Bug #76661 (Closed): Suggest Wizard ajax response ignores columnsOverrideshttp://forge.typo3.org/issues/766612016-06-16T15:09:33ZDaniel Siepmanncoding@daniel-siepmann.de
<p>We override the <em>records</em> fields with different configuration.<br />That works on Rendering the BE-Form, but isn't taken into account while processing the ajax of suggest wizard. He only takes a look at the TCA, without the overwrites and is not usable. The only way to prevent insertions of invalid records is to disable the wizard via <em>columnsOverrides</em>.</p>
<p>Configuration is attached as screenshots, here is the example for copy and paste:<br /><pre>
'columnsOverrides' => [
'records' => [
'config' => [
'minitems' => 1,
'foreign_table' => 'fe_users',
'allowed' => 'fe_users',
'wizards' => [
'suggest' => [
'default' => [
'pidList' => '2',
'searchCondition' => 'pid = 2',
'searchWholePhrase' => 1,
'additionalSearchFields' => 'username, city, country',
],
],
],
],
],
],
</pre></p>
<p>For 7.6.9 the following line is used to fetch configuration:<br /><pre>
$fieldConfig = $GLOBALS['TCA'][$table]['columns'][$field]['config'];
$this->overrideFieldNameAndConfigurationForFlexform($table, $field, $row, $fieldConfig);
$wizardConfig = $fieldConfig['wizards']['suggest'];
$queryTables = $this->getTablesToQueryFromFieldConfiguration($fieldConfig);
$whereClause = $this->getWhereClause($fieldConfig);
</pre><br /><em>sysext/backend/Classes/Form/Wizard/SuggestWizard.php</em></p>
<p>So the configuration is ignored.</p> TYPO3 Core - Bug #75014 (Closed): l18n_cfg not respected in fluid_styled_contents of type special...http://forge.typo3.org/issues/750142016-03-11T09:45:21ZDaniel Siepmanncoding@daniel-siepmann.de
<p><strong>The result</strong><br />Pages in default location are shown in menus, even if they should not.</p>
<p><strong>How to reproduce</strong><br />Create a page in default language, select option "Hide default translation of page" under "Behaviour".<br />Create a content element of kind "special menus" and select the created page. Create the element in default language.<br />The page will be shown and link is broken as page should not be visible because it's not available in default language.<br /><a class="external" href="https://docs.typo3.org/typo3cms/FrontendLocalizationGuide/BasicSetupOfALocalizedWebsite/LocalizationOverviewOfThePageTree/Index.html#hiding-default-translation-of-pages">https://docs.typo3.org/typo3cms/FrontendLocalizationGuide/BasicSetupOfALocalizedWebsite/LocalizationOverviewOfThePageTree/Index.html#hiding-default-translation-of-pages</a></p>
<p>For our own implementation we had to add the following SQL to fix the issue:<br /><pre>
if ($this->arguments[static::ARGUMENT_TABLE] === 'pages') {
$where .= ' AND pages.l18n_cfg != 1';
}
</pre></p> TYPO3 Core - Bug #70382 (Closed): Highlight current result item in suggest wizardhttp://forge.typo3.org/issues/703822015-10-05T15:19:09ZDaniel Siepmanncoding@daniel-siepmann.de
<p>This already happens if you hover with the mouse.<br />But selecting via cursor keys doesn't highlight the current selection, preventing you from effectively using the suggest and filling out forms with a keyboard.</p> TYPO3 Core - Bug #66139 (Rejected): PersistentObjectConverter can't convert ValueObjecthttp://forge.typo3.org/issues/661392015-03-30T12:10:48ZDaniel Siepmanncoding@daniel-siepmann.de
<p>The <em>PersistentObjectConverter</em> can't convert <em>ValueObject</em> from an URL or something else, if they have the property <em>uid</em>.</p>
<p>In our use case we have a form that maps to an <em>ValueObject</em>. After handling the result we do a redirect back to the form providing the <em>ValueObject</em> as a parameter. The <em>UriBuilder</em> will create the url and attach the property <em>uid</em> to it.<br />Once extbase tries to map the parameters back to the <em>ValueObject</em> he find the property <em>uid</em> and can't set it to the target because there is no <em>setUid</em>.</p>
<p>One idea would be to add an <i>TransientObjectConverter</i> that will extend the existing <i>PersistentObjectConverter</i> and overwrite <em>canConvertFrom</em> and <em>getSourceChildPropertiesToBeConverted</em>.</p>
<p>As Mathias Brodala told me in Slack, we should check Flow and keep the sync. As I'm not that into Flow I could not say whether __identity is the same there as uid in CMS.</p>
<p>Affected are all versions above 4.7 incl.</p> TYPO3 Core - Bug #62536 (Closed): Extbase TypeConverter Integer can't work with null anymorehttp://forge.typo3.org/issues/625362014-10-29T15:27:09ZDaniel Siepmanncoding@daniel-siepmann.de
<p>While migrating our TYPO3 4.7 instance to 6.2 we found out that the new TypeConverter for integers can't convert "null" anymore.</p>
<p>This is the old code:<br /><pre>
public function convertFrom($source, $targetType, array $convertedChildProperties = array(), \TYPO3\CMS\Extbase\Property\PropertyMappingConfigurationInterface $configuration = NULL) {
if ($source === NULL || strlen($source) === 0) {
return NULL;
}
if (!is_numeric($source)) {
return new \TYPO3\CMS\Extbase\Error\Error('"%s" is no integer.', 1332933658, array($source));
}
return (int)$source;
}
</pre><br />And the new one:<br /><pre>
public function convertFrom($source, $targetType, array $convertedChildProperties = array(), \TYPO3\CMS\Extbase\Property\PropertyMappingConfigurationInterface $configuration = NULL) {
if (strtolower($source) === "null" || $source === NULL || strlen($source) === 0) {
return NULL;
}
if (!is_numeric($source)) {
return new \TYPO3\CMS\Extbase\Error\Error('"%s" is no integer.', 1332933658, array($source));
}
return (int)$source;
}
</pre></p>
<p>The file is located under <em>/typo3/sysext/extbase/Classes/Property/TypeConverter/IntegerConverter.php</em>.</p>
<p>The problem is that null as a string can't be converted to null. This worked in 4.7 and is a breaking change for our extensions.</p>
<p>If this is behavior is intended, where is the change documented?<br />Looks like the following commit introduced this: <a class="external" href="https://git.typo3.org/Packages/TYPO3.CMS.git/blobdiff/c60a671bb5d7e4b21ef55ffee0028b32d66cad55..8c3f329a18b9496d270ae2467025bf3fee720c49:/typo3/sysext/extbase/Classes/Property/TypeConverter/IntegerConverter.php">https://git.typo3.org/Packages/TYPO3.CMS.git/blobdiff/c60a671bb5d7e4b21ef55ffee0028b32d66cad55..8c3f329a18b9496d270ae2467025bf3fee720c49:/typo3/sysext/extbase/Classes/Property/TypeConverter/IntegerConverter.php</a> So FLOW differs from the old Extbase way. Perhaps the context is different and the string is managed before inside FLOW?</p> TYPO3 Core - Bug #55517 (Closed): ClassLoader not working with NullBackend for legacy classes http://forge.typo3.org/issues/555172014-01-31T14:58:05ZDaniel Siepmanncoding@daniel-siepmann.de
<p>Setting <em>cache_core</em> to <em>NullBackend</em><br /><pre>
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['cache_core']['backend'] = '\TYPO3\CMS\Core\Cache\Backend\NullBackend';
</pre> <br />creates Fatal Errors for calls to old class names like <em>t3lib_extMgm</em>.<br />You can reproduce it e.g. with a call to the <em>t3lib_extMgm</em> class inside <em>ext_tables.php</em> of an extension.</p>
<p>This error is not catched using the <em>Install Tool</em> <em>Check for broken extensions</em> option.</p> TYPO3 Core - Bug #32966 (Closed): Make TYPO3AJAX rendering false, null, 0, ... http://forge.typo3.org/issues/329662012-01-04T15:13:28ZDaniel Siepmanncoding@daniel-siepmann.de
At the moment, the class can't render any of the following values:
<ul>
<li>"" (an empty string)</li>
<li>0 (0 as an integer)</li>
<li>0.0 (0 as a float)</li>
<li>"0" (0 as a string)</li>
<li>NULL</li>
<li>FALSE</li>
<li>array() (an empty array)</li>
<li>var $var; (a variable declared, but without a value in a class)</li>
</ul>
<p>I think it's okay for some of them, but I like to be able to return something like:<br /><pre>
{"effected_rows":0}
</pre><br />That's not possible at the moment, because calling:<br /><pre>
$ajaxObj->addContent( 'effected_rows', 0);
</pre><br />Issn't saved, because 0 is an "empty" value and not saved.</p>
<p>Everything takes part at the method: <a class="external" href="http://api.typo3.org/typo3v4/current/html/class_8typo3ajax_8php_source.html#l00119">http://api.typo3.org/typo3v4/current/html/class_8typo3ajax_8php_source.html#l00119</a></p>
<p>I think this is a missing "feature" or more a bug.<br />I hope you will fix this. It's not a big thing.</p>