Installation problem: false directory-unwriteable report

Install is halted upon apparently-spurious failure of check for install directory being writeable.

Fresh install of Revolution PL.
* Uploaded modx-2.0.0-pl-advanced.zip to newly-created directory [docroot]/modx
* Unzipped in-situ, producing ./core and ./setup subdirs
* Changed permissions of directories as instructed in "Fresh Installation" page (assuming that where it says "/manager" it means "[docroot]/modx/manager", etc), all to 0777
* Visited /modx/setup
* Went through initial config, database checks, etc, all OK. Left everything default where possible.
* Reached "Installation Summary" page to find "Problems were detected ..." and "Checking if [docroot]/modx/ directory is writable: Failed!"
However I had changed the permissions to 0777 and can’t see how it can be any more writeable than that.

Have tried this several times, in 2 different browsers (including restart-after-timeout), same result. Am baffled.

Have not yet tried installing "Traditional" as I would expect the same issue to arise.

Environment:
Server OS: Linux of some kind (hosting company doesn’t say, don’t know how to check; no console access)
PHP: 5.2.13
MySQL: 5.0.91-community
pdo_mysql: installed (AFAICT)
Other: Hosting company provides cPanel (11.25.0-RELEASE_46156) for general config stuff; used this both to upload/unzip the .zip and to change the directory permissions.

Browsers: Opera 9.27; Chrome 5.0.375.99

Use the traditional distribution.

Thanks, that worked. Is this a known issue, or should I see if I can work out what made the difference?

I’m willing to bet it’s specific to your environment, as we cant replicate any such issues. More than likely your setup is preventing PHP from writing to the base path (which it needs access to write to in the advanced distro).

That was one of my reasons for putting the whole lot in a "modx" subdirectory instead of the docroot. I’ll try again, another level down, and report back.

[later]

OK, tried installing in [docroot]/modxtest/modx, where both levels of subdir had permissions 0777. Worked (at least, passed validation check; didn’t go further).

Then tried installing in [docroot]/modxtest. As before, failed the check initially.
Set permissions for [docroot] to 0777 and it passed. No idea what’s going on here. I understood it to be testing [docroot]/modxtest for writeability, not [docroot].

BTW [docroot] is "/home/myuserid/public_html" - I gather this is a pretty normal shared-host setup.

I had exactly the same issue. Trying out the Revolution advanced install on my local machine, running Ubuntu 10.04.

Followed fjpb’s tip to get it work. In summary:

/var/www/site/web/modx -- writable but reported by the installer as being unwritable.

/var/www/site/web -- changed this to writable and now finally the installer is happy.

This is because the writeability tests are operating on the wrong directories.

The code to check the "web" directory, for example, which lives in setup/includes/checks/modinstalltestadvanced.class.php, invokes a function is_writeable2($webdir) (which lives in the same place but just forwards to a function of the same name in setup/includes/modinstall.class.php). However, the argument is produced by
$webDir = dirname($this->install->settings->get(’context_web_path’));
where the ’context_web_path’ produces, in my case, ’/home/myusername/public_html/modx/’

Calling dirname on this will strip off the final level of directory, leaving the *parent* directory (/home/myusername/public_html) as the one being tested for writeability.

This explains the observed symptoms. I can well believe that testers, with write access allowed to parent directories, failed to find this, but I believe I can justify calling it a bug.

Okay, can you file it in JIRA? http://bugs.modxcms.com/

Done. Now awaiting cursing-out for getting it wrong ...

None going to happen, seems dirname() is double-recursing there when we just want the base path. That can be refactored, and we’ll get it out for 2.0.1.