[EP-tech] Re: Errors when requesting /id/eprint/$eprintid after 3.3.13 update

Lizz Jennings E.Jennings at bath.ac.uk
Tue Feb 17 17:29:03 GMT 2015

No, it's not just you - I just found and solved the same error about half an hour ago!

If you replace the line 897 with

if( $self->scope == CRUD_SCOPE_DATAOBJ || $self->scope == CRUD_SCOPE_USER_CONTENTS )

that fixed it for me.


Lizz Jennings BA MSc ACLIP MCLIP (Revalidated 2014)
Technical Data Officer
The Library 4.10, University of Bath, Bath, BA2 7AY UK
Ext. 3570 (External 01225 383570)
E.Jennings at bath.ac.uk
Research Data Management: http://www.bath.ac.uk/research/data

-----Original Message-----
From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Gunnar Wolf
Sent: 17 February 2015 17:08
To: eprints-tech at ecs.soton.ac.uk
Subject: [EP-tech] Errors when requesting /id/eprint/$eprintid after 3.3.13 update


I updated my repository to EPrints 3.3.13 on January 28 (two days after the Debian package was made available). I have not realized until now, but since that moment, all URLS of the form http://$myhost/id/eprint/$eprintid generate an "Internal Server Error"
page. As an example, this page works correctly:


But this one fails:


In my error.log file, I get:

    [Tue Feb 17 10:42:43 2015] [error] [client] Can't call method "base_id" on an undefined value at /usr/share/eprints3/perl_lib/EPrints/Apache/CRUD.pm line 897.\n

And yes, I checked my logs, and the first such message occured just after I performed the update. I am attaching a screencapture from the Google Tools for Webmasters showing the number of errors.

This error happens in the content_negotiate_best_plugin function, regardless of what parameters I give to it; it seems to be related to not having a defined database object — The specific line it complains on is:

    if( ( $self->scope == CRUD_SCOPE_DATAOBJ && $self->{database}->base_id ne "subject" ) || $self->scope == CRUD_SCOPE_USER_CONTENTS )

The database connection *is* working, but it might not yet be initialized at this point in the request handling. Besides, either commenting out the check for $self->{database}->base_id or making it conditional on having defined $self->{database} make the problem apparently go away.


1. Does this happen to others, or is it just me?
2. Does my ugly fix break something else?
3. What goes here? :)


More information about the Eprints-tech mailing list