TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692017-05-23T12:39:30ZTYPO3 Forge
Redmine TYPO3 Core - Feature #81313 (Closed): Backend LiveSearch visual feedback neededhttp://forge.typo3.org/issues/813132017-05-23T12:39:30ZGeorg Kühnbergergk@plan2.net
<p>Issue: <br />- The LiveSearch currently does not provide any visual feedback while querying the db and before presenting the results.<br />- Given an instance with +10.000 pages and CEs the search takes up to +15 seconds, however the user is not provided any feedback that the search is in progress.</p>
<p>Solution:<br />- Add some visual feedback (spinning wheel or similar) to indicate that search is being in progress.</p> TYPO3 Core - Bug #61226 (Closed): Web-View Module does not respect TCEMAIN.previewDomainhttp://forge.typo3.org/issues/612262014-08-27T16:01:05ZGeorg Kühnbergergk@plan2.net
<p><a class="external" href="https://forge.typo3.org/projects/typo3cms-core/repository/revisions/f2b91c8e50a4fe62045f125431b48a2aa18f59cd">https://forge.typo3.org/projects/typo3cms-core/repository/revisions/f2b91c8e50a4fe62045f125431b48a2aa18f59cd</a><br />Introduced the feature to set an alternative domain for preview with TCEMAIN.previewDomain = example.com in PageTS.</p>
<p>However previewDomain is NOT respected in the Module Web>View, <br />resulting in: Web>View behaves different than Page>View.</p> TYPO3 Core - Bug #25167 (Closed): Upgrade 4.5.0 > 4.5.1 - Backend Error - PHP Fatal error: Class...http://forge.typo3.org/issues/251672011-02-24T17:06:46ZGeorg Kühnbergergk@plan2.net
<p>On upgrading a symlinked instance from 4.5.0 to 4.5.1,<br />the backend login failed in that after logging in with correct credentials,<br />the backend returned a blank page<br />and apache threw the below error:</p>
> /var/log/apache2/mydomain.error.log <<br />[Thu Feb 24 15:35:54 2011] [error] [client ] PHP Fatal error: Class 't3lib_extjs_ExtDirectApi' not found in /var/lib/typo3/typo3_src-4.5.1/t3lib/class.t3lib_div.php on line 5277, referer: <a class="external" href="http://mydomain/typo3/index.php">http://mydomain/typo3/index.php</a>
<p>Server Info:<br />PHP Version 5.2.6-1+lenny9<br />Web Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with Suhosin-Patch mod_ruby/1.2.6 Ruby/1.8.7(2008-08-11) mod_ssl/2.2.9 OpenSSL/0.9.8g Phusion_Passenger/2.2.11 mod_perl/2.0.4 Perl/v5.10.0</p>
<p>Using Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies<br /> with XCache v1.2.2, Copyright (c) 2005-2007, by mOo</p>
<p>The issue is related to <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: upgrading to 4.5.1 breaks backend for some installs (Closed)" href="http://forge.typo3.org/issues/25151">#25151</a></p>
<p>The problem was not any Browser / Client-Side Cache (issue observed and tested with multiple Browsers from different machines and IPs).</p>
<p>The solution was to restart Apache,<br />which apparently cleared the opcode-cache (XCACHE in our case).</p>
<p>I recommend to add a notion about restarting the webserver in case an op-code-caches is used.</p>
<p>(issue imported from #M17753)</p> TYPO3 Core - Bug #24334 (Closed): sendCacheHeaders: Wrong usage of Pragma: public and no-cachehttp://forge.typo3.org/issues/243342010-12-13T19:59:42ZGeorg Kühnbergergk@plan2.net
<p>Problem:<br />Given chache-headers are turned on via config.sendCacheHeaders = 1<br />class.tslib_fe.php outputs "Pragma: public" which is plain wrong.<br />Additionally class.tslib_fe.php outputs "Pragma: no-cache" which is depricated since HTTP/1.1.</p>
<p>- "Pragma: public" as http-header-response, never existed in HTTP/1.0 and neighter in HTTP/1.1, as public is implicit, thus should be removed.</p>
<p>- "Pragma: no-cache" is deprecated in HTTP/1.1 and should also be removed, since "Cache-Control: no-cache ..." is returned anyway and correct.</p>
<p>Solution:<br />- remove "Pragma: public" <br />- remove "Pragma: no-cache"</p>
<p>Patchfile is attached</p>
<p>INFO:<br />RFC Hypertext Transfer Protocol -- HTTP/1.0<br /><a class="external" href="http://www.ietf.org/rfc/rfc1945.txt">http://www.ietf.org/rfc/rfc1945.txt</a></p>
<p>Hypertext Transfer Protocol -- HTTP/1.1<br /><a class="external" href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a></p>
<p>(issue imported from #M16737)</p> TYPO3 Core - Bug #23840 (Closed): config example for memcached in t3lib/config_default.php breaks...http://forge.typo3.org/issues/238402010-10-25T19:55:19ZGeorg Kühnbergergk@plan2.net
<p>Used Core-Version: <br />TYPO3 4.4.4 (and 4.3)</p>
<p>Issue:<br />t3lib/config_default.php provides a memcached config example which will break the TYPO3 BE+FE in the following two aspects:</p>
<p>a) the needed but missing frontend config-aspekt leads to a broken BE + FE with the following Error:</p>
<p>Uncaught TYPO3 Exception Class does not exist ReflectionException thrown in file t3lib/class.t3lib_div.php in line 5250.</p>
<p>b) configuring memcached ONLY for cache_pages (and not also for cache_hash and cache_pagesection will break the TYPO3 BE+FE <br />with the following Error:</p>
<p>#1: PHP Catchable Fatal Error: Argument 4 passed to t3lib_cache_Factory::create() must be an array, null given, called in /t3lib/class.t3lib_cache.php on line 67 and defined in /t3lib/cache/class.t3lib_cache_factory.php line 72 t3lib_error_Exception thrown in file /t3lib/error/class.t3lib_error_errorhandler.php in line 106.</p>
<p>Solution: Update the comment in line 149-160 to the below (or move it into any meaningnful documentation and add a link thereupon).</p>
<p>/*<br /> For memcached, use:
=============<br />$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations'] = array (<br /> 'cache_hash' => array(<br /> 'frontend' => 't3lib_cache_frontend_VariableFrontend',<br /> 'backend' => 't3lib_cache_backend_MemcachedBackend',<br /> 'options' => array(<br /> 'servers' => array('localhost:11211'),<br /> )<br /> ),<br /> 'cache_pages' => array(<br /> 'frontend' => 't3lib_cache_frontend_VariableFrontend',<br /> 'backend' => 't3lib_cache_backend_MemcachedBackend',<br /> 'options' => array(<br /> 'servers' => array('localhost:11211'),<br /> )<br /> ),<br /> 'cache_pagesection' => array(<br /> 'frontend' => 't3lib_cache_frontend_VariableFrontend',<br /> 'backend' => 't3lib_cache_backend_MemcachedBackend',<br /> 'options' => array(<br /> 'servers' => array('localhost:11211'),<br /> )<br /> ),<br />);
=============<br />You need to have memcached installed as a daemon and also as a PHP extension!<br />*/</p>
<p>(issue imported from #M16128)</p> TYPO3 Core - Bug #20845 (Closed): disableNoCacheParameter breaks FE Cachehttp://forge.typo3.org/issues/208452009-08-07T02:13:06ZGeorg Kühnbergergk@plan2.net
<p>disableNoCacheParameter breaks FE Cache</p>
<p>to be more precice: disableNoCacheParameter = 1 <br />leads to page cache-entries including editpanel and pencils for FE-Editing.</p>
<p>Result: normal anonymous or FE-Users see editpanel and pencils in the Frontend.as the where cached that way.</p>
<p>Howto reproduce:<br />- clear FE_cache<br />- set [FE][disableNoCacheParameter] = 1<br />- enable editpanels / adminpanel<br />- Login as Backenduser call up the frontend to see the editpanel/pencils<br />- Now this page is being cached (incl. pencils)<br />- Checkout the FE or the above page with another browser and your will see the editpanel/pencils.</p>
<p>Reasons seems to be around the following functions:<br />- class tslib_fe - function set_no_cache()<br />- and /or t3lib/class.t3lib_tsfebeuserauth.php on line 835.</p>
<p>(issue imported from #M11663)</p> TYPO3 Core - Bug #20609 (Closed): broken sorting of filemountshttp://forge.typo3.org/issues/206092009-06-12T02:49:52ZGeorg Kühnbergergk@plan2.net
<p>Description:<br />- Given a Backend-User/Group has more than one filemount, those filemounts are displayed in broken/confusing order in the backend to the backend-user.<br />- The TYPO3-Admin has no meaningfull chance to change the order of those filesmounts.<br />- I percieve this as a bug, as the only workaround for defining a sort-order or filemounts would be fumbling with uid of the sys_filemounts in the DB. This is not feasable, and especially should not be reommended.</p>
<p>Info:<br />class.t3lib_userauthgroup.php grabs the users accumulated filemounts, however with no sorting at all; <br />that is, the filemounts are provided ordered by their UID, which however is neigther transparent nor changeable.<br />Given that the sys_filemounts are only in the root-page, no manual sorting is possible, eigther. (pitty);</p>
<p>Solution:<br />- Sort the filemounts alphabetically, by their title;<br />- This approach matches the expected behaviour of Admins and Users, as its well known from filesystems/directories.<br />- This allows for easily re-orderung via the backend, by simply renaming the given file-mounts.</p>
<p>Patch: <br />- Added an "orderBy" statement to two selects in t3lib/class.t3lib_userauthgroup.php</p>
<p>This patch should also go into versions <= 4.3<br />(issue imported from #M11318)</p> TYPO3 Core - Bug #20413 (Closed): wrong content-length header breaks frontend in case of proxy-usagehttp://forge.typo3.org/issues/204132009-05-10T00:51:49ZGeorg Kühnbergergk@plan2.net
<p>class.tslib_fe.php, function processOutput() calculates the content-length wrongly in case of enabled debug.</p>
<p>In case of config.debug = 1 or $TYPO3_CONF_VARS['FE']['debug'] = '1'; the calculated content-length will differ from the really sent content-length; <br />basically the calculation misses the "Cached page generated ...Expires ... text below the closing html tag.</p>
<p>Now in case of using a forwarding or reverse Proxy like Squid (2.7), the proxy will choke upon the difference of content-length information from the header and the really delivered content-length with an Error like this: httpReadReply: Excess data from "GET <a class="external" href="http://domain.com/123.html">http://domain.com/123.html</a>"</p>
<p>Even worse the Proxy will NOT deliver the complete page but will cut it off somewhere in the middle (observed with pages larger than 30.000 bytes).</p>
<p>Thus I percieve this as a severe bug, as turning on the "debug" feature should not break the frontend.</p>
<p>Solution: In case debug is activated, TYPO3 should not send content-length at all; proxies will behave nice then and deliver the complete page.</p>
<p>Patch: Simply added two more conditions to class.tslib_fe.php, function processOutput()</p>
<p>Note: You should not trust the Firefox Page-Size-Information (Extras > Information > Page-Size); FF seems to ignore everything behind the closing html tag, and thus report a wrong document-size.</p>
<p>(issue imported from #M11063)</p> TYPO3 Core - Bug #16721 (Closed): Update Wizard wont overwrite compat_version mode, in case two l...http://forge.typo3.org/issues/167212006-11-17T15:10:14ZGeorg Kühnbergergk@plan2.net
<p>in localconf.php I had (for whatever reason) 2 entries in the following order:<br />localconf.php <br />-----------------<br />$TYPO3_CONF_VARS['SYS']['compat_version'] = '4.0';<br />$TYPO3_CONF_VARS['SYS']['compat_version'] = '3.8';</p>
<p>Now running through the Installtool like:<br /> InstallTool >>> 3: Update Wizard >>> 4.0 >>> accept all<br /> confirmed that the needed changes would have been made;</p>
<p>however localconf.php still showed - in order:<br />-----------------<br />$TYPO3_CONF_VARS['SYS']['compat_version'] = '4.0';<br />$TYPO3_CONF_VARS['SYS']['compat_version'] = '3.8';</p>
<p>thus the instance was running 3.8;</p>
<p>PS: guess the second line was added manually at some point of time;<br />PPS: fix was manually deleting the 3.8 line;</p>
<p>(issue imported from #M4524)</p> TYPO3 Core - Bug #15665 (Closed): EXT-Mgr: Update from TER fails with no meaningful ERROR, withou...http://forge.typo3.org/issues/156652006-02-18T01:22:04ZGeorg Kühnbergergk@plan2.net
<p>EXT-Mgr > Connect to the current mirror and retrieve the current list<br />results in</p>
<p>Warning: file_get_contents(): php_network_getaddresses: gethostbyname failed in D:\apache\htdocs\t3\t340b3\t3lib\class.t3lib_div.php on line 2120<br />Warning: file_get_contents(<a class="external" href="http://extensions.xml.gz">http://extensions.xml.gz</a>): failed to open stream: No error in D:\apache\htdocs\t3\t340b3\t3lib\class.t3lib_div.php on line 2120<br />Error: The extension list could not be fetched from <a class="external" href="http://extensions.xml.gz">http://extensions.xml.gz</a></p>
<p>setting username, password and especially selecting a mirror, resolves this;<br />so <br />eighter the user should be directed towards setting a respoitory first, or the default repository should come preconfigured ( imho better )</p>
<p>(issue imported from #M2617)</p> TYPO3 Core - Bug #15664 (Closed): EXT version not installed but required by Workspaceshttp://forge.typo3.org/issues/156642006-02-18T01:09:51ZGeorg Kühnbergergk@plan2.net
<p>Extension "version" ist not installed in package BETA3, but required for Workspaces;<br />After having made a tt_content change in the default Workspace Version (-1), <br />the preview of that page <br /><a class="external" href="http://localhost/t3/t340b3/typo3/sysext/version/cm1/index.php?id=1&diffOnly=1">http://localhost/t3/t340b3/typo3/sysext/version/cm1/index.php?id=1&diffOnly=1</a><br />causes the following error:<br />TYPO3 Fatal Error: Extension key "version" was NOT loaded! (t3lib_extMgm::extRelPath)<br />so me feels the EXT version should come preinstalled;</p>
<p>(issue imported from #M2616)</p>