Plug-in update no longer works on my configuration with 2.7

[cwiltgen]

WordPress's plug-in updating mechanisms have worked on my installation for as long as they've existed, until v2.7.

Now, it reports "Unable to locate WordPress Plugin directory. Plugin upgrade Failed." Unfortunately, it doesn't report any useful, specific information (i.e. where it thinks it should be, etc.).

The plug-in directory hasn't moved, and is in the same standard place it's always been.

I notice that the plug-in updating UI now just asks for a hostname, and not a path. It should ask for a path, since sftp-ing to the hostname doesn't resolve to wordpress's root directory. I'm assuming this is why the new code doesn't work.

-- Charles Wiltgen

[DD32]

I notice that the plug-in updating UI now just asks for a hostname, and not a path.

Has it ever asked for a path?

It should ask for a path, since sftp-ing to the hostname doesn't resolve to wordpress's root directory.

Its supposed to search out the path automatically for those who do not know the path

The reason its reporting that error, Is its expecting to find a folder, but it couldn't locate it, so its failed.

Can you give some examples of your setup?
ie.

WP_CONTENT_DIR = /home/dd32/public_html/wordpress/wp-content/
FTP Dir = /public_html/wordpress/wp-content/

(And you're using the SFTP Option, Does the normal FTP option work?)

[ryan]

Closing pending reporter feedback. Reopen with the requested information.

[ocean90]

I have the same problem.

"Unable to locate WordPress Content directory (wp-content)." (Plugin install)

"Unable to locate WordPress Root directory." (Core update)

I use the FTP option.

WP_CONTENT_DIR = /var/www/web39/html/blog/wp-content/
FTP DIR = /html/blog/wp-content/

But I it works, if i add these lines to my wp-config.php:

putenv('TMPDIR=/var/www/web39/html/blog/wp-content/tmp');
define('WP_TEMP_DIR', ABSPATH . 'wp-content/tmp');

If you need more infos, ask. Maybe we can fix it in 3.0.

[dd32]

ocean90: Did this work in a previous version of WordPress & just suddenly stop with 3.0, or has this been occuring in previous versions as well?

Do you need both of those lines, or only the latter?

[ocean90]

dd32: I think the problem exists since version 2.8.

I tested it again and it works, if I add only the first line. So it seems that WordPress can't access to the tmp directory.

[ocean90]

I could catch a warning which confirm my guess.

Warning: tmpfile() [function.tmpfile]: open_basedir restriction in effect.
File(/tmp) is not within the allowed path(s): (
/var/www/web39/html/:
/var/www/web39/phptmp/:/var/www/web39/files/:
/var/www/web39/atd/
)in
/var/www/web39/html/blog/wp-admin/includes/class-wp-filesystem-ftpext.php
on line 116

I get this message on bulk updates. Maybe we can fix it or show a specific message what the problem is (and/or fix the warning message on bulk updates site)

[dd32]

can you do some debugging of ​get_temp_dir() and see where the issue is arising?

From what i can tell, Your PHP config is setup in a way which makes it impossible to determine a valid temporary directory. Can you supply me a copy of the phpinfo() page perhaps? (on this ticket, or email wordpress@ my_username .id.au or IRC, etc)

[ocean90]

get_temp_dir() returns /var/www/web39/phptmp/. And that is my upload_tmp_dir

The problem, is that tmpfile() doesn't use the temp dir which get_temp_dir returns. It use /tmp. But this directory is not in my open_basedir list.

Here are some sites, which explain the problem:

• ​http://bugs.php.net/bug.php?id=40141
• ​http://php.net/manual/en/function.tmpfile.php#74623
• ​http://www.codingforums.com/showthread.php?t=146437
  

So, I don't know if we can fix it in the core, eventually do not use tmpfile()?
But I contacted also my webhoster, if they can add the tmp directory to open_basedir. Wait for an answer and then I check it again.
But if it works by me then, then its not fixed globally, only for me and some other users from my webhoster and not for ​other users.

[dd32]

Since your problems seem to be unrelated to the reporter here, I've created a new ticket here: #12866

I'm re-closing this ticket as it was originally.