Trying to pin down a server error after site transfer

[Helen]

Hi there - I'm hoping to get some help with an error that's come up after our site was moved to a new server.

We're on a shared hosting package, and our web host had to rather abruptly move our site to a new server at the end of last year. I've since been working through a number of problems this caused (both for our main sites and the archive catalogue), and find myself stuck.

We're using ICA-AtoM version 1.0.9 (as we're on shared hosting, I don't have shell access, and wasn't able to implement the database upgrade to version 1.1 - I'd been meaning to bring that problem to the group, but my priority now is just to get the catalogue working again!)

Our server is Apache version 2.2.23, PHP version 5.3.20 and MySQL version 5.1.66-cll - as far as I know, this is the same as the previous server our site was installed on. There have been discrepancies between the two server set-ups - e.g. the php mbstring extension was initially not enabled, which caused problems with indexing the site - it's since been enabled. I should be able to get our webhosts to make any additional changes to the server setup, but I'm not currently able to identify the source of our problem.

Our installation of ICA-AtoM at http://archive.womenslibrary.org.uk/ produces a generic 'Internal Server Error' page when trying to access the index page. However, I discovered (largely by accident) that I was able to access the site via an error page, and that most of the links on the menu worked, allowing me browse the Archival descriptions, authority records, etc. Since mbstring was enabled, I've been able to search the site for records, but attempting to access individual resources / records results in an internal server error. I'm also not able to access our 'about' page. 

I am able to log in, and access the admin pages including edit pages - I've not attempted to make any edits at this point, because I don't know if the error relates to the database or not. I'm able to reach the 'add' pages for all except the archival descriptions. Logging out results in an internal server error, but returning to one of the working pages shows that the log out worked.

I'm also able to switch between display languages.

Enabling the debug mode in the index.php file doesn't do anything - the index page still displays an internal server error, and the pages I can access don't display any errors.

The error log has a recurring error for the robots.txt file:

Empty module and/or action after parsing the URL "/robots.txt" (/).

(There isn't a robots.txt file in the root directory, but there are robots.txt files in a couple of other locations - I assume it's supposed to redirect to these? If not, I can create a robots.txt file)

There's also a similar error when I access the Import > OAI page:

Empty module and/or action after parsing the URL "/Qubit/web/images/up.gif" (/).

And there's a similar error when it tries to access some images in the theme, e.g.:

Empty module and/or action after parsing the URL "/plugins/sfGWLThemePlugin/images/next.png" (/).

None of these errors correspond to any of the instances of the internal server error. As far as I can tell, none of these files exist in those locations: The only up.gif is in the images folder (no Qubit/web/ ), and sfGWLThemePlugin is our theme folder, but it's missing a few images (they're not visible in the theme, so I guess our designer didn't realise)

Because the 'Empty module and/or action after parsing the URL' errors relate to missing files, I have no idea if this is related to the internal server error or not - any help in pinning this down, or suggestions of other things to try (for example, possible server set-up needs I should check with our hosts), would be greatly appreciated.

thanks,

Helen

[Jesús García Crespo]

Hi Helen,

I think that your problem is related to the URL rewriting configuration. In Apache, URL rewriting is done via mod_rewrite and its directives are located under the Apache configuration directory. However, it's a common practice under shared hosting services to store some of these directives under a file called .htaccess, located in your web root directory.

If you can see that directory under your ICA-AtoM directory, open it and take look at the existing directives. I suspect that you may be able to fix the problem by removing its contents although you may want to try to fix it. You can find the mod_rewrite docs at http://httpd.apache.org/docs/current/mod/mod_rewrite.html.

For your information, the following is the default .htaccess file in ICA-AtoM. Is your .htaccess file looking similar?

<IfModule mod_rewrite.c>

  RewriteEngine On

  # uncomment the following line, if you are having trouble

  # getting no_script_name to work

  # RewriteBase /

  # we skip all files with .something

  #RewriteCond %{REQUEST_URI} \..+$

  #RewriteCond %{REQUEST_URI} !\.html$

  #RewriteRule .* - [L]

  # we check if the .html version is here (caching)

  RewriteRule ^$ index.html [QSA]

  RewriteRule ^([^.]+)$ $1.html [QSA]

  RewriteCond %{REQUEST_FILENAME} !-f

  # no, so we redirect to our front web controller

  RewriteRule ^(.*)$ index.php [QSA,L]

