Yet another blank Manager problem

Hi there,
I've search the rest and haven't found anything like what I'm experiencing, so hopefully I can get some help. Here's what happened:

1. Installed the latest version of Revo successfully, built simple site (5 pages, FormIT, Wayfinder, TinyMCE)
   
2. Gave edit access to another user, user edited pages successfully
   
3. I changed the template slightly, the change propagated across all pages except one
   
4. Tried to clear cache through manager, it just said "Console is running" or similar, but didn't actually do anything
   
5. Manually emptied the core/cache folder
   
6. Page now updated, everything is fine EXCEPT
   
7. Manager now not accessible. Completely blank page when I go to the Manager URL. Core/Cache remains empty, despite refreshing site page and manager page repeatedly.

Things I've tried:
Confirming the paths are correct and not corrupted in all three config files. Fiddling with js and css compress settings in db. Trying the manager link in Chrome/Firefox and in private window (to exclude issues with cookies/caching).

What else can I try? Is there any error log maintained that I can get more info on what's happening? Many thanks in advance for your suggestions.

Apache version 2.2.27
PHP version 5.3.28
MySQL version 5.1.73-cll
Architecture i686
Operating system linux

Are you seeing the Manager login page?

Have you tried repairing all tables in PhpMyAdmin?

Thanks - Just tried repairing all tables, completed successfully with no change. No login page - just a blank white page. Empty source.

I should add I'm using ModX 2.2.14-pl and that I've double-checked the permissions on the cache folder are 755. I find it most bizarre that this folder remains empty despite refreshing the site pages (which all work fine) and the manager (which remains blank)!

Can you access the server's PHP error log? Or the web server's access log?

Oh good idea! Here's what I see below. Why can't it make that dir?

[Wed Apr 16 13:09:54 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//dff9972ba91065f7ffb060af3479b3b5
[Wed Apr 16 13:09:54 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:09:54 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//db08533834b22a850d2a76c183fa8c9e
[Wed Apr 16 13:09:54 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:09:07 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//dff9972ba91065f7ffb060af3479b3b5
[Wed Apr 16 13:09:07 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:09:07 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//db08533834b22a850d2a76c183fa8c9e
[Wed Apr 16 13:09:07 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:06:20 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//dff9972ba91065f7ffb060af3479b3b5
[Wed Apr 16 13:06:20 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:06:20 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//db08533834b22a850d2a76c183fa8c9e
[Wed Apr 16 13:06:19 2014] [error] [client xxx.xxx.xxx.xxx] Cache couldn't make dir '/home/<path>/public_html/core/cache/rss/'.
[Wed Apr 16 13:03:36 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//dff9972ba91065f7ffb060af3479b3b5
[Wed Apr 16 13:03:36 2014] [error] [client xxx.xxx.xxx.xxx] Cache unable to open file for writing: /home/<path>/public_html/core/cache/rss//db08533834b22a850d2a76c183fa8c9e

Access log seems normal though:

xxx.xxx.xxx.xxx - - [16/Apr/2014:14:56:13 +1000] "GET /manager/ HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0"

So it appears to be something to do with permissions. I've changed the cache folder to 777 and everything works perfectly. Change back to 755 and things go wrong again. Permissions/ownership isn't my forte and I have no idea how to go about fixing this. Leaving it at 777 gets me out of trouble short term, but obviously I don't want to leave it like that. Any suggestions would be most appreciated!

It all depends on the server configuration. Normally, PHP files (whatever.php, in our case index.php) are run as the web server user, since it's the web server that triggers the PHP processing. So that means that the web server user must be able to write to your files - you being the user that uploaded MODX in the first place. That usually means 777 for directories, and 666 for files - everybody has to be able to write to them. Of course, this isn't the most secure way to run a web server, so we only want to have the files and directories that MODX will need to write to to have these permissions.

Some servers are configured to use some form of suexec - Switch User EXECute. They automatically switch the user from the web server user to the owner of the .php file being run (our index.php file). This means that with 755 and 644 permissions MODX can write to the files and directories we created when we uploaded MODX.

I have for many years now simply refused to work with a host that doesn't use suPHP or CGI/FastCGI with suexec.

If you can't run php in CGI - modus, you should create all directories, where php needs to have write-access, by php not by ftp.

You can do so from MODX - filemanager.

But than you will have issues uploading/editing that files by ftp.