Bug #14371

Problems with "Clear temp_CACHED" and "Clear All Cache"

Added by Wolfgang Klinger almost 17 years ago. Updated about 15 years ago.

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


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


If you click those two links let's say "too fast" (or maybe in the wrong order) on a server with a higher latency it may happen that you end up with an error message like this:

Error: The main frontend extension "cms" was not loaded. Enable it in the extension manager in the backend.

And this on the website and in the backend!!

The solution was to delete the temp_* files in the typo3conf directory and reload.
(issue imported from #M446)


15_checkBeforeWrite_tempCACHED.diff (893 Bytes) 15_checkBeforeWrite_tempCACHED.diff Administrator Admin, 2005-04-26 12:54
em_bug.diff (4.12 KB) em_bug.diff Administrator Admin, 2005-05-18 23:40

Updated by Ingmar Schlecht almost 17 years ago

It would have been interesting to know what the contents of the temp_* files were when you had that strange error.

Can you reproduce it? It would also be nice if you could suggest a fix.


Updated by Wolfgang Klinger almost 17 years ago

I have not seen this behaviour since then, but it occurs much more often that the following error message is displayed:

Warning: main(/home/something/www/typo3conf/temp_CACHED_ps37cd_ext_tables.php): failed to open stream: No such file or directory in /home/something/www/typo3/init.php on line 255

The reason is obvious (Clear temp_CACHED deletes the files and Clear all cache needs them), so I wonder why there are two buttons instead of one, as not even Kasper knows what they really do (look at one of the videos of the Snowboard tour of 2003)...

I suggest to remove "Clear temp_CACHED" and move any functionality to "Clear all cache"!


Updated by Sven Wilhelm over 16 years ago

I think I also note this bug in one of our production systems.
But the workaround by deleting temp_* didn't work.
Also the Menu-Item clear temp was not shown.
This bug is really hard and should be of priority critical.
Feedback of a friend: there are other systems outside display this bug on their page.


Updated by Michael Stucki over 16 years ago

We just had this problem on one of our clients site.
I did save the temp_CACHED files which caused the error and compared them with some working ones produced after removal.

The main difference was the line on the beginning, setting $TYPO3_LOADED_EXT to some serialized content. The malicious version didn't list the "cms" extension (plus many more) inside.

Since "cms" is the main extension which must be loaded always, I suggest a solution like this:

Check if $TYPO3_LOADED_EXT contains the "cms" extension and if not, clear the cache and reload the page.

Unfortunately I cannot test if this occurs on 3.8 as well, but I guess this did not change since then.


Updated by Michael Stucki over 16 years ago

The patch might solve the problem. Unfortunately I don't know how to check if it works...(?)


Updated by Michael Stucki over 16 years ago

Finally, I discussed this with Kasper. He did not like my patch supplied as 15_checkBeforeWrite_tempCACHED.diff, mainly because the "cms" extension is not neccessarily loaded at all.

After some research by Kasper and me we came to a solution which might work but we're both not sure as we cannot reproduce the bug.

I will post the full conversation between Kasper and me below and change the bug resolution to "feedback" - maybe it can be closed but who knows...


Updated by Michael Stucki over 16 years ago

I have researched the issue and it appears to me that in the case that
fails no global and system extensions are loaded! That seems to be the
pattern if you look at the $TYPO3_LOADED_EXT variable. Whatever the
changes are in the files depends only on which extensions were loaded.

Yes, that's what I thought as well.

So, looking at why this might happen you find the function
t3lib_extMgm::typo3_loadExtensions(). All I can suspect here is that
this part fails for some reason:

(lines 947-954 approx)

That would make sense, yes. However I can't believe that is_dir returns
different results - would be very strange indeed!

Now, I would actually like to know more if is_dir() can fail. One option
is that it contains a cached result, but why should it. Anyway, I have
added a call to clearstatcache() before testing. That can't hurt.

I can do some research about that is_dir function later.

In addition I suggest that we allow caching only if access to the global
and system main dirs is OK. If the problem is a temporary glitch where
they are not available this will make sure that state is not cached.


Any other suggestions?

If this trick does not work it might make sense to look "behind" the sysext/
directory. In other words: sysext/ might be present as a symlink but behind
there is an empty directory!

I don't know if is_dir would still return true in that case...(?)


Updated by Michael Stucki over 16 years ago

I have checked bugs.php.net if there are any issues with is_dir(). What I
mainly see is that PHPs bugtracker is a big chaos with every issue 10 times

There were no bugs which might match this problem, but there was a comment at
this page: http://bugs.php.net/bug.php?id=22499

| I too have discovered directories are not always recognised,.  However, | I have found they are correctly recognised provided I ensure the path | has a '/' on the end. | | This bug appears to be widely reported and to my knowledge has not been | fixed even in recent versions.  Can someone please investigate?"

And this sounds like it could be our problem! Again, I cannot test it but
according to this guy the problem is solved by adding a slash to the path.
I have attached a patch which adds these slashes, and I guess that we can now
be sure that the problem won't happen anymore...


Updated by Michael Stucki over 16 years ago

The patch em_bug.diff might fix the problem. The change is already implemented in TYPO3 3.8.0.


Updated by Wolfgang Klinger over 16 years ago

I haven't had the problem for a long time now, can we close this bug report?


Updated by Michael Stucki over 16 years ago

Made a change which seems to solve the problem, but we couldn't reproduce it ever so we don't know if it's really fixed. If the problem still occurs with TYPO3 3.8.0 or later, please reopen this bug.

Also available in: Atom PDF