TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692019-02-20T13:50:49ZTYPO3 Forge
Redmine TYPO3 Core - Bug #87750 (Closed): Argument 3 passed to TYPO3\CMS\Core\DataHandling\History\Record...http://forge.typo3.org/issues/877502019-02-20T13:50:49ZChristian Eßlchristian.essl@seam.at
<p>The function "TYPO3\CMS\Core\DataHandling\History\RecordHistoryStore::*addRecord*()" expects $payload to be an array:</p>
<pre><code class="php syntaxhl" data-language="php"><span class="k">public</span> <span class="k">function</span> <span class="n">addRecord</span><span class="p">(</span><span class="kt">string</span> <span class="nv">$table</span><span class="p">,</span> <span class="kt">int</span> <span class="nv">$uid</span><span class="p">,</span> <span class="kt">array</span> <span class="nv">$payload</span><span class="p">):</span> <span class="kt">string</span>
<span class="p">{</span>
</code></pre>
<p>However, when called in the DataHandler, $payload can be <strong>null</strong> from the <strong>checkStoredRecord</strong> function:</p>
<p>in /.../public_html/typo3/sysext/core/Classes/DataHandling/DataHandler.php line 7318<br /><pre><code class="php syntaxhl" data-language="php">
<span class="nv">$newRow</span> <span class="o">=</span> <span class="p">[];</span>
<span class="k">if</span> <span class="p">(</span><span class="nv">$this</span><span class="o">-></span><span class="n">enableLogging</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// Checking the record is properly saved if configured</span>
<span class="k">if</span> <span class="p">(</span><span class="nv">$this</span><span class="o">-></span><span class="n">checkStoredRecords</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// !!! checkStoredRecord(), depending on TCA configuration returns either an array or NULL</span>
<span class="nv">$newRow</span> <span class="o">=</span> <span class="nv">$this</span><span class="o">-></span><span class="nf">checkStoredRecord</span><span class="p">(</span><span class="nv">$table</span><span class="p">,</span> <span class="nv">$id</span><span class="p">,</span> <span class="nv">$fieldArray</span><span class="p">,</span> <span class="mi">1</span><span class="p">);</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="nv">$newRow</span> <span class="o">=</span> <span class="nv">$fieldArray</span><span class="p">;</span>
<span class="nv">$newRow</span><span class="p">[</span><span class="s1">'uid'</span><span class="p">]</span> <span class="o">=</span> <span class="nv">$id</span><span class="p">;</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="mf">...</span>
<span class="c1">// Store in history</span>
<span class="c1">// !!! this now triggers a TypeError, because $newRow is NULL</span>
<span class="nv">$this</span><span class="o">-></span><span class="nf">getRecordHistoryStore</span><span class="p">()</span><span class="o">-></span><span class="nf">addRecord</span><span class="p">(</span><span class="nv">$table</span><span class="p">,</span> <span class="nv">$id</span><span class="p">,</span> <span class="nv">$newRow</span><span class="p">);</span>
</code></pre></p> TYPO3 Core - Bug #78830 (Closed): images attached to record in workspace get removed when publish...http://forge.typo3.org/issues/788302016-11-29T14:10:21ZChristian Eßlchristian.essl@seam.at
<p>Hi,</p>
<p>we discovered a scenario in which image attachments of a record, created in a workspace, get removed, when published to the live workspace.<br />I attached an example extension with just a dummy model and an image field. It appears to only happen with the TCA setting of type "group":</p>
<p><code>'image' => array(<br /> 'exclude' => 0,<br /> 'label' => 'LLL:EXT:dummy/Resources/Private/Language/locallang_db.xlf:tx_dummy_domain_model_dummy.image',<br /> 'config' => array(<br /> 'type' => 'group',<br /> 'internal_type' => 'file',<br /> 'uploadfolder' => 'uploads/tx_dummy',<br /> 'show_thumbs' => 1,<br /> 'size' => 1,<br /> 'maxitems' => 1,<br /> 'allowed' => $GLOBALS['TYPO3_CONF_VARS']['GFX']['imagefile_ext'],<br /> 'disallowed' => '',<br /> ),<br /> ),</code></p>
<p>To reproduce this problem, the following steps are required:<br />- install a new typo3 7.6.12<br />- install the "workspace" extension and the attached "dummy" extension<br />- create a root page and a workspace record "Test" <br />- switch to the workspace and create a new "dummy" record with an uploaded image attached.<br />- check the upload path "uploads/tx_dummy/filename.*" - the file should be there as expected<br />- go to the workspace module and publish the new record to LIVE<br />- now check the upload path again - file suddenly got removed and is nowhere else to be found<br />- if you now open the record in the list module, you will get a "File is missing!" error message.</p> TYPO3 Core - Bug #73616 (Closed): Different standards used in GeneralUtility::validEmail (RFC 369...http://forge.typo3.org/issues/736162016-02-23T10:07:18ZChristian Eßlchristian.essl@seam.at
<p>Tested in 6.2.18, but may also occur in current versions.</p>
<p>At the moment GeneralUtility::validEmail() is following RFC3696, where as the internally used swiftmailer is follwing RFC 2822.<br />We had a case where an email with the format "user@¹gmx.at" was checked as valid by TYPO3s internal function but lead to an Swift_RfcComplianceException when sending an email.</p>
<p>The problem may or may not occur because of the different standards that were used. Currently this would mean, that as a TYPO3 developer you would always have to check against the \Swift_Mime_Grammar instead of GeneralUtility::validEmail() to be on the safe side, if the email at some time should be sent by TYPO3s internal methods.</p> TYPO3 Core - Bug #49444 (Closed): No file found for given UID after deleting a referenced image filehttp://forge.typo3.org/issues/494442013-06-26T12:58:10ZChristian Eßlchristian.essl@seam.at
<p>How to reproduce:</p>
<p>- create a content element of type "image" with a referenced image file<br />- delete the image file in filelist<br />- try to access the previously created content element in the backend.</p>
<p>You will get the following exception:</p>
<p>Uncaught TYPO3 Exception<br />#1317178604: No file found for given UID. (More information)</p>
<p>TYPO3\CMS\Core\Resource\Exception\FileDoesNotExistException thrown in file<br />/usr/www/users/naderq/typo3/sysext/core/Classes/Resource/ResourceFactory.php in line 266.</p> TYPO3 Core - Bug #47222 (Closed): Uncaught TYPO3 Exception in RTE when using FAL makes the tcefo...http://forge.typo3.org/issues/472222013-04-15T08:51:46ZChristian Eßlchristian.essl@seam.at
<p>TYP3 6.0.4</p>
<p>1.) Create a content element that uses rte in the backend.<br />2.) In the rte create a link to a file or a path that doesn't exist (anymore).<br />3.) Save and reload the tceform.</p>
<p>You will get this error:</p>
<pre>
Uncaught TYPO3 Exception
TYPO3\CMS\Core\Resource\Exception\FileDoesNotExistException thrown in file
/var/www/vhosts/domain.com/httpdocs/typo3/sysext/core/Classes/Resource/Driver/AbstractDriver.php in line 399.
14 TYPO3\CMS\Core\Resource\Driver\AbstractDriver::getFile("veranstaltungen/seminarpauschalen/")
</pre>
<p>This makes it virtually impossible to use TYPO3 6.0 as an editor right now, because the editor has no way to fix this minor mistake in the link. You would have to directly edit the database field in an external tool because tceform itself becomes unusable.</p> TYPO3 Core - Bug #44597 (Closed): height of inline-relational-records in ie8http://forge.typo3.org/issues/445972013-01-17T12:04:25ZChristian Eßlchristian.essl@seam.at
<p>The height of inline-relational-records in the tceform is too big in internet explorer (tested in ie8) (screenshot)</p>
<p>because of this css:</p>
<p><code>div.t3-form-field-header-inline td {<br /> padding:0px;<br /> margin:0px;<br /> *min-height:100px;*<br />}</code></p>
<p>located in typo3/sysext/t3skin/stylesheets/structure/element_tceforms.css</p> TYPO3 Core - Bug #25852 (Closed): rtehtmlarea ignores attributes with "-" (like in the HTML5 data...http://forge.typo3.org/issues/258522011-04-08T11:46:56ZChristian Eßlchristian.essl@seam.at
<p>The RTE (rtehtmlarea) is correctly configured to take over own html attributes in the link-element. <br />But when I try to take an attribute with a "-" in it, it will automatically get removed from the element.</p>
<p>For example:<br />"data-role" will not be taken over.<br />"datarole" will be taken over.</p>
<p>In HTML5 it is common to use "-"-Lines for data-attributes.</p> TYPO3 Core - Feature #13825 (Closed): Support for opening Backend sites in new tabshttp://forge.typo3.org/issues/138252011-03-14T15:34:52ZChristian Eßlchristian.essl@seam.at
<p>When I try to open a link inside the backend as a new tab (middle mousebutton click), not the module of the clicked link but the entry page of the backend will be loaded. (As there are no get parameters given) This seems to be a big usability problem for me. - If I want to open a second tab of a specific module I always would have to go through the complete navigation again to get where I want.</p> TYPO3 Core - Feature #25078 (Closed): Cropping support for content element imageshttp://forge.typo3.org/issues/250782011-02-18T10:15:33ZChristian Eßlchristian.essl@seam.at
<p>Would'nt it be useful to make imagecropping work in content elements with images, like in typoscript with the "c"-Parameter?</p>
<p>For example if you want to display a list of various images with the same aspect ratio, the first you would do is to specify a width and height. - One of the two values with a "c"-Parameter to be added, to ensure, that the images are cropped to the same size.</p>
<p>Right now, this can only be applied with extra typoscript, as the inputs in the content elements do not accept additional parameters for width and height of the images.</p>
<p>(issue imported from #M17642)</p> TYPO3 Core - Bug #22141 (Closed): First login attempt to the backend fails every timehttp://forge.typo3.org/issues/221412010-02-19T10:06:38ZChristian Eßlchristian.essl@seam.at
<p>I updated from 4.2 to 4.3.</p>
<p>The first attempt to log into the backend fails every time. - The second works well.</p>
<p>This problem is browser- und user-undependent.</p>
<p>I tried clearing the be_session-table and site-cookies, but it has no effect.<br />(issue imported from #M13582)</p>