I have had an Omeka installation active on a shared Bluehost server for the last 5 years, but when I upgraded to a Virtual Private Server account over the weekend, the URL to the site stopped working and instead generated the "Omeka has Encountered an Error" screen.
All of the files and the database were intact, so I backed everything up, uploaded a brand new installation, copied over the appropriate files, and it worked... until I changed the directory name back to what it is supposed to be.
I cannot get a detailed error report to come up even after altering the .htaccess file per the codex instructions. Do you have any idea what might be causing this? The site works if I call the directory anything else, but I really need it to be the same as it was because I don't want my users to have to find a new URL.
My first guess is that some server configuration might be different for that specific directory name. Maybe something like Apache's
mod_rewrite module not being enabled for it. That might explain why changes to .htaccess to show the errors are not working as expected.
I'm not sure I'm going to be able to figure that out though. Any chance you could give me some instructions on how to get that enabled?
That would be something on the Bluehost side, if indeed that is the issue. The fact that it seems like it's only a problem in one directory makes me think that's what's happening.
If there was any difference in the code being used in the two directories, that might be another thing.
Nope. It's definitely just the directory. I could name it something else right now and it would work fine.
It's great to have a possible reason for the issue, though. Thanks for your help. I've opened a ticket with Bluehost and I'll ask them about the Apache module you mentioned first.
Bluehost assures me that mod_rewrite is active. Is there anything else that could be causing the issue. I've also discovered that I can rename the directoru, go to wdchumanities.org/dcdm, and it still gives me the "Omeka has encountered and error message.' Even though the directory does not exist anymore.
Well, that makes it all the more mysterious. If the directory doesn't exist, it certainly shouldn't think Omeka is there, unless the server is returning something that has been pretty aggressively cached.
Since it sounds like you have everything, files and database, backed up (always worth double checking you have everything!), you might try starting from scratch: create the directory (dcdm?), make sure that it is completely empty, including 'hidden' dot-files, and upload the files. You should be able to just point db.ini to the existing database.
My guess is that somewhere there is some file that shouldn't be there in the Omeka directory causing problems, so I'm hoping that the clean-slate approach will work. That's a bit of a stab in the dark, though.
You might also press the BH folks to see if there is some other change they might be aware of. Since the problem started during a server change, they might at least be able to list out differences in configuration between what you had before and what you have now. That list might point us in the right direction.
After my first chat with Bluehost, they suggested a full reinstall. The version that is up there now is a full, clean-slate reinstall, with only the plugins, themes, files, and db.ini files being carried over. (I really hope its not something in any of those causing the problem)
The caching issue is something I'd thought might have been the problem. We use a service called Cloud Proxy that acts as a website firewall and also caches pages, but I've had the cache turned off on that for some time now and flushed it several times yesterday and today just to be on the safe side.
I'm talking with a tech from Bluehost now and he says that the upgraded VPS service uses FCGI for php instead of suPHP. I don't know if that makes a difference.
I just took a look at wdchumanities.org/dcdm, and it looks alive! Does that mean that this has been sorted out (fingers crossed!)?