Revo 2.0 Install Nightmares

Greetings,

This comes after two days of trying to get Revolution 2.0 advanced to install properly. At one point I almost had it, but as you’ll see . . . it all fell down. Please cut me a little slack and understand I’ve been digging through your documentation and have tried every suggested fix posted, and then some, if I leave something out, apologies in advance.

Apache/1.3.42
PHP/5.2.14, safe_mode off, PDO sqlite, sqlite2, mysql
GD (2.0.34 compatible)
Freetype 2.1.9
mySQL 4.1.22
cPanel 11

And of course Revo 2.0. Have my feet wet with Evo but the client wanted the latest so in I went. Server (at least this domain) is a clean slate, no files to worry about losing.

I’m stuck behind web interfaces and have no root access, this is not a shared server, it’s a managed dedi but only have access to this site thorough the web interfaces and FTP. Which is part of the problem, as you’ll see. The other part, well, maybe I’m an idiot . . .

Dropped the .zip at domain root, unpacked via cPanel’s file manager (wishing all along I had terminal access) and attempted the install, PDO missing, so had the admin’s install it. Came back, went fine until I got to the file path checks "directory public_html is not writable." Though I felt funny about it, okay, set it to 0777 just to get the install done, still reporting not writable. So I looked into the docs, couldn’t see anything clear about "web context" so created a web-context directory, pointed the web contexts at it, install went fine. (maybe this is where my thinking goes south.)

/home/username/public_html/core
/home/username/public_html/manager
/home/username/public_html/web-context
/home/username/public_html/connectors

First time through, I was able to log in to the manager OK. Awesome, let’s get to it, installed a lot of add ons and one of the site demos. All went well.

But . . . after installing the site demo, I ent to domain root and have a directory listing, no page. I dug around, spent another three hours in the documentation, digging through your code (just looking,) trying to figure out what I was missing. To move on, I put an index.php at root to include /web-context/index.php and lo and behold, it worked. Until I clicked a link ion the page. It logged me out of the manager and sent me to the login screen. Okay . . . logged back in, went to the resource, hit preview. Logged out again. I broke something.

So I spent another 3 hours or so digging through documentation and the manager, and your code, trying to see where I went wrong, then decided to reinstall. This is where things get real fun . . . . After a couple reinstalls without removing anything (except the configs) I get no change in results, so thought I’ try removing files. I can’t remove any files because I’m not the owner. So now I have seven directories named "deleteme1, deleteme2 . . . " that some sysadmin will have a laugh over when I ask hime to remove them.

After losing an entire Saturday, the last install drove me here to beg for help. Managed to get through one more install without kicking the monitor off the desk, and now I’m getting the bounce-back to login screen. I’ve tried the "123456" password fix modifying the DB, deleted cookies, deleted DB sessions, added php_value session.auto_start 0, don’t know about eAccelerator but since it got through the first time I doublt that’s the issue.

I’ve been programming for 17 years, PHP coding for 7, if there’s anything specific you can offer, what code to hunt down, what files and directories to look at, to look at I’d sure appreciate it.

Your fundamental mistake, I think, was assuming that MODx’s stuff was based on physical directories. The "web" context is conceptual, not physical. It’s in the DB and needs no physical directory. It’s also created automatically during the install, so you were going down the wrong road to mess with it. Delete the directory you created for it. I’m not sure where you set paths to that directory, but it’s also unnecessary and could be part of your problem. MODx uses the index.php file in the root as a kind of dispatcher for every request on the site, so it’s critical that you leave it alone.

I’m assuming that your MODx install is not in a subdirectory. There are four config.core.php files that tell MODx where to look for things. One in the root, one in /setup, one in Manager (iirc) and one in /processors. They should all point to yoursite.com/core/, unless you moved and/or renamed the core during the install. If so, they should point to the new name/location. Also, check also the stuff at the top of /core/config/config.inc.php to make sure it’s correct as well.

If you tried to move the core during the install, there was a bug that prevented it from actually moving the files (don’t know if that’s been fixed, but I don’t think so). So if you tried to move the core, the config.core.php files may have been set, but if the actual core directory hasn’t moved, those files are pointing at nothing.

Hope this makes sense. It’s been a really long day.

All in all, you may be better off just deleting everything, dropping all the tables in the DB, and starting over -- leaving all files in their default locations, for now.

Bob, thank you - and yours was one of the sites I’ve been to attempting to get this to work.

All in all, you may be better off just deleting everything, dropping all the tables in the DB, and starting over -- leaving all files in their default locations, for now.

Will do, and have done, that several times (okay, ten times, specifically.) As mentioned, this may be part of the problem, I can’t delete some of the directories created by modX install. I’ve been renaming them on each attempt - however, I’ve solved this *part* by brute force, wrote a script to do the deleting.

MODx uses the index.php file in the root as a kind of dispatcher for every request on the site, so it’s critical that you leave it alone.

