Letting WordPress users install themes, plugins without FTP credentials

[shacker23]

I run a WHM server, and lots of users have WordPress sites. WordPress provides an interface for installing plugins and themes directly from the WP Dashboard, without having to FTP them into place. On my server, when they select a theme to install, WordPress prompts for FTP credentials.

On some cPanel hosts, like BlueHost, users are NOT prompted for FTP credentials - the plugin or theme just installs itself, no questions asked. I'm trying to figure out how this is possible so I can offer the same convenience to my WP users. According to this page, it's a simple matter of permissions - if the user "nobody" can write to wp-content/themes, this should "just work." But I can't seem to make it work.

chown username:nobody wp-content/themes
chmod g+w wp-content/themes

(still prompts for credentials)

chown nobody:nobody wp-content/themes

(still prompts for credentials)

So, on this test install, perms are currently:

drwxrwxrwx   6 nobody  nobody 4096 Mar 21 12:00 themes/

but it still doesn't work. What does it take to get this working?

Thanks,

[shacker23]

I had posted a big explanation of how this works, but this forum swallowed my message with "token expired," grrr.

Quick answer: Put this in the user's wp-config.php file:

define('FS_METHOD', 'direct');

and it results in a non-suPHP cPanel server to allow the user-friendly plugin/theme installer to work.

[Infopro]

More on WordPress Upgrade Constants

and it results in a non-suPHP cPanel server to allow the user-friendly plugin/theme installer to work.

Not sure this makes sense, but I get the point I think.

After you've made your changes, and uploaded a new theme for example, who owns those files and what are the permissions on them if I may ask? Your server *is* running SuPHP, correct?

[shacker23]

Here are the perms on the folder containing a theme installed in this way:

drwxr-xr-x 5 nobody nobody 4096 Mar 24 09:53 f8-lite/

and files within that theme have:

-rw-r--r-- 1 nobody nobody 583 Mar 24 09:53 page.php

No, this server is not running suPHP (if it were, I wouldn't have to use this technique).

[Infopro]

Here is an informative article on this technique:
WordPress How-To: Force Direct Filewrites For Upgrades « Viper007Bond.com

Wouldn't SuPHP solve this for you, and be safer?

[shacker23]

Infopro: What are the potential downsides to switching to suPHP? What could possibly go wrong? Things that might not work as expected... ?

Thanks.

[Infopro]

IMHO, arguably there are none. And in this particular situation? The perfect answer.

You'll need to do some homework, switching to SuPHP has been covered quite a bit on these forums. File and Directory permissions and owner will need set, some users may have far more space used than you're aware of being used, as a couple of examples of problems you may come into as you'll read in those threads. Easy to sort out and worth the trouble.

cPanel comes with SuPHP enabled by default these days, AFAIK.

You want users to own their own files. It's easier for them to do things like updating Joomla or wordpress of SMF (three examples of scripts that allow updating via their admin panels) and it's easier for you as they don't have to bother you with setting directories and files owner and perms all the time so they can delete something they've uploaded thru a PHP script.

[shacker23]

Thanks for that great response. Sounds like this will be my next project, as soon as the dust settles from other recent changes. I'll start reading up. Much appreciated!

[dtravington]

I found a few commands to help with troubleshooting here as well. /http://docloft.com/wordpress-prompts-for-connection-information/ I believe they are building an AWS instance for WordPress using a LAMP stack from scratch

[brianoz]

IMHO, arguably there are none. And in this particular situation? The perfect answer.

+1 - there is little or no downside.

The downside to NOT having suPHP (or similar) is that you are running your server with a pretty significant security hole open. Users can read each other's PHP files - not something you want!