TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692017-06-20T11:22:53ZTYPO3 Forge
Redmine TYPO3 Core - Bug #81629 (Closed): Using persistent connections with Redis cache backend can fail ...http://forge.typo3.org/issues/816292017-06-20T11:22:53ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>There is a rare corner-case with using the Redis Cache Backend with persistent connections. It was discovered and described in the original Gerrit patch-set <a class="external" href="https://review.typo3.org/#/c/50978/">https://review.typo3.org/#/c/50978/</a> (comment included below).</p>
<p>The way to fix this is to ensure that if no database number is given, then we should explicitly set it to zero.</p>
<blockquote>
<p>@markus: My DevOps guy has a theory that if you use database 0 and other databases, then if not explicitly setting the database it might default to db 0. <br />A test case you could try is the following:<br />1) Create these two files in a webroot:<br />File A: test.php<br /><?php<br />$redis = new Redis();<br />$redis->pconnect('redis.eu-west-1.systime.dk', 6379);<br />print($redis->dbSize());<br />?><br />File B: test2.php:<br /><?php<br />$redis = new Redis();<br />$redis->pconnect('redis.eu-west-1.systime.dk', 6379);<br />$redis->select(2);<br />print($redis->dbSize());<br />?><br />2) Make sure the number of entries in the two databases a not the same<br />3) Try calling the scripts. The assumption should be that script test.php always gives the number of entries in db 0; and test2.php should always give the number of entries in db 2.<br />As far as we can see, it seems that test.php sometimes gives the number of entries from db 2. If you can confirm that, then the fix would be that we always select the correct database.<br />At Systime Redis database 0 isn't used, so we always select the database, which would explain why we didn't see this problem.<br />For now the above is only circumstantial evidence, but for now it's the best guess we have come up with to explain the symptoms your describe.</p>
</blockquote> TYPO3 Core - Bug #79005 (Closed): Missing support for persistent connection in Redis cache backen...http://forge.typo3.org/issues/790052016-12-15T14:58:39ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>phpredis has support for persistent connections, but currently the Redis cache backend has hard-coded the regular connect call. We should allow an opt-in cache configuration for persistent connections.</p> TYPO3 Core - Bug #79001 (Closed): PHP 7.1: AbstractMenuContentObject declares uidRegister as stri...http://forge.typo3.org/issues/790012016-12-15T13:35:34ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>PHP 7.1 throws an exception on menu generation as $rL_uidRegister is declared to be string but used as array.</p> TYPO3 Core - Bug #77539 (Closed): Javascript warning in Firefox 48 console: "unreachable code aft...http://forge.typo3.org/issues/775392016-08-18T14:04:50ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>On <a href="https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/backend/Resources/Public/JavaScript/jsfunc.evalfield.js#L263" class="external">line 263 in TYPO3.CMS/typo3/sysext/backend/Resources/Public/JavaScript/jsfunc.evalfield.js</a> there is unreacheable code:<br /><pre>
261 if (value=="") {
262 return "";
263 return 0; // Why would I ever return a zero??? (20/12/01)
264 }
</pre></p>
<p>Solution: Remove line 263.</p>
<p>PS: According to the comment on line 263, it would seem the unreachable code has there for years.</p> TYPO3 Core - Bug #77323 (Closed): Enlarge 'field' in table 'sys_refindex' from 40 to 64http://forge.typo3.org/issues/773232016-08-01T12:14:53ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>In the standard table definitions in <a href="https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/ext_tables.sql#L571" class="external">typo3/sysext/core/ext_tables.sql</a>, the schema definition for table <em>sys_refindex</em> has the size of the field called <em>field</em> set to <em>varchar(40)</em>, but MySQL allows 64 characters (at least since v. 5.5).</p>
<p>We have field-names in our tables, which are longer than 40 characters, and thus have met this problem. It might be that the field was simply truncated previously, but now that we switch to MySQL in strict mode, we get a warning.</p>
<p>We also think that 40 is rather short; 64 would be more appropriate.</p>
<p>The change we propose is to enlarge the <strong>field</strong> varchar from 40 to 64 in ext_tables.sql:<br /><pre>
CREATE TABLE sys_refindex (
...
field varchar(64) DEFAULT '' NOT NULL,
...
);
</pre></p> TYPO3 Core - Bug #50493 (Closed): "Invalid Memcache->connection member variable" in unit testshttp://forge.typo3.org/issues/504932013-07-27T20:45:24ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>Since <em>[FEATURE] Add PHPUnit error handler as default</em> (<a class="external" href="https://review.typo3.org/22456">https://review.typo3.org/22456</a>) was merged I have seen a lot of Core tests fail as errors with the text:<br /><pre>
Memcache::get() [<a href='memcache.get'>memcache.get</a>]: Invalid Memcache-&gt;connection member variable
</pre></p>
<p>I do not think it is the PHPUnit feature which broke something. Rather it seems the feature surfaced some problem with the MemcachedBackend.</p>
<p>The error is located in the file TYPO3.CMS/typo3/sysext/core/Classes/Cache/Backend/MemcachedBackend.php in the two methods get() (line 239) and findIdentifiersByTag() (line 284).</p>
<p>I am not familiar with the Cache Framework and Memcached, so have no clue what might be wrong.</p> TYPO3 Core - Task #50318 (Closed): Make DiffUtility faster and much more scaleable.http://forge.typo3.org/issues/503182013-07-23T09:17:18ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>The method DiffUtility->explodeStringIntoWords() can be made faster and able to handle much larger inputs.</p>
<p><strong>The problem</strong>: When the content element you wish to see the history for is many lines long, then <em>History</em>-view becomes slower.</p>
<p>As an extreme example, I have a 7000 lines long content element. It has been edited several times, so in total there at some 300KB in the <em>history_data</em> field for the element in the <em>sys_history</em> table. With the current code it takes 92 seconds to display in the <em>History</em> view. This can be vastly improved.</p>
<p><strong>The solution</strong>: Profiling the code showed that the time was spent doing thousands of array_merge(). The fix is to collect all the arrays in an array, and then call array_merge(). It cut the time of my example above down to less than 2 seconds.</p>
<p>DiffUtility is used by the <em>History</em>-view of content elements, <em>Workspaces</em>, <em>Version</em> and <em>Import/Export</em>. Basically anything that needs a visual diff.</p>
<p>Patch forthcoming via Gerrit for <em>master</em>-branch.</p> TYPO3 Core - Bug #41165 (Closed): Parameter $alternativeUrl not obeyed in t3lib_BEfunc::viewOnClickhttp://forge.typo3.org/issues/411652012-09-21T14:24:15ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>In the method viewOnClick the parameter $alternativeUrl is documented like this: "$alternativeUrl is an alternative URL which - if set - will make all other parameters ignored: The function will just return the window.open command wrapped around this URL! The hook will allow modification, though."</p>
<p>But that is not obeyed anymore. The semantics of the method was inadvertently changed when a hook was added, see bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: t3lib_BEfunc::viewOnClick - Hook request (Closed)" href="http://forge.typo3.org/issues/22157">#22157</a>. Rectifying the semantics while keeping the hook is luckily no problem.</p>
<p>The change needs to be done in TYPO3 4.4, 4.5, 4.6, 4.7 and 6.0.</p>
<p>PS: I first targeted this for 4.5, but since the change should also be in 6.0 I create this issue, since I couldn't find any way to modify the first issue, <a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: Parameter $alternativeUrl not obeyed in t3lib_BEfunc::viewOnClick (Closed)" href="http://forge.typo3.org/issues/41130">#41130</a>.</p> TYPO3 Core - Bug #41130 (Closed): Parameter $alternativeUrl not obeyed in t3lib_BEfunc::viewOnClickhttp://forge.typo3.org/issues/411302012-09-20T19:02:36ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>In the method viewOnClick the parameter $alternativeUrl is documented like this: "$alternativeUrl is an alternative URL which - if set - will make all other parameters ignored: The function will just return the window.open command wrapped around this URL! The hook will allow modification, though."</p>
<p>But that is not obeyed anymore. The semantics of the method was inadvertently changed when a hook was added, see bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: t3lib_BEfunc::viewOnClick - Hook request (Closed)" href="http://forge.typo3.org/issues/22157">#22157</a>. Rectifying the semantics while keeping the hook is luckily no problem.</p>
<p>The change needs to be done in TYPO3 4.4, 4.5, 4.6, 4.7 and 6.0.</p>
<p>NB: This is my first attempt at submitting to core after the change last year, so bear with me and guide me, if I do something the wrong way. I will start with (trying) to upload a patch for review in Gerrit in review.typo3.org.</p> TYPO3 Core - Bug #21849 (Closed): When configuring to remove Edit menu from clickmenu, it also re...http://forge.typo3.org/issues/218492009-12-12T19:27:56ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>According to the TS Config manual you can configure the User TSConfig entry contextMenu.[key].disableItems with either (or both) af edit and edit_pageheader.</p>
<p>If adding 'edit' then 'edit_pageheader' is also removed because the code (wrongly) test whether the variable editPageIconSet is set. Removing the check, which is done in the attached patch file, solves the problem and makes things work as documented in the TS Config manual.</p>
<p>There is a closely related problem: The entry is not called 'edit_pagehader' anymore (and has not been called that since 2005!!!). It is now called 'edit_pageproperties'. This needs to be corrected in the manual, i.e. replacing 'edit_pageheader' with 'edit_pageproperties' in the description of the configuration entry for contextMenu.[key].disableItems.</p>
<p>TS Config manual: <a class="external" href="http://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.2.0/view/1/2/#id4138422">http://typo3.org/documentation/document-library/core-documentation/doc_core_tsconfig/4.2.0/view/1/2/#id4138422</a><br />(issue imported from #M13022)</p> TYPO3 Core - Bug #18517 (Closed): Add icon to selected entry (currently icons are only shown in d...http://forge.typo3.org/issues/185172008-03-30T11:41:01ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>The dropdown boxes currently show icons in the dropdown menu, but not in the closed dropdown. This can be seen in e.g. the 'Type' field in a Page Element.</p>
<p>The attached patch add this.</p>
<p>As all this patch does is attach a style attribute to the select tag, the risk is very low.</p>
<p>Note that the patch uses it's own styling, since using the styling from function optionTagStyle() makes the dropdown box look bad.</p>
<p>Note: Opera does not show icons at all in the dropdown - with or without this patch.<br />(issue imported from #M7962)</p> TYPO3 Core - Bug #18483 (Closed): PHP5ize class.t3lib_iconworks.phphttp://forge.typo3.org/issues/184832008-03-19T20:04:10ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>Same reasons as given in issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: PHP5ize class.t3lib_extMgm.php (Closed)" href="http://forge.typo3.org/issues/18480">#18480</a> and <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: PHP5ize class.t3lib_extMgm.php (Closed)" href="http://forge.typo3.org/issues/18480">#18480</a>, that the documentation says the class is to never be instantiated, thus let us use the PHP5 capabilities to enforce this.</p>
<p>The patch does the following:<br />1) Sets class to 'final'.<br />2) Sets all functions to 'public static'<br />3) Replaces tabs between function signature and body with a space.<br />4) Inserts spaces around = where appropriate according to CGL.<br />5) Inserts a space after commas where appropriate according to CGL.</p>
<p>(issue imported from #M7909)</p> TYPO3 Core - Bug #18482 (Closed): PHP5ize class.t3lib_extBEfunc.phphttp://forge.typo3.org/issues/184822008-03-19T14:04:16ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>Same reasons as given in issue <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: PHP5ize class.t3lib_extMgm.php (Closed)" href="http://forge.typo3.org/issues/18480">#18480</a>, that the documentation says the class is to never be instantiated, thus let us use the PHP5 capabilities to enforce this.</p>
<p>The patch does the following:<br />1) Sets class to 'final'.<br />2) Sets all functions to 'public static'<br />3) Replaces tabs between function signature and body with a space.</p>
<p>pending in core list<br />(issue imported from #M7906)</p> TYPO3 Core - Bug #18480 (Closed): PHP5ize class.t3lib_extMgm.phphttp://forge.typo3.org/issues/184802008-03-19T11:26:18ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>t3lib_extMgm states in it's documentation: "This class is never instantiated, rather the methods inside is called as functions like t3lib_extMgm::isLoaded('my_extension');"</p>
<p>Thus I propose to PHP5ize all methods by marking them 'public static'. This will remove E_STRICT warnings such as this one:</p>
<p>Strict: Non-static method t3lib_extMgm::extPath() should not be called statically, assuming $this from incompatible context</p>
<p>I have tested on my own machine, and things seem to run fine. Furthermore I did a grep for 'new t3lib_extMgm' through Typo3, to see if anyone is instaitiating the class; the search gave no results. Googling for "new t3lib_extMgm" did not find exact matches for that string: Thus it seems to be safe make this change.</p>
<p>Only possible danger might be if some extension instantiates t3lib_extMgm. I find this unlikely, since the documentation states you should not, and I have never seen any examples that instantiates t3lib_extMgm.</p>
<p>Doing the change will ensure us that people calling the class correctly will not be shown an E_STRICT warning, but that people calling the class incorrectly will be told right away.</p>
<p>Note: Typo3 does not currently run with E_STRICT.<br />(issue imported from #M7903)</p> TYPO3 Core - Bug #18077 (Closed): CSH not working in flexforms after merge of patch from #17932http://forge.typo3.org/issues/180772008-01-29T18:43:35ZKasper Ligaardkasperligaard+typo3.org@gmail.com
<p>The patch in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Context Senstitive Help as Tooltip (Closed)" href="http://forge.typo3.org/issues/17932">#17932</a> does not work with the new flexforms CSH (see bug 0007028), but that is easily fixed by the attached patch</p>
<p>This bug supercedes my comments in <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Context Senstitive Help as Tooltip (Closed)" href="http://forge.typo3.org/issues/17932">#17932</a>.<br />(issue imported from #M7317)</p>