Error kernel (3)/Error ocurred using URI: /

Next topic

Author	Message
Greg McAvoy-Jensen	Thursday 18 January 2007 5:23:36 pm I had an ezpublish 3.7 site running under PHP 4.3 and it became unstable--first disallowing logins, then an error like the one below. I had to move the site to my own server so I can use PHP 4.4.4. I followed these instructions (http://ez.no/ezpublish/documentation/configuration/backup_restore/move_to_new_provider) and the upgrade instructions to get me to ezpublish 3.8.0. But I still get none of my content when I visit the site. Instead, I get: Error kernel (3) Object is unavailable The object you requested is not currently available. Possible reasons for this are: * The id or name of the object was misspelled, try changing it. * The object is no longer available on the site Debug output: Timing: Jan 18 2007 17:11:43 Script start Notice: eZMySQLDB::query(0.000 ms) query number per page:0 Jan 18 2007 17:11:43 SET NAMES 'latin1' Timing: Jan 18 2007 17:11:43 Module start 'content' Error: error/view.php Jan 18 2007 17:11:43 Error ocurred using URI: / Timing: Jan 18 2007 17:11:43 Module end 'error' Timing: Jan 18 2007 17:11:43 End Do I need to have www-data own everything, not just /var? Any suggestions? Thanks! Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog
Greg McAvoy-Jensen	Saturday 20 January 2007 12:38:29 am Ok, I think this error occurred because I thought the instructions for moving to a new provider (see above) meant that in this command: shell> mysql database < dump_file.sql "database" should be the name of the database you created in the fresh install. I think instead, after creating the new install, the dump file should be sent to a blank database, and the siteaccesses should then point to the new database as well. Granite Horizon, Certified Developer of eZ Publish Web Solutions Provider of the SaaS Solution Granite Horizon In The Cloud \| http://granitehorizon.com/cloud http://granitehorizon.com \| +1 916 647 6350 \| California USA \| @granitegreg Blog: http://granitehorizon.com/blog

Author

Message

Thursday 18 January 2007 5:23:36 pm

I had an ezpublish 3.7 site running under PHP 4.3 and it became unstable--first disallowing logins, then an error like the one below. I had to move the site to my own server so I can use PHP 4.4.4. I followed these instructions (http://ez.no/ezpublish/documentation/configuration/backup_restore/move_to_new_provider) and the upgrade instructions to get me to ezpublish 3.8.0. But I still get none of my content when I visit the site. Instead, I get:

Error kernel (3)
Object is unavailable

The object you requested is not currently available.

Possible reasons for this are:

    * The id or name of the object was misspelled, try changing it.
    * The object is no longer available on the site

Debug output:

Timing:  	Jan 18 2007 17:11:43
Script start
Notice: eZMySQLDB::query(0.000 ms) query number per page:0 	Jan 18 2007 17:11:43
SET NAMES 'latin1'
Timing: 	Jan 18 2007 17:11:43
Module start 'content'
Error: error/view.php 	Jan 18 2007 17:11:43
Error ocurred using URI: /
Timing: 	Jan 18 2007 17:11:43
Module end 'error'
Timing: 	Jan 18 2007 17:11:43
End

Do I need to have www-data own everything, not just /var? Any suggestions? Thanks!

Granite Horizon, Certified Developer of eZ Publish Web Solutions
Provider of the SaaS Solution Granite Horizon In The Cloud | http://granitehorizon.com/cloud
http://granitehorizon.com | +1 916 647 6350 | California USA | @granitegreg
Blog: http://granitehorizon.com/blog

Greg McAvoy-Jensen

Saturday 20 January 2007 12:38:29 am

Ok, I think this error occurred because I thought the instructions for moving to a new provider (see above) meant that in this command:

shell> mysql database < dump_file.sql

"database" should be the name of the database you created in the fresh install. I think instead, after creating the new install, the dump file should be sent to a blank database, and the siteaccesses should then point to the new database as well.