</IfModule>

Let us know how it goes. It may be worth to look into a different hosting solution with shell access and some more flexibility. There are good options out there with economic prices like Dreamhost, OVH, etc...

Regards,

--
You received this message because you are subscribed to the Google Groups "ICA-AtoM Users" group.
To post to this group, send email to ica-ato...@googlegroups.com.
To unsubscribe from this group, send email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/ica-atom-users/-/0cRwFWcyQvQJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jesús García Crespo,
Software Engineer, Artefactual Systems Inc.
http://www.artefactual.com | +1.604.527.2056

[Helen]

Hi Jesús - thanks for getting back to me.

The .htaccess file is pretty much exactly as below, but it has the line:

Options +FollowSymLinks +ExecCGI

at the start, and the "RewriteBase /" line is uncommented. Making changes, or clearing the .htaccess file completely, doesn't seem to make any difference, but I'm aware that I'm pushing the limits of my knowledge here. There had been an additional line at the start: SuPHP_ConfigPath /home/womensli/public_html/php.ini which I removed when checking the .htaccess file against my backups (again, the presence or absence of this line doesn't make a difference to the site).

Our web host just let me know that they're getting an additional error message: Premature end of script headers: index.php - would this correspond to an issue with the .htaccess file?

Unfortunately we don't have any additional budget for IT - we've been pushing the limits of our shared hosting for a while, which is why the site was moved, but it's frustrating that the catalogue wasn't causing problems until they moved it (they're eager enough to offer us a dedicated server, but if we could afford that...)

thanks,

Helen

[Jesús García Crespo]

Hi Helen,

On Thu, Jan 17, 2013 at 4:16 AM, Helen <ad...@womenslibrary.org.uk> wrote:

Our web host just let me know that they're getting an additional error message: Premature end of script headers: index.php - would this correspond to an issue with the .htaccess file?

I think that's due to a problem in the code that we fixed in newer models, so it is better if you upgrade.

Does your data set contain any digital object? I could do the upgrade for you from my local machine but I'd need a SQL dump of your database and a copy of your uploads directory. If so, please don't send any private information to the public list, use my address instead.

[Helen]

Hi Jesús - sorry about the delay in getting back to you. 

Thank you for the offer of help with the upgrade! I'm going to hold off for now, as I've had yet another problem arise with the main part of our site, possibly related to .htaccess, so I'm going to chase them about that before I make any further changes.

If we do go ahead with the upgrade (which I'm hoping to do anyway :), we do have a few digital objects - what's the best way to get that folder to you?

thanks again,

Helen

[Jesús García Crespo]

Hi there

On Tue, Jan 22, 2013 at 6:05 AM, Helen <ad...@womenslibrary.org.uk> wrote:

If we do go ahead with the upgrade (which I'm hoping to do anyway :), we do have a few digital objects - what's the best way to get that folder to you?

Archive it using zip or something similar. If it is less than 10M send it to me by e-mail, otherwise host it somewhere safe. That new service (http://MEGA.co.nz) is giving 50G of free storage space.

I need the SQL dump from your database and the uploads/ directory if you have uploaded any digital object.

[Helen]

Hi Jesús - I've tried installing a fresh version of version 1.3, which worked fine, so I'd like to go ahead with trying an upgrade. I can't see your email to send you the uploads folder and database? 

thanks,

Helen

[Jesús García Crespo]

On Mon, Feb 4, 2013 at 4:22 AM, Helen <ad...@womenslibrary.org.uk> wrote:

Hi Jesús - I've tried installing a fresh version of version 1.3, which worked fine, so I'd like to go ahead with trying an upgrade. I can't see your email to send you the uploads folder and database?

jesus at artefactual dot com 

[Helen]

Thanks! I'll get that sent through.

cheers,

Helen