Bug #30827
closedt3lib_utility_VersionNumber is not found after trying to upgrade
0%
Description
This may be related to #28098
I have an existing 4.5.x installation of TYPO3. When I'm trying to switch the Core to someting with 4.6 (either git master or a downloaded beta) the error occurs that t3lib_utility_VersionNumben is not found - and that is all you can see in the frontend, backend and also Install Tool it the ENABLE_INSTALL_TOOL file is present.
I tried it on at least three machines and all are broken.
When I manually change the return value in t3lib_div::int_from_ver() to 40060000 and override the call to t3lib_utility_VersionNumber everything works fine.
I deleted all cache files and also emtied all cache database tables.
Updated by Markus Klein over 13 years ago
Hi, can you please check whether this file exists
t3lib/utility/class.t3lib_utility_versionnumber.php
And can you please provide the full error message.
Thx.
Updated by Ingo Pfennigstorf over 13 years ago
The file exists. It is also present in core_autoload.php. I do not have the complete error message here this moment - but it unfortunatly doesn't say anything more than that it is not found when it's called from t3lib_div. If it helps I can provide the exact message tomorrow.
Updated by Ingo Pfennigstorf over 13 years ago
Fatal error: Class 't3lib_utility_VersionNumber' not found in /Users/ingop/repo/Core/t3lib/class.t3lib_div.php on line 887
Updated by Steffen Gebert over 13 years ago
- Status changed from New to Needs Feedback
- Priority changed from Should have to Must have
- Target version set to 4.6.0
- Complexity set to medium
Hi Ingo,
you're at least the second having this problem...
- first guess: delete
typo3temp/Cache/
, which holds the autoloader cache. However, I'm unsure, whether it really exists, or if TYPO3 fails already earlier - probably more helpful: Change
devIPmask
to include your IP. Then access the site and post the stack trace here.
Updated by Steffen Gebert over 13 years ago
.. and please post your extList
here, have a look at typo3conf/extTables.php
and localconf.php
, there is something happening, which is not only configurational stuff.
Thanks
Steffen
Updated by Ingo Pfennigstorf over 13 years ago
Steffen, thanks a lot for your help and reply.
So first, here is an update on that: Setting the devIPmask and tried various debug things in localconf.php didn't help. The typo3temp folder only contained empty folders Cache/ and so on.
Temporary files have not been created at all.
What helped was:
Manually change the return value of t3lib_div::int_from_ver to 4006000 and delete or comment out all other stuff in that function.
Next, go to install tool, do all the upgrade wizard stuff and ... after a DB compare I finally reset the t3lib_div::int_from_ver function to the originial state and everything works fine.
My guess is, that it may have something to do with missing CF-tables - because now it works like a charm.
I even commented out everything in extTables.php
localconf.php only contained one if statement, belonging to the caching framework - if you consider this non-configurational ;)
Do you still need the extList?
Updated by Steffen Gebert over 13 years ago
Thanks for your feedback, however I don't count this as a real solution (more a dirty workaround).
Do you have a backup of the site to try the update again?
Have you set the devIPmask
and then deleted typo3conf/temp_CACHED*
? It should really give you a stack trace, which then could help us to find the root cause.
Updated by Ingo Pfennigstorf over 13 years ago
Yes, definetly no solution. No temp_Cached_* files were generated and the devIPmask was set, first to 127.0.0.1,10.0.* and later as there was no stack trace to *.
I also truncated all cache tables first, also sys_registry and so on. I do have a backup and will try to do this again.
Updated by Steffen Gebert over 13 years ago
So one thing, which comes to my mind, could be that sth. calls t3lib_div::int_from_ver
that early that the whole configuration isn't even initialized.. Would be good, to post your extList here, in case sb. else has the same problem. Maybe one of them has such things in ext_tables.php
(but unsure, if that would really be too soon during bootstrapping).
Updated by Ingo Pfennigstorf over 13 years ago
Yesterday I made a quick search in the ext folder and several extensions called that function.
Btw. I just deleted all cf_ database tables and the error occurs again until I recreate these tables.
This is the extList, there are several custom extensions, but I truly still don't get the point where it fails. Maybe something in the bootstrap happens before an autoloader cache is generated. Dunno.
$TYPO3_CONF_VARS['EXT']['extList'] = 'extbase,css_styled_content,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,t3skin,tt_address,eu_ldap,nkwbrowsinghistory,nkwlib,nkwsitemap,be_acl,stever_rsscontent,nkwuserfeedback,static_info_tables,dam,dam_ttcontent,about,cshmanual,feedit,opendocs,recycler,t3editor,reports,scheduler,nkwtcaaddress,nkwtcadam,nkwtcadedefault,nkwtcamidcol,jm_recaptcha,kickstarter,nkwgok,nkwreport,nkwaddressextend,nkwgmaps,nkwsubreport,nkwsubfeprojects,nkwsubstaff,metasuchexml,realurl,fluid,dsschedgmaps,nkwtcabasic,nkwtca,nkwsubmenu,nkwusertsrte,nkwpiwikoptout,dam_index,patenschaften,standorte,t3jquery,powermail,wt_doorman,powermail_frontend,powermail_cond,linkhandler,imagemap_wizard,nkwtcarte,piwik,wt_spamshield,info,perm,func,filelist,l10nmgr,shorts,nkwkeywords,linkvalidator,static_info_tables_de,pagebrowse,fed,devlog,tika,solr,tmpl_sub,sassify,additional_reports,pazpar2,version,workspaces,scriptmerger';
Updated by Steffen Gebert over 13 years ago
There's some print/get stacktrace function in PHP. Could you use that to output the stack, when the function is called for the first time?
Updated by Ingo Pfennigstorf over 13 years ago
#0 t3lib_div::int_from_ver(4.6-dev) called at [/Users/ingop/Sites/w3d/typo3conf/ext/additional_reports/ext_autoload.php:5]
#1 require(/Users/ingop/Sites/w3d/typo3conf/ext/additional_reports/ext_autoload.php) called at [/Users/ingop/repo/Core/t3lib/class.t3lib_autoloader.php:173]
#2 t3lib_autoloader::createCoreAndExtensionRegistry() called at [/Users/ingop/repo/Core/t3lib/class.t3lib_autoloader.php:121]
#3 t3lib_autoloader::loadCoreAndExtensionRegistry() called at [/Users/ingop/repo/Core/t3lib/class.t3lib_autoloader.php:69]
#4 t3lib_autoloader::registerAutoloader() called at [/Users/ingop/repo/Core/t3lib/config_default.php:779]
#5 require(/Users/ingop/repo/Core/t3lib/config_default.php) called at [/Users/ingop/repo/Core/typo3/sysext/cms/tslib/index_ts.php:123]
#6 require(/Users/ingop/repo/Core/typo3/sysext/cms/tslib/index_ts.php) called at [/Users/ingop/repo/Core/index.php:78]
Fatal error: Class 't3lib_utility_VersionNumber' not found in /Users/ingop/repo/Core/t3lib/class.t3lib_div.php on line 889
Ok - additional_reports seems to be responsible ... After removing it from extList it seems to work finer. Thanks for your help!
Updated by Markus Klein over 13 years ago
Ok, that's hard. But actually I think it is reasonable for an extension to call such basic functions anytime.
The problem is located int t3lib_autoloader:
/** * Find all ext_autoload files and merge with core_autoload. * * @return void */ protected static function createCoreAndExtensionRegistry() { $classRegistry = require(PATH_t3lib . 'core_autoload.php'); // At this point localconf.php was already initialized // we have a current extList and extMgm is also known $loadedExtensions = array_unique(t3lib_div::trimExplode(',', t3lib_extMgm::getEnabledExtensionList(), TRUE)); foreach ($loadedExtensions as $extensionKey) { $extensionAutoloadFile = t3lib_extMgm::extPath($extensionKey, 'ext_autoload.php'); if (file_exists($extensionAutoloadFile)) { $classRegistry = array_merge($classRegistry, require($extensionAutoloadFile)); } } return $classRegistry; }
The ext_autoload.php files are executed before the core autoloads are actually loaded.
I suggest to change the behaviour, so that autoloading of Core is completely finished, before any extension is even touched.
This would also prevent the still existing race condition, where an extension might use int_from_ver in the localconf.php.
Updated by Steffen Gebert over 13 years ago
Christian, could you give your feedback to Markus suggestion? (you don't have to read everything ;-))
Updated by Björn Pedersen over 13 years ago
Duplicate of:
http://forge.typo3.org/issues/28235
Updated by Björn Pedersen over 13 years ago
This case is fixed by: http://forge.typo3.org/issues/28236.
Only ext_autoload files can not use features requiring autoloader.
Updated by Markus Klein over 13 years ago
So what's the reason for implementing our own version comparison system (t3lib_utility_VersionNumber) and not using version_compare()?
Updated by Christian Kuhn over 13 years ago
ext_autoload.php must not have any php code except the return array();
Updated by Christian Kuhn over 13 years ago
- Status changed from Needs Feedback to Rejected
Rejected:
The calculation of the autoload cache identifier was already fixed and the ext_autoload 'I do code here' thing will not be solved.