Bug #21388

typo3temp got filled with thousands of javascript_* files

Added by Mittwald CM over 11 years ago. Updated over 7 years ago.

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


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


If you use "GMENU_LAYERS / TMENU_LAYERS" without a specific "layer_menu_id" then your typo3temp will be filled continously with javascript_* files.

If you want to specifically name a menu on a page. Probably you don't need that!

This is wrong, you SHOULD set it to avoid this bug if it's not fixed.

The unique filename is created with a string md5(microtime()).
(Actually it's intended to be unique.)
md5(microtime()) can create millions of different filenames causing typo3temp to be filled more and more.

Problems with temporary files with unique filenames are also mentioned in Bug #21387 (http://bugs.typo3.org/view.php?id=12375).
This bug can also show DoS-like behaviour.

The applied patch is a dirty bugfix. It replaces microtime() with a string built around env var TYPO3_HOST_ONLY.

A better fix should use a system wide (system=TYPO3) class-function especially written for purposes like this.

(issue imported from #M12376)


Related issues

Related to TYPO3 Core - Bug #22311: another Bug causing typo3temp to fill up with filesClosed2010-03-22

Related to TYPO3 Core - Bug #20329: cache_hash fills up with huge amounts of MENUDATAClosed2009-04-21

Related to TYPO3 Core - Bug #21387: typo3tempgot filled with thousands of EXTERNAL_URL* filesClosedDmitry Dulepov2009-10-28

Related to TYPO3 Core - Bug #23866: layered menus generate "too much recursion javascript-error"Rejected2010-10-28

Related to TYPO3 Core - Bug #23867: Menu_Layers is screened incorrectRejected2010-10-29

Related to TYPO3 Core - Bug #23957: nested XMENU_LAYERS and the typo3temp *.js caching bugRejected2010-11-05

Related to TYPO3 Core - Bug #24367: changes in tmenu_layers.php broke TMENURejected2010-12-19

Related to TYPO3 Core - Bug #28640: TMENU_LAYERS does not always create unique IDs for the third levelRejected2011-08-01

Related to TYPO3 Core - Task #46358: Separate ext:statictemplates code from coreClosed2013-03-16


Updated by Georg Ringer over 11 years ago

Additional information - How to reproduce:
1.) Delete temp js files in typo3temp
2.) Create a Layer_menu with a code like this

