Terence Milbourn

Whether we understand it or not, the universe is right on time.

@nike.stars — files yes, but folders no, they should be 755 which is what putting those two lines in your wp-config.php file should ensure.

@reviveam — Google is your friend…

The Apache HTTP Server is a modular program where the administrator can choose the functionality to include in the server by selecting a set of modules. The modules can be statically compiled into the httpd binary when the server is built. Alternatively, modules can be compiled as Dynamic Shared Objects (DSOs) that exist separately from the main httpd binary file. DSO modules may be compiled at the time the server is built, or they may be compiled and added at a later time using the Apache Extension Tool (apxs).

suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.

@ad Lagendijk — I had already tried all those standard fixes before writing here. In the end, I just fixed it a few moments ago by adding one “putenv” line to my wp-config.php file…

putenv(‘TMPDIR=’ . ini_get(‘upload_tmp_dir’));
define(‘FS_CHMOD_DIR’, (0755 & ~ umask()));
define(‘FS_CHMOD_FILE’, (0644 & ~ umask()));

The other two definitions I just put in for housekeeping reasons. They work in a SuPHP machine but I have no way to tell if they will be effective in a DSO machine, but I expect they won’t.

I solved my problem by putting this single line in my wp-config.php file…

putenv(‘TMPDIR=’ . ini_get(‘upload_tmp_dir’));

I think there’s more to it than 777 being the answer. If you set 755 under SuPHP, the permission used is “7” and 777 under DSO the permission used is “7” so in the case of 755 on SuPHP verses 777 on DSO, it is exactly the same thing! If you want to set something to 777, you set it to 755 on SuPHP. If you actually set it to 777, you instead actually set 000 —- NO ACCESS — oops!

If you simply set permissions without knowing if you’re on a DSO or suPHP machines, you could be in a world of pain. If you set 755 under SuPHP, the permission used is “7” and 777 under DSO the permission used is “7” so in the case of 755 on SuPHP verses 777 on DSO, it is exactly the same thing! If you want to set something to 777, you set it to 755 on SuPHP. If you actually set it to 777, you instead actually set it to 000 —- NO ACCESS — oops! And this doesn’t solve the problem for everyone, especially those on suPHP machines like me.

If you simply set permissions without knowing if you’re on a DSO or suPHP machines, you could be in a world of pain. If you set 755 under SuPHP, the permission used is “7” and 777 under DSO the permission used is “7” so in the case of 755 on SuPHP verses 777 on DSO, it is exactly the same thing! If you want to set something to 777, you set it to 755 on SuPHP. If you actually set it to 777, you instead actually set it to 000 —- NO ACCESS — oops!

I am having exactly the same “Could not create directory” problem. It started out of the blue a few days ago on one installation of WP 3.0.1. I have 3 other sites running 3.0.1 on the same server which are all working fine, but this one just won’t play nice for some reason.

On a connected note. I see some folks advising us to set perms at 777 without knowing if its a DSO or SuPHP server, which can be very helpful. If you set 755 under SuPHP, the permission used is “7” and 777 under DSO the permission used is “7” so in the case of 755 on SuPHP verses 777 on DSO, it is exactly the same thing! If you want to set something to 777, you set it to 755 on SuPHP. So if on a SuPHP machine you actually set it to 777, you instead actually set 000 —- NO ACCESS — oops!

Now to get back to trying to find the REAL cause of the problem and a REAL solution.

@newhollandbrew — What do you think the right place for the sitemaps directory should be. The plugin default was what I used. The error was reported by Google’s Webmaster Tools. In the end, I solved my problem by abandoning the sitemaps directory and using the site’s home directory. Now I am going to do what Arne has asked and try out the new beta version and see how it goes.

Frederick, I have exactly the same problem. With disk basic caching it works, but with enhanced it crashes the site with a 500 internal server error. I will send you a support config and bug report asap.

Got a question. Where can I find “Cache Control policy” explained and how to choose/select the appropriate option?

By the way, I much prefer the new interface in this version. Much more logical, and I like the “Performance” touch… 8^)

@modemlooper… Thanks for that. I had checked that but something else must have been snagging one or other hooks because now its working fine. That just leaves me with two questions. How/where do I get rid of the 1px gray vertical line top to bottom of the standard page sidebar? Is that BuddyPress default theme territory? And secondly, how/where do I adjust the column widths in the default page(s)? When I have done those two things, I think Virtual Crowds is ready to take its place amongst the some of spiffiest of the spiffymost on the web, thanks to you.

Looks like the modemlooper left da house!

I have exactly the same problem trying to get W3TC to work with CDN at VPS.NET as you know Frederick. Is there something you can see that might be common to all of us having this problem?

What does a “stock” php configuration look like Frederick?