gnagent

I had the same problem on a local OSX 10.5.7 install with MySQL 5.0.67 and Apache 2.2. It was pretty clear that WordPress was at fault, because phpMyAdmin was working just fine in the same doc root using the same MySQL user.

I had to change from “localhost” to “127.0.0.1” for “DB_HOST” in wp-config.php to get it to work. Sort of ridiculous, since I can actually access the site at https://localhost/wordpress/wp-admin/install.php after making this change. Given that “127.0.0.1” can’t fail as a substitute for “localhost”, it seems like wp-config-sample.php should be permanently changed to use the IP address rather than the hostname.

By the way, if you make the above changes, and instead of an error message, you are told that everything worked fine, but your plugin still isn’t available, check to see if it has unpacked in the /wp-content/upgrade directory rather than in the /wp-content/plugins directory where you hoped it would. If it did, read this webpage:

https://www.theosquest.com/2009/04/19/fixing-plugin-auto-update-in-wordpress-271/

and follow the direction exactly, including making the change from ‘getmyuid’ to ‘posix_getuid’ (the ‘sanity’ check). In WordPress 2.7.1 the ‘getmyuid’ function is used on lines 626 & 628 of /wp-admin/includes/file.php, and those need to change to use posix_getuid.

Good luck and I hope this helps. My installation is now able to upload a plugin .zip file and have it installed and read to be activated, but it took a good three hours of digging to get it to work. Not what I’d call friendly, but hey, the price is right. ??

There is a space character in the critical define statement above that solves the problem described in this thread:

define('FTP_PLUGIN_DIR ','/path/to/wordpress/wp-content/plugins/');

should be:

define('FTP_PLUGIN_DIR','/path/to/wordpress/wp-content/plugins/');