Bug #30827

t3lib_utility_VersionNumber is not found after trying to upgrade

Added by Ingo Pfennigstorf over 8 years ago. Updated over 8 years ago.

Must have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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.

Related issues

Related to TYPO3 Core - Bug #28098: call to t3lib_div::compat_version() in config_default.php breaks the system Closed 2011-07-11


#1 Updated by Markus Klein over 8 years ago

Hi, can you please check whether this file exists

And can you please provide the full error message.


#2 Updated by Ingo Pfennigstorf over 8 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.

#3 Updated by Markus Klein over 8 years ago

Yeah would be cool. Thx.

#4 Updated by Ingo Pfennigstorf over 8 years ago

Fatal error: Class 't3lib_utility_VersionNumber' not found in /Users/ingop/repo/Core/t3lib/class.t3lib_div.php on line 887

#5 Updated by Steffen Gebert over 8 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.

#6 Updated by Steffen Gebert over 8 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.


#7 Updated by Ingo Pfennigstorf over 8 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?

#8 Updated by Steffen Gebert over 8 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.

#9 Updated by Ingo Pfennigstorf over 8 years ago

Yes, definetly no solution. No temp_Cached_* files were generated and the devIPmask was set, first to,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.

#10 Updated by Steffen Gebert over 8 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).

#11 Updated by Ingo Pfennigstorf over 8 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';

#12 Updated by Steffen Gebert over 8 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?

#13 Updated by Ingo Pfennigstorf over 8 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!

#14 Updated by Markus Klein over 8 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.

#15 Updated by Steffen Gebert over 8 years ago

Christian, could you give your feedback to Markus suggestion? (you don't have to read everything ;-))

#17 Updated by Björn Pedersen over 8 years ago

This case is fixed by: http://forge.typo3.org/issues/28236.

Only ext_autoload files can not use features requiring autoloader.

#18 Updated by Markus Klein over 8 years ago

So what's the reason for implementing our own version comparison system (t3lib_utility_VersionNumber) and not using version_compare()?

#19 Updated by Christian Kuhn over 8 years ago

ext_autoload.php must not have any php code except the return array();

#20 Updated by Christian Kuhn over 8 years ago

  • Status changed from Needs Feedback to Rejected


The calculation of the autoload cache identifier was already fixed and the ext_autoload 'I do code here' thing will not be solved.

Also available in: Atom PDF