(Resolved for Revo beta-4 ) - Installation of Revo SVN does not complete

OK, so I finally got tired of Windows shenanigans and moved to linux. I have been trying to install SVN Revo on my machine for the past 3 days but the installation does not complete. (btw, SVN Evo and Revo Beta 2 install fine). The install proceeds until the Installation Summary page which tells me "Core installation was successful. Click continue to complete the installation process". Clicking continue does nothing; the page does not reload or load another page.

I have followed these troubleshooting tips:

# Make sure the directories "/[root]", "/core/packages","/core/cache", and "/core/export" are writable. (root will be the actual directory you are installing to.)
# Make sure "/manager", "/connectors" are writable. If installing advanced, this is unnecessary.
# Make sure your php.ini setting sets memory_limit to 128M, and max_execution_time to 120
# Create a blank file "/core/config/config.inc.php" and make it writable.

Here’s what I get in the log and my server environment.

core/cache/logs:

The first log when I press continue has this entry:



All subsequent clicks on continue produce this sort of timestamp:



Server environment:

apache 2.2
php 5.3
mysql 5.1.37
pdo_mysql - enabled
suhosin - not installed
Linux Mint 7 Gloria - x64 Edition \n \l (ubuntu)
permissions - ok

I know mysql 5.1x is not yet supported but I have been testing Revo on such a configuration to possibly pre-empt bugs in future releases (plus I like latest stuff ). Btw, this setup worked fine in Windows. Many thanks.

cheers/k

First, which Revo branch are you getting from SVN?

Second, in my experience, this behavior occurs when the cache directory (or a subfolder/file within it) is not writable. Double-check...

Hi,

I am getting Revo branch 2.0 (from here http://svn.modxcms.com/svn/tattoo/tattoo/branches/2.0/). The revision I attempted to install is 5669 (18.08.2009).

The cache directory and all its content are all world writable. Browser is FF 3.0, btw). Thx.

cheers/k

Make sure that your memory limit change "took."

You did run transport.core.php, right?

And you’re not running suPHP?

If it’s not one of those, my guess would be a corrupted download/upload.

Quote from: BobRay at Aug 19, 2009, 05:06 AM

Make sure that your memory limit change "took."

It did

You did run transport.core.php, right?

I did

And you’re not running suPHP?

I’m not

If it’s not one of those, my guess would be a corrupted download/upload.

So I thought, but I’ve done this at least 7 times now thx.

cheers/k

kongondo: I’m not sure where the problem would be, but it’s installing fine here; however, a lot of changes have been made so make sure you are rebuilding the core transport and upgrading. The upgrade is taking longer now BTW, so make sure you are not reaching a time limit. You can also try manually deleting all of the core/cache/ dirs/files as well as truncating the session table. Or are you doing a fresh install?

Jason,

In this instance, I have been doing a complete fresh install - creating a database (utf8_unicode), creating a build.config.php with the correct details (creating from build.config.sample.php) and building the transport core, then running setup. Normally I don’t fresh installs every time if it installs fine; in that case I normally just rebuild and upgrade.

About truncating session tables, it’s something I haven’t done before but will look into it. Let me try and start over with a fresh install using the latest revision and see how that goes. Btw, I am using Eclipse for PHP Developers with the plugin subclipse. I doubt whether the problem is in the transfer though.

cheers/k

Update,

OK, I truncated the session table (found only one session table?). Nothing doin, didn’t work.

Then, I have had a closer look at the tables and I see that modx is not adding the table prefix modx_ . So, all the tables appear as, e.g. access_actions, instead of modx_access_actions. This is for all the tables.

I want to repeat an install to confirm. I have definitely been adding a table prefix. No wonder I am getting the above error?



I definitely don’t have a table by that name.

cheers/k

Quote from: kongondo at Aug 19, 2009, 02:07 PM

Update,

OK, I truncated the session table (found only one session table?). Nothing doin, didn’t work.

Then, I have had a closer look at the tables and I see that modx is not adding the table prefix modx_ . So, all the tables appear as, e.g. [/b]access_actions, instead of [b]modx_access_actions. This is for all the tables. I want to repeat an install to confirm. I have definitely been adding a table prefix.

cheers/k

Are you sure you got all of the latest code in place? Are doing checkouts or exports? The way prefixes definitely changed in a recent commit, but it’s been working flawlessly on upgrades and new installs for me since it was changed, in several environments.

Quote from: OpenGeek at Aug 19, 2009, 02:20 PM

Quote from: kongondo at Aug 19, 2009, 02:07 PM

Update,

OK, I truncated the session table (found only one session table?). Nothing doin, didn’t work.

Then, I have had a closer look at the tables and I see that modx is not adding the table prefix modx_ . So, all the tables appear as, e.g. [/b]access_actions, instead of [b]modx_access_actions. This is for all the tables. I want to repeat an install to confirm. I have definitely been adding a table prefix.

cheers/k

Are you sure you got all of the latest code in place? Are doing checkouts or exports? The way prefixes definitely changed in a recent commit, but it’s been working flawlessly on upgrades and new installs for me since it was changed, in several environments.

I am doing checkouts (checking out to a new project in eclipse)..from here http://svn.modxcms.com/svn/tattoo/tattoo/branches/2.0/ Is that the correct location? Should I be exporting instead?

thx/k

edited