Does anyone know why the install process would quietly die ("connection was reset") with the following error in the Apache log file:
[Thu Dec 30 15:37:05 2010] [error] [client 127.0.0.1] PHP Catchable fatal error: Argument 1 passed to Omeka_Core_Resource_Options::_convertMigrationSchema() must be an array, null given, called in C:\\Program Files\\Apache Software Foundation\\Apache2.2\\htdocs\\omeka-1.3\\application\\libraries\\Omeka\\Core\\Resource\\Options.php on line 49 and defined in C:\\Program Files\\Apache Software Foundation\\Apache2.2\\htdocs\\omeka-1.3\\application\\libraries\\Omeka\\Core\\Resource\\Options.php on line 79
That section of code looks as though it is looking to do a version upgrade but I am unsure why that would matter on a fresh install. This happens right after 4 omeka-* tables are created and populated, so I suspect this is not a database configuration issue.
FireFox 3.6.8
Windows 7
localhost install (yeah, I know) using 127.0.0.1
Apache/2.2.16 (Win32)
PHP/5.2.14
MySQL 5.1.51-community
Rick
Further update...
Previous install was a fresh install of omeka-1.3 with no previous version being installed before.
A new install of omeka-1.2.1 also quietly fails with almost no error in the Apache error logs:
[Thu Dec 30 16:26:14 2010] [notice] Parent: child process exited with status 255 -- Restarting.
In both cases the connection reset browser error is shown after the initial install configuration screen form is submitted.
Rick
Omeka runs on a Linux server. Instructions for running a VMWare virtual machine are on the bottom of the Preparing to Install Page. http://omeka.org/codex/Preparing_to_Install
Aodiorne,
I am aware that Omeka (preferably) runs on LINUX, however, my task right now is to explore the feasibility of using Omeka on a Win32 server.
If it can't be made to work on a Win32 server, then we can consider other platform options. Until then, I need to see if this can be made to work somehow.
Further update...
I've finally made it completely through the install process on a Win32 system and it seems most of my install problems were related to execution of 2 of the SQL files. Specifically the "item_types.sql" and "elements.sql" SQL files located in the [webroot]\omeka-1.3\application\core\schema\ folder. For some reason each of those files partially load, then cause the installer to quit unexpectedly (control chars issue???).
To get around the problem I manually loaded both files via SQLyog and renamed to tables to the expected prefix before the install. Next, I edited the "Schema.php" file located in the [webroot]\omeka-1.3\application\models\Installer\Task\ folder to comment out the 'item_types' and 'elements' items in the Installer_Task_Schema class (lines 26 and 31). After that, run the install process as you normally would (using a host of 127.0.0.1 rather than localhost).
Now to figure out how to resolve the CSS path issue.
Further update...
Found the CSS path issue. You need to edit the "AssetFunctions.php" located in the [webroot]\omeka-1.3\application\helpers\ folder. Change line 204 from
$file = $dir.DIRECTORY_SEPARATOR.$file;
to
$file = $dir.'/'.$file;
That will resolve the issue of the CSS not loading on Windows servers due to an incorrect path.
Yes, you're right, that is a bug.
That path gets used basically untouched to create a URI, so we can't use DIRECTORY_SEPARATOR there.
Since this thread's been externally linked to as of late, an update:
- The issue with the incorrect CSS paths is fixed.
- The issue with the installer crashing is caused by a bug in the Zend Framework which can cause long queries to crash PHP on Windows. There's not much we can do about this one.