page.20 = HMENU
page.20 {
    1 {
      wrap=<table border="0" cellspacing="0" cellpadding="0">|</table>
      layerStyle = position:absolute;VISIBILITY:hidden;border: 1px solid #CCCCCC; background: #ffffff;

      lockPosition = y
      hideMenuWhenNotOver = 1
      leftOffset = 0
      topOffset =22
      relativeToTriggerItem = 1

      NO {    
        ATagParams = class = "menue" 

    2 = TMENU
    2.NO {
      ATagParams = class = "menue1" 

3.) click around and look at the typo3temp/ it will get larger with every click.


Updated by Jorgo S. over 11 years ago

Hi Georg,
thanks for the patch! I tried the generic one on Typo3 4.3 and unfortunately, js and css files are still being generated. Anything I can do to help troubleshoot this?


Updated by Mittwald CM over 11 years ago

Hi all review,

@Georg: Your patch differs from my original patch. Did it happen accidentally or was it your intent?
md5('gl' ...
md5('tl' ...
md5('tl' ...
md5('tl' ...

@Jörg: The patch was created when doing some research for an article in german T3N magazine. Are you sure that the patch did succeed without any error? Is it possible that the class files are cached in any way and the cached files and not the patched files are used? Can you give me some examples of js filenames? There may be still another bug which affects also css files. Then there will be more research needed.



Updated by Jorgo S. over 11 years ago

Hi Frank,

I think I had a caching problem after applying the patch before. Now, no more .js files are accumulated, thanks again!


Updated by Mittwald CM over 11 years ago

Hi all review,
it looks like nobody cares about this bug. Maybe there should be more users with 2 million .js files in typo3temp like posted on twitter a few days before. ;-)

Hint: If your typo3temp is grown and you have to delete many thousands of files then the small linux-tools "direntries" (part of the sac-tools software suite) may be useful for you.
Example: direntries -D -e .js typo3temp
It will delete the .js files faster than any other tool on linux.


Updated by Mittwald CM over 11 years ago

A new patch is available.
As an additional string for creating the ID a serialized representation of the menu array variable menuArr is used.


Updated by Vahan Amirbekyan over 11 years ago

the patch for 4.2.9 worked for me on 4.2.6
the patch for 4.3.2 did not work for me though on 4.3.2

Should anything else be applied together with this patch(s)?


Updated by Mittwald CM over 11 years ago

Please try the simplified patch typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch.
Compare the patched files with their originals to see the small difference.

The patch should fit for all TYPO3 versions (with a little offset).


Updated by Jorgo S. almost 11 years ago

I thought this was already fixed in Typo3 4.4(x). Now I just realized that after updating, I had another 4600 .js files in my temp folder...


Updated by Chris topher almost 11 years ago

Hi guys,

please send a reminder to the thread in Core List, so that this problem gets a bit more attention.

Thank you!


Updated by Jorgo S. almost 11 years ago

I've used typo3-4.3.2-no-typo3temp-fill-with-javascript-3.patch on Typo3 4.4.2 and it doesn't seem to have any effect. Anybody else?


Updated by Mittwald CM almost 11 years ago

Hi Jorgo,
on 2009-12-14 you wrote that you already had a "caching problem" (solved).
Now we try it again. :-)
1) Did you verify that the files are actually patched?
2) Are you sure that there are no copies of these on other places installed and "activated"?
3) Did you check for Bug #22311?
4) Do you use GTMENU (http://wiki.typo3.org/wiki/GTMENU)?
If you can't solve it please post the last few lines of an example typo3temp/*.js file.
I've successfully patched hundreds of TYPO3 installations.


Updated by Lars Houmark almost 11 years ago

I have just bumped the core list with a new CGL version of the patch after my testing of v3. Let's hope this one gets solved soon. It certainly have waited long enough. Will attach the patch here for reference.


Updated by Steffen Kamper almost 11 years ago

committed to svn
4_2 rev 9035
4_3 rev 9036
4_4 rev 9037
trunk rev 9038


Updated by Jorgo S. about 10 years ago

As per various posts of mine in the newsgroups, I had advised that

In my typo3 4.4.4 there are 2 identical versions of the script. One
resides in
and this is where the patch header points to.

Another version resides in
and only after I had patched those files as well did the creation of
new .js files stop.

Also, in Typo3 4.5.3, different (older) versions of the files than in 4.5.2 seem to have been included.


Updated by Jorgo S. about 10 years ago

I've advised about this bug in the Bug Day Wiki http://wiki.typo3.org/BugDay/201105, in the newsgroups and here, yet nobody seems to want to fix it as 4.5.4 came out with it AGAIN.


Updated by Xavier Perseguers about 10 years ago

  • Status changed from Resolved to Needs Feedback
  • Assignee deleted (Steffen Kamper)
  • Priority changed from Should have to Must have
  • Target version deleted (0)

Reopen the bug and waiting for further tests/feedback/...


Updated by Kay Strobach over 9 years ago

why not using md5(json_encode($config_array)) as name for the js file?! this way you would only get a new file, if the config changes.

I have not spent time to digg into the issue's code, but i think this could be a solution



Updated by Steffen Gebert over 9 years ago

To be honest, I don't exactly understand the problem (at least not under which circumstances it exists).

What's with the option layer_menu_id? Does that help?

The patch mentioned here was obviously only applied to the file in cms/tslib/, but not in statictemplates/. But, if I don't get you wrong, this one doesn't work, too?


Updated by Steffen Gebert over 9 years ago

Example code by Sergey Alexandrov:

temp.topmenu {
  1 {
    wrap = <tableborder="0"cellpadding="0"cellspacing="0"class="level1"align="center"><tr>|</tr></table>
    NO.allWrap = <tdclass="level1"align="left">|</td>

  2 {

Updated by Steffen Gebert over 9 years ago

I still cannot reproduce this. What's the difference between all these files' contents?


Updated by Christian Kuhn over 8 years ago

  • Status changed from Needs Feedback to Rejected

With 6.1 issue #46358, the _layers menus where moved to statictemplates, and statictemplates was removed from core afterwards. This issue won't be solved in the core anymore.


Updated by Jorgo S. over 8 years ago

Wow... 2 years of nothing and then this is what the community gets? What about the 4.x versions???


Updated by Artur Cichosz over 7 years ago

Just for reference in case somebody still has this problem with TYPO3 4. The patches disscussed here did work in our case.
We actually did set the tmenu_layers and gmenu_layers script excplicitely, so there is no issue with different locations of that scripts among different TYPO3 versions.


This worked for almost a year but today for some reason we had double function definitions caused by the same identifier generated twice inside the DHTML menu JavaScript code.
Now the Menu didn't work as expected and some layers just didnt got hidden on mouse out.

To fix this again without too much digging I just changed the critcal line of code from this

 $this->WMid = trim($this->mconf['layer_menu_id'])?trim($this->mconf['layer_menu_id']).'x':substr(md5('tl'.serialize($this->result)),0,6);

to this

$this->WMid = trim($this->mconf['layer_menu_id'])?trim($this->mconf['layer_menu_id']).'x':substr(md5('tl'.serialize($this->result).$this->id),0,6);

Now it works again.

Also available in: Atom PDF