Now here’s something, this may be (hoping) it. I had a blank domain, there was no index.php When I run the setup, I get / and /home/username/public_html/ for web context, the check page says /public_html is not writable, even though I’ve (temporarily) set public_html to 0777. Hence going down the web-context road. I will place an empty index.php at root, make it writable for the install, see if that fixes it.

Other notes for clarification . . .

’m assuming that your MODx install is not in a subdirectory.

Starting with the install, I have

/home/username/public_html/core
/home/username/public_html/setup
/home/username/public_html/manager (rwx all)
/home/username/public_html/connectors (rwx all)

There are four config.core.php files that tell MODx where to look for things.

I found two, but if the writable index.php doesn’t fix it, I will check all four.

If you tried to move the core during the install...

Did try this once per the docs, placing the files off-root. Also failed (I could move them before setup, but once setup is run, no permissions to delete, but as said, solved.)

Thanks again for your time, every little bit helps.

Rats.

Checking if /home/username/public_html/ directory is writable: Failed!

Perms set to 0777 on a blank index.php, same on public_html. I think it’s a matter of ownership, and can’t issue any chown’s, even temporarily.

Maybe I can go with a directory and add a mod rewrite? !d and !f /somedirectory/index.php


I’m stumped.

Maybe your host is using suPHP or suExec. In that case the permissions need to be 755 for folders and 644 for files.

Apparently not, that now fails on the manager and connector directories.

Just went through all the documentation again (almost know it by heart now) and it just appears that modX won’t be able to write to public_html. What’s a possible workaround? My rewrite idea and an empty directory? Or a manager/manager directory for admin, with the web context php inside manager?

<editing to avoid post spams> OR . . . create a temporary "web-context" directory, get past the install, them move everything from within web-context to domain root, then mod all the config files. That’s one thing I haven’t tried yet.

SOLVED!

For anyone who’s hosting setup will not allow PHP to write to the public_html root, I think this may be a workaround and it’s not that complex. What *really* bites is I was this close->||<-- to it in the previous ten tries. AGH! :-P Anyway, the previous scenario works:

- Create a temporary directory for web context, I used "web-context." Chmod 0777
- Run the install. Be sure to add the web context path to the path and URL.
/home/username/public_html/web-context/
/web-context/

Don’t forget the trailing slash or you’ll get a directory web-contextassets. (Had that one too.)

- After the install, MOVE or duplicate the directories in web-context at root. At this point it’s just
/assets/components
/assets
- Optionally: I didn’t feel comfortable with the config file at root (someone inexperienced may futz it up) so moved it into assets. This required a small change to index.php:

#@include(dirname(__FILE__) . ’/config.core.php’);
@include($_SERVER[’DOCUMENT_ROOT’] . ’/assets/config.core.php’);

- mod /core/config/config.inc.php, change MODX_BASE_PATH/URL to /home/username/public_html/ and /, change MODX_ASSETS_PATH/URL to /home/username/public_html/assets and /assets. The config.core files are already pointing to /core, no changes needed.

Logs in fine. Page loads fine. I’m *pretty sure* assets may need to be writable for file uploads, maybe not (will cross that bridge when I get to it.) I Think this one’s fixed. I still have to see if I have the "link" problem I had, off to install all the modules and sample site.

I’m glad you got it sorted. Personally, I wouldn’t be on a host that didn’t allow me to write to public_html. Have you asked the host about this? Maybe it could be changed. Also, the problem may be with the ownership of the public_html directory rather than its permissions. I’ve never been on a host with this problem so I don’t know how to solve that, but someone else may chime in. If the host has put a php.ini file in public_html, you might take a look at it.

As for the config file, I’d advise against rewriting index.php. It may be overwritten when you upgrade (or even just run an upgrade install to straighten things out). That’s a lot more likely than someone messing it up and you might not remember why things have gone south after the upgrade some time in the future. Almost anyone would know better than to rewrite a config file and you could always make it read-only.

Final follow up, installed most of the modules we need, demo site installed and good to go, definately solved and working as expected. Personally I like the old graphic interface better but there are some awesome improvements in the overall functioning . . . stellar job.

Personally, I wouldn’t be on a host that didn’t allow me to write to public_html.

To clarify, *I* (user) have no problem writing to the domain root (public_html) It just appears that PHP cannot. Or at the very least, the setup program is interpreting it that way (don’t want to use the word bug. )It’s a situation I’m pretty familiar with and makes sense, if "any user" can write to domain root it’s a bit of a security hole.

Also, the problem may be with the ownership of the public_html directory rather than its permissions.

Agreed, I’m able to change mode on it but it had no effect. Also explains the inability to delete directories setup had created when I could write a PHP script to delete them.

I’d advise against rewriting index.php.

Okay . . . makes sense, will move config.inc.php back to domain root.

Glad you got it working. Thanks for reporting back.