Review Site User Manual

TROUBLESHOOTING

Adjust Text:  a a a a
« Table of Contents   |   Obtain Review Site »


TROUBLESHOOTING

As Review Site becomes more widely used, and issues are addressed regarding its use in various situations, this page will grow.

My Review Site Links Do Not Work

If, when you click on links on your index page, you get errors displayed instead of functioning web pages, the likely cause is due to a non functioning .htaccess file. Possible solutions to this problem are discussed in the section entitled IS THE .htaccess FILE WORKING?

I see CGI source code when I run Review Site

Presently the back end of Review Site (the administrative part) is meant to be run as a CGI application, so it should be installed into a directory that your web server regards as a "CGI bin". This means that the web server will assume that any request for a .cgi file in such a directory is a request to execute the file as a script, and the generated output is to be sent to the browser. If the directory into which Review Site has been installed is NOT a CGI bin, the web server will regard the HTTP request as one for the content of the file, and you will see Perl source code appear in your browser. Either install the back end portion of Review Site into a CGI bin (e.g. at /cgi-bin/rs/reviewsite), or have your web host convert the directory into a CGI bin.

I get a 500 Internal Server Error

You will get a 500 type error message when your script cannot be executed. There are several possible reasons why this might be the case. If you did not upload your executable Perl scripts as ASCII, then the first line of these scripts (which contain the path to your Perl interpreter) will not be correctly parsed and the web server will not know how to run the program. Another possibility is that the web server does not have sufficient permissions to execute the program (generally after uploading a script you should chmod it to 755 so that the web server has permission to read and execute the script). In this case you will usually get a "Permission denied" type of error message. A final possibility is that the first line of your Perl executable script simply contains the wrong path to your Perl interpreter. In that case, all you need to do is replace it with the correct path. See the Installation Instructions for a fuller discussion of installation-related issues.

I see 'regex' Errors when Adding Items

For fields that are required to have a value when adding a record to the database, oftentimes there is an accompanying regular expression check carried out on the value supplied for that field just prior to adding the record to the database. This check is to ensure that the supplied data is of the right format.

For example, if only an integer expression should be supplied for the field, the regular expression (see the 'regex' option on the column definition page) would be ^\d+$ which means "one or more sequential digits and nothing else between the start ^ and end $ of the string". If your supplied data fails the regular expression check you'll get an error message to that effect. In that case you should change the definition of the column from Not Null = 'Yes' to Not Null = 'No' (i.e. from values are Required to values are Not Required) if you don't always want to be forced to suppply a value for the column in question.

Also you'll either need to delete the regexp altogether, or amend it so that it works for the kind of data you want to add for that column. For instance, if I were to have a column that might or might not have an integer associated with it, it would be an INT column of some length, the value would be Not Null = 'No' and the regex would be ^(\d+|)$ meaning the same as before but "also allow the empty string through" so that if we supply a value it MUST be an integer, but not supplying a value is OK too.

I get a DBI error

There could be a lot of reasons for this, but here are some of the common ones:

  • Error: Exception: Modification of a read-only value attempted at /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/DBI.pm line 279.

    Soln: If you looked at line 279 in the Perl DBI module you would likely see something that looked like this:

    Scalar::Util::weaken(my $test = \"foo");

    Your Perl is complaining because it has an old copy of the class Scalar::Util and the weaken() method is absent. Update the Scalar::Util class and you should be back in action. Ask your web hosting company to do this for you, if necessary.

My Template Modifications Don't Take

If you make a change to your PHP templates and you don't see the expected result, it might be that you have template caching switched on. In that case, if a compiled template has been cached and has not expired, it will be shown. The thing to do would be to look for the misc_page_cache_hrs configuration variable (which you can find of the Configure > Miscellaneous page), and set it to zero, so that a new page is regenerated with each browser request. This variable should always be set to zero when you are developing your site and need to see your modifications instantly.

Smarty also caches compiled versions of its templates. If you need to delete these compiled versions at any time, you can, and they will simply be regenerated. Compiled templates live in this directory:

/rs/reviewsite/my/smarty/compiled
The way the Smarty templates work is that Smarty will cache a compiled version of each template the first time the template is used after having been modified in any way. This caching makes things just a bit more speedy. However, I have seen instances of Review Site deployment where Smarty seems not to be aware of newly made changes to templates, and it continues to serve up the cached version that is no longer valid. If this appears to be happening you can simply delete the cached compiled template.


Next Section: FREQUENTLY ASKED QUESTIONS

« Table of Contents   |   Obtain Review Site »


Copyright © 2008 Random Mouse Software. All Rights Reserved.