Auto detect mysteriously stopped working...

[kcristiano]

Just today I started receiving errors when adding new pod cast episodes.

Blurbrry PowerPress verison 1.0.3 with Wordpress 2.8.6, dedicated server.  MySQL 5.1.39, PHP 5.3

Error is:

"Unable to create temporary file for checking media information" when posting or if you choose the verify option.

However, If I manually set the file size and duration, posts fine.

Been using this for a while, first problem.   tried deactivating and activating plugin, reinstalled plugin no help..

Where is the temporary file being created?  I can look at a rights issue, but I have changed nothing on the server.

Any help/insight would be greatly appreciated!

Thanks,

Kevin

[angelo]

This means that the temporary folder on your server for some reason is not writable. You will want to contact your web hosting provider about the issue.

Some web hosting plans place a /tmp folder right at the root of your FTP login and that /tmp folder should never be deleted and the file permissions for the folder should be 777. More than likely either your tmp folder is no longer writable, the folder no longer exists or is completely full and needs to be purged by the server administrator. Your web hosting provider will be the one who will know how to fix the problem.

[kcristiano]

This means that the temporary folder on your server for some reason is not writable. You will want to contact your web hosting provider about the issue.

Some web hosting plans place a /tmp folder right at the root of your FTP login and that /tmp folder should never be deleted and the file permissions for the folder should be 777. More than likely either your tmp folder is no longer writable, the folder no longer exists or is completely full and needs to be purged by the server administrator. Your web hosting provider will be the one who will know how to fix the problem.

That is what I thought. However,  I have a dedicated server.  the /tmp folder is the temp folder, it is 777 and other apps (forum software notably) are reading and writing to it without issue.  It is not full at all.

Can you tell me where in the code it looks for the temp folder?  I am thinking that a variable is not define correctly so I want to try coding the path on one of my development blogs to troubleshoot. 

I have looked and it appears to calls a function and if not defined it goes to the system temp. 

I have set wp-content to 777 on my dev blog and it works, but I am not a fan of 777 anywhere so any direction on where this is looking (even back to wp core) would be helpful.

Thanks

[angelo]

The code you are looking for is in the powerpress/mp3info.class.php, go to lines 358-361. If you are using WordPress 2.7+, then the WordPress function get_temp_dir() is called for the temporary directory. You can set this temp path by adding the following define to your wp-config.php. The line needs to be above the require wp-settings.php or else it will not apply.

Code: [Select]

define("WP_TEMP_DIR", "/tmp/");

The call to get_temp_dir() in WordPress checks to see if WordPress can write to the temp folder, and if it cannot returns the system temporary directory (/tmp/). Here's the code if you are curious what WordPress is doing:

Code: [Select]

function get_temp_dir() {
if ( defined('WP_TEMP_DIR') )
return trailingslashit(WP_TEMP_DIR);

$temp = WP_CONTENT_DIR . '/';
if ( is_dir($temp) && is_writable($temp) )
return $temp;

if  ( function_exists('sys_get_temp_dir') )
return trailingslashit(sys_get_temp_dir());

return '/tmp/';
}

You may also want to temporary enable error reporting for your web site to see if there are other errors being generated by PHP. Here's some code you can add to your .htaccess file to do this:

Code: [Select]

# All Error reporting (except notices):
php_flag display_errors on
php_value error_reporting 2039

Remember to remove or comment out these lines after you are done testing so your web visitors do not accidentally see them.

[kcristiano]

OK.

That helped.  No "solution" but I see the issue.

Defining WP_TEMP_DIR fails.

WP's function looks to wp-content if it fails so making that directory 777 "fixes" things.

My issue is why WP will not

a) see the temp directory from php.ini (and phpbb3 does, same server)
b) accept WP_TEMP_DIR definition in wp_config.php

So, not a blubrry issue at all.  Thanks.

One question:  as a work around I have disabled auto detect for file size and duration.  Seems to work fine, but are there any pitfalls I should watch for?  keep in mind we are not podcasters, but have audio/video we use in posts from time to time.

Thanks again.
EDIT: I just tried adding this:

Code: [Select]

define('WP_TEMP_DIR', ABSPATH.'wp-content/tmp');
Works.

I am certian this has something to do with the open_basedir directive.  Now why phpBB3 can write to /tmp and WordPress cannot is an issue for another day....

[angelo]

What is the value in your open_basedir setting? It should have .:/tmp:... in it.

Did you try this define to see if it works?

Code: [Select]

define('WP_TEMP_DIR', '/tmp');

Just to be on the same side, you can secure that /wp-content/tmp folder by adding a line to your .htaccess file. Add this line directly below the RewriteBase / line:

Code: [Select]

RewriteRule ^wp-content/tmp [F]

This will make accessing the wp-content/tmp folder from a web browser display a 404/403 not found / forbidden message.

If you want to be able to upgrade WordPress from the web, you will also need to make an upgrade folder 777 in the wp-content folder, in which case you would want to ad another RewriteRule for that folder as well...

Code: [Select]

RewriteRule ^wp-content/upgrade [F]

[kcristiano]

Thanks for the response.

No /tmp is not in the open_basedir , it should be.  I'll test that on off hours.

I use SVN to update wordpress, so i have not had to go with an upgrade directory. 

Thanks for the help.  I really need to figure out how phpbb3 is writing to /tmp.... It should not be allowed, yet it is.

[angelo]

phpBB has been known to do weird things, it may have its own temp folder. A Google search may get you the answer.

Using subversion is smart, I do the same for our WordPress blogs.

If you do a subversion checkout / co, you may want to add the following to your Apache httpd.conf, which will prevent users from accessing those hidden .svn folders:

Code: [Select]

<Files ".svn">
    Order allow,deny
    Deny from all
</Files>
<DirectoryMatch "/\.svn/">
    Order allow,deny
    Deny from all
</DirectoryMatch>

[kcristiano]

Thanks for the pointers.  I had been using svn export to avoid the .svn clutter, but adding the deny rules is better.  I just moved my development blog to wp 2.9.1 beta and used svn and with the blocking rules, I am fine. 

This was an added bonus.  Thanks again.