Error 500: Internal Server Error on doc after upgrade to 0.9

[thetitan]

I went through a successful upgrade from 0.8 to 0.9 . But when I try to edit my documents I am unable to, I receive "Error 500: Internal Server Error".

I am able to create and edit new documents, but I am unable to edit documents I have created in version 0.8

No changes in file or folder permissions on the server.

*EDIT*
I have looked at my server's error log and I see the following whenever I try to view or edit an old doc:

PHP Notice:  Use of undefined constant LUCENE_SEARCH - assumed 'LUCENE_SEARCH' in /home/<snip>/public_html/init.php on line 19, referer: http://opengoo.dom.tld/
PHP Fatal error:  Uncaught exception 'InvalidParamError' with message 'There is no session matching this name (null for default session): NULL' in /home/<snip>/public_html/environment/classes/logger/Logger.class.php:83\nStack trace:\n#0 /home/<snip>/public_html/init.php(156): Logger::log(Object(FileNotInRepositoryError), 4)\n#1 /home/<snip>/public_html/index.php(9): require('/home/tfnet/dom...')\n#2 {main}\n  thrown in /home/<snip>/public_html/environment/classes/logger/Logger.class.php on line 83, referer: http://opengoo.dom.tld/

[ignacio]

Hi titan.

Please, try setting DEBUG to true in config/config.php and see what comes out in cache/log.php.

Thanks.

[thetitan]

here is the debug report

Error (FileNotInRepositoryError)

File 'a23dbb550e5e637047ce9b3202c82231d9276a53' can not be found in the repository
Error params:
File:    /home/<snip>/public_html/library/filerepository/backend/FileRepository_Backend_FileSystem.class.php
Line:    68
File ID:    a23dbb550e5e637047ce9b3202c82231d9276a53
Backtrace:
#0 /home/<snip>/public_html/library/filerepository/FileRepository.class.php(58): FileRepository_Backend_FileSystem->getFileContent('a23dbb550e5e637...')
#1 /home/<snip>/public_html/application/models/project_file_revisions/ProjectFileRevision.class.php(97): FileRepository::getFileContent('a23dbb550e5e637...')
#2 /home/<snip>/public_html/application/models/project_files/ProjectFile.class.php(272): ProjectFileRevision->getFileContent()
#3 /home/<snip>/public_html/application/views/files/add_document.php(57): ProjectFile->getFileContent()
#4 /home/<snip>/public_html/environment/classes/template/Template.class.php(74): include('/home/<snip>...')
#5 /home/<snip>/public_html/environment/classes/template/Template.class.php(46): Template->includeTemplate('/home/<snip>...')
#6 /home/<snip>/public_html/environment/classes/template/template.php(35): Template->fetch('/home/<snip>...')
#7 /home/<snip>/public_html/environment/classes/controller/PageController.class.php(111): tpl_fetch('/home/<snip>...')
#8 /home/<snip>/public_html/environment/classes/Env.class.php(124): PageController->getContent()
#9 /home/<snip>/public_html/init.php(150): Env::executeAction('files', 'add_document')
#10 /home/<snip>/public_html/index.php(9): require('/home/<snip>...')
#11 {main}
Autoglobal varibles:
$_GET:    Array (
  ['ajax'] => (string) 'true'
  ['active_project'] => (string) '8'
  ['c'] => (string) 'files'
  ['a'] => (string) 'add_document'
  ['id'] => (string) '13'
  ['current'] => (string) 'documents-panel'
)
$_POST:    
$_COOKIE:    Array (
  ['__qca'] => (string) '1223905296-45352120-64240590'
  ['__qcb'] => (string) '1132465338'
  ['PHPSESSID'] => (string) 'd9a3eafvk9bb0s5d3n5u89sm46'
  ['id'] => (string) '1'
  ['token'] => (string) '679371e5215962c90e2a8cf8fcc63ef3cf05f3bd'
)
$_SESSION:    Array (
  ['cal_version'] => true
  ['cal_month'] => (string) '10'
  ['cal_year'] => (string) '2008'
  ['cal_day'] => (string) '13'
)
Execution time:
Total execution time: 0.24788808822632 seconds

looks like there is a problem with the back up I used. Looks like I will have to manually add the content to new files. What's the easiest way to clean the old file names?

[ignacio]

When you are using the Filesystem as the backend for saving your documents, the content of your documents is stored in the upload folder, so you should backup that folder too. Also, when you change the backend you can't access all files you saved with the other backend. We'll have to do something about it, but currently that's how it woks .

In order to delete those broken files you would have to manually delete them from the database. This following queries would delete all files from OpenGoo.

Code: [Select]

DELETE from `og_project_files`;
DELETE from `og_project_file_revisions`;
If there are files that do work and you don't want to delete you would have to add a WHERE condition specifying only the files you want to delete:

Code: [Select]

DELETE from `og_project_files` WHERE `id` IN (1, 2, 4, 6);
DELETE from `og_project_file_revisions` WHERE ``file_id` IN (1, 2, 4, 6);
You can get the file ids with this query:

Code: [Select]

SELECT `filename`, `id` FROM `og_project_files`

[thetitan]

I know about the filesystem and the upload directory. My uploads directory and its contents are preserved and I am able to view the content of all the files I had in it.

I decided to go with the filesystem because I thought that OpenGoo will store everything in a flat format, but looks like it does not. It looks like only the actual content of the file is stored in a file and the rest of the document relevant information is stored partially in the DB and partially in a reference file, which I did not back up prior to the upgrade. I figured that OpenGoo will parse the directory and because nothing was encrypted it will simply open the files.

I will change the storage system to the DB and manually recreate my files and repost the content from my documents. On a side note, when using the DB is any of the documents information stored in a file or does everything go in the DB?

[cabeza]

When using DB storage, avatars are still stored on the file system.
Marcos

[thetitan]

if that's the case, the team has to change the description by the storage dropdown

File storage:
Select where you want to store attachments, avatars, logos and any other uploaded documents. Database storage engine is recommended.<strong>Switching storage will make all previuosly uploaded files unavailable </strong>.

[cabeza]

Will do.
Thanks!