Could it not be some trouble by akismet ?
Or a possible attack ?
I would try to recreate the blog with new password, etc.
Thread Starter
Deep
(@deep)
Akismet..I just disabled it, but no change, it still creates the files…
Attacks – Not possible actually..blog is not very popular + I dont see anything logs too
I guess the only way left is, reinstall..I will reinstall it tonight and see what happens…
Thanks for the help.
Regards,
Deep
Please, tell us about the result.
There were some similar problems and those seemed to be related php safe mode, somehow.
But your other blogs work all right.
Is this particular blog confused about where to put its cache? The example looks rather like the kind of files that appear in the cache folder.
Thread Starter
Deep
(@deep)
Hi,
I reinstalled the wp but still the issue remains…I too feel that there is some issue with the cache but I couldnt find any option to define cache path…
the folder cache in wp-content is also chomd’d to 777
Kassad – Yes, all blogs work fine excpet this one…
Regards,
Deep
Thread Starter
Deep
(@deep)
I tried to trace out the issue by reading few files..I have noticed that it is storing all admin stuff in the file…i.e. the usernames, plugin names etc…
and all files have <?php ?>
Thread Starter
Deep
(@deep)
I guess it creates tmp file only when people have logged into the admin panel…
Well, this is certainly a typical case when what we can do is only guesswork, more or less.
Not enough data.
It looks, LesBessant is right, but we do not know the how and the why.
You should consider your server setup, blog setup, themes, etc.
Are you running standalone wp or wpmu ?
Tried changing theme ?
Tiga uses themetoolkit, it may cause trouble, perhaps.
Disable cache ?
All in all, it is a particular blog which causes trouble.
So, the problem should be just there.
Thread Starter
Deep
(@deep)
Its standalone WP..
Yes, I tried changing theme…i.e. got rid of Tiga too but still it didnt help…I feel that, it creates tmp files when users get into admin panel..coz the data of the tmp files contain admin stuff i.e. user details, plugin names, theme details etc….
Disable cache – thats the only thing is left…I have just disabled it by adding this line in the config file
define(‘DISABLE_CACHE’, true);
Let’s see what happens next..I will update this thread in few minutes…
Seriously, never faced such kind of problem ever…its like running with eyes shut…..
Thread Starter
Deep
(@deep)
Hurray….Time for the cake… 😀
disable_cache fixed it 🙂
Awesome…
Thanks both for the help…
Regards,
Deep
Hallelujah 🙂
Now, I would just like to know why this blog has run amouck.
I suppose, there are more with caching.
Thread Starter
Deep
(@deep)
Basically what I feel is, at the time of updating he might have missed something..i.e. might not have old disabled plugins while update or something…and then it would have generated errors in update..
but thats just the guesswork…coz this is the only thing I can do now 🙂
Regards,
Deep
I have spent the last day fighting with a blog having precisely this problem. It was writing multiple files to the tmp directory and ended up taking down other wordpress blogs on the server as it cut down on the available temp space. We ended up backing up the database and then installing a clean copy of wordpress and re-integrating the database.
The user was running multiple plugins, although I’m not sure that akismet was one of them. The tmp files contained different information, some looked like those described above, and others had entire page (word chosen carefully) content.
Even passwording the blog directory didn’t stop the process once it had begun, which gave rise to serious concern.
As I say, we have headed off the issue by installing a clean copy of wordpress, but this was a very serious problem, which is why I’ve added information to this old thread.
I’m the user codemonkey referred to, and we would both definitely appreciate anything others have to offer on this issue.
Akismet was not running on the blog btw. The most recent update was perhaps three months ago, and there have been very few changes made since, and none in the last day or two which would have been when these files were being generated (they can’t have been arriving for longer than that or they’d have taken the server down sooner).
Have noted the disable_cache trick, but would really like to know *why* this happened.
