Bug #24752
closedError Message while Updating 4.4.6 > 4.5
Added by Heinz Scheungrab over 13 years ago. Updated over 13 years ago.
0%
Description
In the Update Wizard, in Step2 "Install Outsourced System Extensions":
Class tx_em_Connection_ExtDirectServer does not exist
see http://forge.typo3.org/issues/13131 for the EM part
(issue imported from #M17244)
Files
0017244.patch (7.49 KB) 0017244.patch | Administrator Admin, 2011-01-28 13:31 | ||
0017244_core.patch (5.6 KB) 0017244_core.patch | Administrator Admin, 2011-02-17 12:36 |
Updated by Steffen Gebert over 13 years ago
Umm.. weird problem. I wonder why the autoloader is not active for you..
Updated by Ernesto Baschny over 13 years ago
Indeed a strange issue, as the EM extension provides this class and the auto-loader should make it available.
Any further information on your particular setup? Maybe a list of extensions you had installed, operating system, Webserver ...
Updated by Heinz Scheungrab over 13 years ago
Operating System: Linux, Webserver: Apache/2.2.16
$TYPO3_CONF_VARS['EXT']['extList'] = 'tsconfig_help,context_help,extra_page_cm_options,impexp,sys_note,tstemplate,tstemplate_ceditor,tstemplate_info, tstemplate_objbrowser,tstemplate_analyzer, func_wizards,wizard_crpages,wizard_sortpages,lowlevel,install,belog,beuser,aboutmodules,setup,taskcenter, info_pagetsconfig,viewpage,rtehtmlarea, css_styled_content,t3skin';
Updated by Rainer over 13 years ago
Same here!
Upgraded from 4.4.5 to 4.5 LTO.
Apache 2.2.9
$TYPO3_CONF_VARS['EXT']['extList'] = 'cms,lang,sv,css_styled_content,tsconfig_help,context_help,extra_page_cm_options,sys_note,tstemplate, tstemplate_ceditor,tstemplate_info,tstemplate_objbrowser,tstemplate_analyzer,func_wizards,wizard_crpages, wizard_sortpages,lowlevel,install,belog,beuser,aboutmodules,setup,taskcenter,info_pagetsconfig,sys_action, viewpage,indexed_search,mininews,user_set_page_title,impexp,de_phpot,t3skin,about,cshmanual,feedit, opendocs,simulatestatic,recycler,t3editor,reports,scheduler,statictemplates'; //
Updated by Hauke Haller over 13 years ago
the same happens here. Maybe the weak server might cause the problem. (It s an old installation at 1und1)
PHP Memory Limit 40M
PHP_VERSION : 5.2.17
Updated by Steffen Gebert over 13 years ago
Which PHP version are you running?
EDIT: Okay, Hans entered PHP >= 5.2. Really true?
Updated by Rainer over 13 years ago
PHP 5.2.17-0.dotdeb.0 with Suhosin-Patch 0.9.7 (cli) (built: Jan 7 2011 07:47:48)
Updated by Rainer over 13 years ago
I set the memory limit to 228 MB in /etc/php5/apache2/php.ini, still the same problem
Updated by Steffen Gebert over 13 years ago
Why does your web server run a CLI ;-)
Dunno atm..
Updated by Rainer over 13 years ago
I just find it really easy to type "php -v" and then copy and paste.
I am pretty sure the part of php that's working for Apache has the same version.
Anyways, how should we treat a half-upgraded website in the meantime, until this problem is fixed? I did the other updates (database) and am not seeing any obvious things that would not work, but can I be sure it's okay to leave it like this? Or should I rather restore a backup and go back to the old version?
Updated by Steffen Gebert over 13 years ago
You should test, before you upgrade ;)
If you're sure that you're running PHP 5.2+, then fine.
Please download and extract the src-package again or make sure that tx_em_Connection_ExtDirectServer really exists in typo3/sysext/em/classes/connection/class.tx_em_connection_extdirectserver.php
Updated by Rainer over 13 years ago
of course it exists.
This seems to be a bug... you should test before you make something GA :-)
Updated by Steffen Gebert over 13 years ago
I don't know, why it occurs. I see no reason and no point to debug. It obviously never occured for anybody else before.
You could have a look at t3lib_autoload - if that one is used and if it automatically includes the file and thus makes the class available.
Updated by Heinz Scheungrab over 13 years ago
I tried to download and extract the source again. Still the same problem.
The extension manager is not loaded/visible in the admin tools.
In other installations there is no problem (Same Server, PHP-Version...)
Updated by Rainer over 13 years ago
Well, whenever a new bug occurs, you will have the situation that it has never occurred for anyone else before.
Are you saying that you only accept bugs as real bugs if they have occurred before they occur for the first time? In other words, you are never interested in any bugs?
We have a bug here that occurs for two people, in two independent, different Typo3 installations.
My Typo3 installation worked just fine until your new version 4.5 LTA came around, and now it's broken. I would appreciate it if you typo3 developers would not tell me you see no point in debugging your software.
Now, let's be constructive and solve the problem at hand - how do I check whether t3lib_autoload is used? It definitely is present:
grep -R t3lib_autoload .
./t3lib/config_default.php:require_once(PATH_t3lib . 'class.t3lib_autoloader.php');
./t3lib/config_default.php:t3lib_autoloader::registerAutoloader();
./t3lib/core_autoload.php: 't3lib_autoloader' => PATH_t3lib . 'class.t3lib_autoloader.php',
./t3lib/class.t3lib_autoloader.php: * $Id: class.t3lib_autoloader.php 10121 2011-01-18 20:15:30Z ohader $
./t3lib/class.t3lib_autoloader.php:class t3lib_autoloader {
./t3lib/class.t3lib_autoloader.php: return spl_autoload_register('t3lib_autoloader::autoload');
./t3lib/class.t3lib_autoloader.php: return spl_autoload_unregister('t3lib_autoloader::autoload');
./typo3_src/t3lib/config_default.php:require_once(PATH_t3lib . 'class.t3lib_autoloader.php');
./typo3_src/t3lib/config_default.php:t3lib_autoloader::registerAutoloader();
./typo3_src/t3lib/core_autoload.php: 't3lib_autoloader' => PATH_t3lib . 'class.t3lib_autoloader.php',
./typo3_src/t3lib/class.t3lib_autoloader.php: * $Id: class.t3lib_autoloader.php 10121 2011-01-18 20:15:30Z ohader $
./typo3_src/t3lib/class.t3lib_autoloader.php:class t3lib_autoloader {
./typo3_src/t3lib/class.t3lib_autoloader.php: return spl_autoload_register('t3lib_autoloader::autoload');
./typo3_src/t3lib/class.t3lib_autoloader.php: return spl_autoload_unregister('t3lib_autoloader::autoload');
Updated by Oliver Hader over 13 years ago
Dear Rainer,
thanks for your feedback on this issue. The TYPO3 community worked hard during the last few months and especially in the last few days to get as much bugs solved. However it still happens that there are bugs that we want to take and analyze seriously. This also means that we need a way to reproduce the faulty behaviour.
Feel free to contact me directly via mail at oliver (at) typo3 (dot) org - maybe it's possible to get access to the affected system to do a proper analysis there? Thanks in advance!
Best regards,
Oliver
Updated by Ernesto Baschny over 13 years ago
Maybe there is a conflicting autoloader in one of your used extensions? Could you grep for "autoload" in your typo3conf/ext/ path, please?
Updated by Oliver Hader over 13 years ago
Heinz contacted me via mail and offered access to his server environment. I'm going to analyse further...
Updated by Oliver Hader over 13 years ago
I was able to reproduce the behaviour on Heinz' server.
The reason was, that the new system extension "em" was not installed and therefore the ext_autoload.php file was not loaded. I'm going to analyze further how this could happen when upgrading from older TYPO3 versions.
Updated by Rainer over 13 years ago
Sorry about my late response, I was somewhat busy otherwise.
Here's the response to Ernesto's question:
grep -R autoload typo3conf/ext
delivers nothing whatsoever. I guess that's a good thing?
Glad to hear that Heinz is giving you access.
Of course, I appreciate your efforts! Thanks for making Typo3 better and better!
Updated by Ernesto Baschny over 13 years ago
maybe you have this setting in your localconf.php file, which doesn't include the "em"?
$TYPO3_CONF_VARS['EXT']['requiredExt']
This setting is not intended to be added manually to localconf.php. Doing this caused that Exception to me too (because then the "em" extension was not loaded).
If you have this setting in your localconf.php, maybe you can try to figure out (or remember) when and how this was added?
Updated by Rainer over 13 years ago
Indeed, there is:
$TYPO3_CONF_VARS["EXT"]["requiredExt"] = 'cms,lang';
so, do I just need to add "em" here?
I have no clue how this line got into the file. This installation is many years old...
Updated by Oliver Hader over 13 years ago
Yes, this line was given there:
$TYPO3_CONF_VARS['EXT']['requiredExt'] = 'cms,version,lang,sv'; // Modified or inserted by TYPO3 Install Tool.
Thus, we should add a check and ensure that the extension manager is available in the install tool for upgrading...
Updated by Ernesto Baschny over 13 years ago
Yes, and maybe add a "warning" if $TYPO3_CONF_VARS['EXT']['requiredExt'] is set in localconf.php, because it is not intended to be manipulated in an user setup (because we might change the list at any time, like we did here). Its not configurable through Install Tool (maybe it was in ancient times)?
Thanks for spotting that issue!
Updated by Ernesto Baschny over 13 years ago
Solution is to remove the line from your localconf.php and clean the typo3conf/temp* files afterwards.
Updated by Oliver Hader over 13 years ago
- define a list of required extensions as new constant (required for TYPO3)
- enable the requiredExt setting in the install tool to define additional required extensions (your extensions)
- add the ignoredExt setting in the install tool to define extensions that shall not be loaded (e.g. the "em" can be disabled this way)
In the install tool, the ignoredExt setting is not considered and thus at least the required extensions for TYPO3 are available.
Updated by Oliver Hader over 13 years ago
- TYPO3_4-5 (rev. 10479)
- Trunk (rev. 10480)