TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692021-09-10T07:57:29ZTYPO3 Forge
Redmine TYPO3 Core - Feature #95172 (Rejected): Support different connections for read and write access t...http://forge.typo3.org/issues/951722021-09-10T07:57:29ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If you have multiple redis containers with replications you will want to read from one redis instance and write to the other.<br />At the moment, the TYPO3 redis caching backend doesn't support configuring separate connectivity configuration for read and write.</p>
<p>Suggestion:</p>
<p>The possibility to configure <strong>one</strong> connection should be kept as it is for simplicity and backwards compatibility. Additionally the keys <code>read</code> and <code>write</code> can override individual options of the default connection.</p>
<pre><code class="yaml syntaxhl" data-language="yaml"><span class="na">SYS</span><span class="pi">:</span>
<span class="na">caching</span><span class="pi">:</span>
<span class="na">cacheConfigurations</span><span class="pi">:</span>
<span class="na">extbase</span><span class="pi">:</span>
<span class="na">backend</span><span class="pi">:</span> <span class="s1">'</span><span class="s">\TYPO3\CMS\Core\Cache\Backend\RedisBackend'</span>
<span class="na">options</span><span class="pi">:</span>
<span class="na">defaultLifetime</span><span class="pi">:</span> <span class="m">31536000</span>
<span class="na">hostname</span><span class="pi">:</span> <span class="s1">'</span><span class="s">%env(REDIS_REPLICA)%'</span>
<span class="na">port</span><span class="pi">:</span> <span class="m">6379</span>
<span class="na">database</span><span class="pi">:</span> <span class="m">0</span>
<span class="na">write</span><span class="pi">:</span>
<span class="na">hostname</span><span class="pi">:</span> <span class="s1">'</span><span class="s">%env(REDIS_MASTER)%'</span>
</code></pre> TYPO3 Core - Feature #92929 (Closed): Allow registering additional "trees" in Configuration Modulehttp://forge.typo3.org/issues/929292020-11-25T09:37:55ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The list of available "trees" (<code>$GLOBALS['TYPO3_CONF_VARS']</code>, <code>$GLOBALS['TCA']</code>, ..., <code>Event Listeners</code>) of the Configuration module is hardcoded in the <a href="https://github.com/TYPO3/TYPO3.CMS/blob/73bcf9a1d971308f3ad66638ca1587a8dac8f681/typo3/sysext/lowlevel/Classes/Controller/ConfigurationController.php#L64" class="external">ConfigurationController</a> . An item for the form extension is <a href="https://github.com/TYPO3/TYPO3.CMS/blob/73bcf9a1d971308f3ad66638ca1587a8dac8f681/typo3/sysext/lowlevel/Classes/Controller/ConfigurationController.php#L179" class="external">added</a> via <code>if (ExtensionManagementUtility::isLoaded('form'))</code>.</p>
<p>Instead there should be an interface to add configration trees. The <code>form</code> extension and other extensions that maintain a configuration can then just add themselves to the module.</p> TYPO3 Core - Feature #92780 (Rejected): Provide Event after page URI has been generatedhttp://forge.typo3.org/issues/927802020-11-05T20:37:45ZSebastian Michaelsenmichaelsen@t3seo.de
<p>After <code>PageRouter->generateUri()</code> has created a link to a page, an event should be dispatched that allows extensions to react to the created URI or modify it.</p>
<p>Whenever an extension author <em>modifies</em> a generated URL they would need to take care that the URL can be resolved again in the end.</p>
<p>Use Case 1 (URL modification):<br />Via event the generated page URI is modified in a way that url path slugs are rearranged. Once this modified URI is called, a middleware recognizes it and modifies it back, so TYPO3 can resolve it again.</p>
<p>Use Case 2 (URL Logging):<br />Sometimes you have errors reported or in your logs, where you ask yourself: How did anyone end up on <strong>that</strong> URL? Where and why was it generated? So it could be useful to maintain a log with debugging information whenever a <em>new</em> URI is generated.</p> TYPO3 Core - Bug #85965 (Rejected): FileWriter fails to check for valid log file pathhttp://forge.typo3.org/issues/859652018-08-24T16:43:53ZSebastian Michaelsenmichaelsen@t3seo.de
<p><code>\TYPO3\CMS\Core\Log\Writer\FileWriter::setLogFile()</code> uses <code>GeneralUtility::getFileAbsFileName()</code> to get the absolute path to a given <code>$logFile</code>. <code>GeneralUtility::getFileAbsFileName()</code> always returns a string, even in an error case it returns an empty string. However the return value is checked for being <code>null</code>.</p>
<p><a class="external" href="https://github.com/TYPO3/TYPO3.CMS/commit/bfdc332650a92839e8ae73ec21b29f23609b5a1e#r30280568">https://github.com/TYPO3/TYPO3.CMS/commit/bfdc332650a92839e8ae73ec21b29f23609b5a1e#r30280568</a></p>
<p>That means that exception #1444374805 can never be thrown.</p>
<p>This applies to v7, v8 and master.</p> TYPO3 Core - Task #69381 (Rejected): Move the images field of the images CE to the first form tabhttp://forge.typo3.org/issues/693812015-08-28T08:50:19ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Historically the images of the images content element were always configured in the second tab.<br />Back in the times before FAL this might have been a good idea, because there were many fields that would have cluttered the first view on the record.</p>
<p>Now with FAL and the image config details hidden the collapsed inline records it's time to move the images to the first tab. In fact they are the most important property of the record and should be directly visible.</p> TYPO3 Core - Feature #67450 (Rejected): Support custom markers in search formhttp://forge.typo3.org/issues/674502015-06-15T10:08:29ZSebastian Michaelsenmichaelsen@t3seo.de
<p>indexed_search should support the creation of custom markers via typoscript to output custom labels and arbitrary content</p> TYPO3 Core - Bug #67406 (Rejected): Form sysext detected as broken in install toolhttp://forge.typo3.org/issues/674062015-06-10T23:07:14ZSebastian Michaelsenmichaelsen@t3seo.de
<p>With the big change to the TYPO3 autoloading (<a class="external" href="https://github.com/TYPO3/TYPO3.CMS/commit/ec2b4f4266af7bc93e301ad4735464f958a6d1bf">https://github.com/TYPO3/TYPO3.CMS/commit/ec2b4f4266af7bc93e301ad4735464f958a6d1bf</a>) the form system extension is detected as broken by the install tool.</p>
<p><a class="external" href="http://shots.michaelsen.io/HYEa">http://shots.michaelsen.io/HYEa</a></p> TYPO3 Core - Feature #49805 (Rejected): Access extConf in displayCondhttp://forge.typo3.org/issues/498052013-07-09T10:14:18ZSebastian Michaelsenmichaelsen@t3seo.de
<p>The displayCond directive allows to disable/enable a tceform field or flexform field based on various conditions.</p>
<p>Until now it's not possible to use the extConf (settings from ext_conf_template.txt) as condition.</p>
<p>Introduce new displayCond: EXT:EXTCONF:[settingsname]:[operator]:[value]</p>
<p>Allow the same operators like FIELD, which are: <, >, <=, >=, REQ, <del>, !</del>, IN, !IN, =, !=</p> TYPO3 Core - Bug #43874 (Closed): array_merge_recursive_overrule: __UNSET can't unset array valueshttp://forge.typo3.org/issues/438742012-12-11T11:17:09ZSebastian Michaelsenmichaelsen@t3seo.de
<p>If the $enableUnsetFeature parameter is true, array_merge_recursive_overrule you can unset values from the first array.<br />The phpDoc says:<br /><pre>
* @param boolean $enableUnsetFeature If set, special values "__UNSET" can be used in the second array in order to unset array keys in the resulting array.
</pre><br />But in fact keys are only unset if they don't hold an array value. I see no reason why this should be like this. There should be the possibility to unset array values.</p> TYPO3 Core - Task #40870 (Closed): Add Utility Functions to retreive Information from Class Nameshttp://forge.typo3.org/issues/408702012-09-12T16:23:02ZSebastian Michaelsenmichaelsen@t3seo.de
<p>My intention is to introduce these 2 Utility Functions:</p>
<p>\TYPO3\CMS\Core\Extension\ExtensionManager::getClassNameWithoutVendorAndProduct($className)<br />\TYPO3\CMS\Core\Extension\ExtensionManager::getExtensionKeyFromClassName($className)</p>
<p>These can be used in the the Autoloader for example (will be a separate patch, when this one is done).<br />Also Extbase can make use of these functions to resolve #40742.</p> TYPO3 Core - Feature #36669 (Closed): Add Hook to manipulate BE login formhttp://forge.typo3.org/issues/366692012-04-27T16:28:05ZSebastian Michaelsenmichaelsen@t3seo.de
<p>With TYPO3 4.7 the old deprecated way of defining Login News ($TYPO3_CONF_VARS['BE']['loginNews']) was removed and the sys_news database table is the only source for login news now.<br />But you may want to add items from another source (e.g. RSS-Feed).</p>
<p>This is why I want to implement a hook to manipulate the Login News Records.</p> TYPO3 Core - Feature #34922 (Closed): Allow .ts file extension for static typoscript templateshttp://forge.typo3.org/issues/349222012-03-16T12:15:45ZSebastian Michaelsenmichaelsen@t3seo.de
<p>At the moment the following static typoscript filenames are allowed:</p>
<p>setup.txt<br />constants.txt<br />include_static.txt<br />include_static_files.txt</p>
<p>My intention is to also allow ".ts" as file extensions because they're commonly used and IDEs can recognize those file as TypoScript.</p>
<p>I was already playing around with the code and what makes me worry is performance. It's quite expensive to check all the allowed filenames and read them.</p>
<p>I benchmarked different situations (folder with only .txt / only .ts / both / none) and in average it slows down the reading of static templates by about 48%. I don't know if this is acceptable in change for the convenience you get.<br />Maybe there's a possibility for a smart caching solution or other ideas on improving the performance. Ideas are welcome.</p>
<p>I will add my best effort patch here shortly.</p> TYPO3 Core - Bug #24336 (Closed): <img> Tags are rendered with border attribute in HTML5 modehttp://forge.typo3.org/issues/243362010-12-14T12:13:54ZSebastian Michaelsenmichaelsen@t3seo.de
<p>By default <img> Tags are rendered with a border attribute in HTML5. Only with XHTML they are omitted.<br />This is a bug. in HTML5 the border attribute is not allowed.</p>
<p>You can disable the border attribute by using config.disableImgBorderAttr = 1, but it should be disabled by default when using html5 to produce valid code.<br />(issue imported from #M16740)</p> TYPO3 Core - Feature #22279 (Closed): Add .numberFormat function to stdWraphttp://forge.typo3.org/issues/222792010-03-15T11:49:49ZSebastian Michaelsenmichaelsen@t3seo.de
<p>When handling prices or other special formated Numbers in TypoScript there's no reasonable way to format it properly. When there's a price like 0.8 in your Database you can't transform it to 0,80 easily.</p>
<p>There's already an extension adding this functionality by XCLASSing (am_stdwrap_number_format) and requests for such a feature (<a class="external" href="http://www.typo3.net/forum/list/list_post//89143/">http://www.typo3.net/forum/list/list_post//89143/</a> [german]), so I think a general interest for this functionality is given.<br />(issue imported from #M13815)</p> TYPO3 Core - Feature #22107 (Closed): Add a Hook to add Sub Categories to the Constant Editorhttp://forge.typo3.org/issues/221072010-02-11T10:42:37ZSebastian Michaelsenmichaelsen@t3seo.de
<p>Currently the Sub Categories of the Constant Editor are hardcoded (Enable Features, Dimensions, etc).<br />Especially when you develop a flexible TypoScript Library which should be configurable with the Constant Editor it would be great if you could add custom Sub Categories.</p>
<p>I added a constructor to t3lib_tsparser_ext, which can also be used for other hooks or initialization stuff. Currently it only includes my Hook (callUserFunction) to add Sub Categories.<br />(issue imported from #M13510)</p>