Multi-App Frequently Asked Questions

How do I specify prefs once for multiple apps, or multiple copies of an app?
I'm on GoDaddy, and I get a "page not found" error for my CGI scripts.
I'm getting a message saying: an error occurred while processing this directive.
I'm getting an error like: virtual() ... Unable to include script.cgi ... request execution failed.
I'm getting an error saying: exec() has been disabled for security reasons.
I'm getting an error saying: Can't execute code from a freed script.
I tried to execute the CGI script from the command prompt and it didn't work.
When I embed the app into my existing page, it loads slowly.
My server's CGI module is outdated.

How do I specify prefs once for multiple apps, or multiple copies of an app?

As a special case, an app configured for UserBase integration will automatically read the userbase_prefs.cgi file for the necessary prefs, including the database prefs.

But in general, to share prefs between multiple copies of a single app, you can create a new prefs file called appname_shared_prefs___overrideable.cgi and/or appname_shared_prefs___nonoverrideable.cgi, where "appname" is "filechucker", or "userbase", etc.  Overrideable prefs will be overridden if the same pref is specified in the appname_prefs.cgi file; non-overrideable prefs will not.

To share prefs between different apps, you can create new files named encodable_shared_prefs___overrideable.cgi and/or encodable_shared_prefs___nonoverrideable.cgi. 

Each app will search for these prefs files in its own directory, as well as any top-level directory named "cgi-bin" or "cgi", and also in the parent folder of its own directory.

[ Top ]

I'm on GoDaddy, and I get a "page not found" error for my CGI scripts.

...or the script is displayed as a text file, not executed.

GoDaddy does screwy things with their servers in terms of Perl/CGI setup.  But it's usually easy to fix.  First, try renaming your "cgi-bin" folder to just "cgi" -- you may even have a folder by that name already.  If that doesn't fix it, try renaming the folder to something totally different like "apps".

In some cases, the problem is that GoDaddy has failed to enable CGI execution on the server or on your account.  To fix that, you just need to send them a support ticket and ask them to enable CGI execution for your website.

[ Top ]

I'm getting a message saying: an error occurred while processing this directive.

This can occur when trying to call a CGI script from an SHTML file, such as www.yoursite.com/upload/index.shtml (or the shortcut version of that same address which is simply www.yoursite.com/upload/).  That index.shtml file by default contains a reference to /cgi-bin/filechucker.cgi, or whichever other CGI script you're trying to use.  And this error message means that there was a problem while trying to execute that CGI script.

There are 2 common causes for this error.  The first is that there is a problem with the CGI script itself; if the script is not installed properly or is not working properly, then calling it from a shortcut URL (via the SHTML file) is not going to work either.  So you need to try visiting the CGI script directly (www.yoursite.com/cgi-bin/filechucker.cgi for example) and fix any errors that occur there.  (You may get an "Internal Server Error" from the direct CGI URL; this page will help with that.)  Once the CGI script itself is working properly, you can then try to get the shortcut /upload/ URL working.

The second common cause is simply having the wrong path to the CGI script inside the SHTML file.  For example, if your server requires you to use a .pl extension instead of a .cgi extension, and therefore you've renamed the script from filechucker.cgi to filechucker.pl, then the line inside the SHTML file which references "/cgi-bin/filechucker.cgi" will need to be changed so it points to filechucker.pl instead.  Likewise if you've put your CGI script in some other folder besides cgi-bin then you'll need to adjust that path in the SHTML file so it's pointing to where the CGI script is actually at.

[ Top ]

I'm getting an error like: virtual() ... Unable to include script.cgi ... request execution failed.

This can occur when trying to call a CGI script from a PHP file, such as www.yoursite.com/upload/index.php (or the shortcut version of that same address which is simply www.yoursite.com/upload/).  That index.php file by default contains a reference to /cgi-bin/filechucker.cgi, or whichever other CGI script you're trying to use.  And this error message means that there was a problem while trying to execute that CGI script.

There are 2 common causes for this error.  The first is that there is a problem with the CGI script itself; if the script is not installed properly or is not working properly, then calling it from a shortcut URL (via the PHP file) is not going to work either.  So you need to try visiting the CGI script directly (www.yoursite.com/cgi-bin/filechucker.cgi for example) and fix any errors that occur there.  (You may get an "Internal Server Error" from the direct CGI URL; this page will help with that.)  Once the CGI script itself is working properly, you can then try to get the shortcut /upload/ URL working.

The second common cause is simply having the wrong path to the CGI script inside the PHP file.  For example, if your server requires you to use a .pl extension instead of a .cgi extension, and therefore you've renamed the script from filechucker.cgi to filechucker.pl, then the line inside the PHP file which references "/cgi-bin/filechucker.cgi" will need to be changed so it points to filechucker.pl instead.  Likewise if you've put your CGI script in some other folder besides cgi-bin then you'll need to adjust that path in the PHP file so it's pointing to where the CGI script is actually at.

[ Top ]

I'm getting an error saying: exec() has been disabled for security reasons.

This is a PHP error, and it can occur when trying to call a CGI script from within a PHP page (for example, calling userbase.cgi from within ubprotect.php).  This is often caused by the server's PHP configuration having so-called "safe mode" enabled.  The solution is to disable "safe mode", because it's not safe, it never was safe, and it causes problems for many web applications.  Even PHP's creators acknowledge this; they have completely removed the "safe mode" feature from new versions of PHP:

And:

[ Top ]

I'm getting an error saying: Can't execute code from a freed script.

This appears to be an Internet Explorer bug.  It can happen if your page has a <meta> tag which comes after a <script> tag.  The workaround is to move all <meta> tags up, so they come before any <script> tags.

[ Top ]

I tried to execute the CGI script from the command prompt and it didn't work.

That's correct.  You can't execute a website-based CGI script from a command prompt.  Web applications are not the same as desktop applications; they require a proper server environment in order to execute, and this environment is not present when you use a shell or command prompt to execute them.  If you try, you'll probably get errors, and these errors usually don't tell you anything useful since they are caused by being executed incorrectly.

[ Top ]

When I embed the app into my existing page, it loads slowly.

When you embed, say, FileChucker into an existing page on your site, you need to add the following lines to your page's head section:

Then you need a third call to the CGI script in the middle of your page, where you want the app's output to appear.  On slower servers, having 3 separate calls to the CGI script can slow the page down.  To make it faster, you can reduce that to just 1 call, by replacing the ?css and ?js calls with static files.

To do that, visit (for FileChucker) www.yoursite.com/cgi-bin/filechucker.cgi?css in your browser.  You'll see a bunch of text which is the app's CSS.  Copy and paste all of that text into a file on your computer, say filechucker.css.  Do the same thing for the ?js output; save it as filechucker.js.  Then upload filechucker.css and filechucker.js to your website's top level.  Finally, in your page's head section, replace those ?css and ?js lines with these new versions:

[ Top ]

My server's CGI module is outdated.

For Perl-based web applications, the CGI Perl module (CGI.pm) is very important.  Using an outdated version of this module can result in problems, such as failed uploads.  For FileChucker in particular, using CGI.pm version 3.02 or older will often cause problems; that version is ancient (at least 5 years old now) and contains many bugs.

To determine your server's CGI version, you can install FileChucker, then go to its Login > Administration > Server Information page.  Or, you can download and install this server information script.

The CGI module usually comes with Perl itself, so the best way to update it is to update your Perl installation; if your CGI is old and outdated then your Perl probably is too.  But depending on your server and your Perl version, you may be able to install a newer CGI.pm without doing a full Perl update.  If your CGI version is very old, then the very newest version may be incompatible with the rest of your Perl installation.  So if you want to try updating just your CGI module, you should try a newer-but-not-too-new version, like 3.15.  (Even version 3.03, while still old, is known to have fixed many of the significant bugs in previous versions, and it works well with FileChucker.)

Download CGI.pm v3.15 and unzip it.  You'll get a bunch of files, one of which is called "CGI.pm".  On your server, go to the folder where your CGI scripts are installed (usually the cgi-bin folder) and create a new subfolder called "perlmodules" (cgi-bin/perlmodules/).  Upload the CGI.pm file into that perlmodules folder.  Encodable apps like FileChucker will detect and use this new version automatically; for other CGI scripts, just add a new line which says   use lib './perlmodules';   near the top of the script.

Now FileChucker's Server Information page should show the updated version number for the CGI module.  If you get errors, you might try taking the CGI folder from the zip file and uploading that into the perlmodules folder on your server as well.

[ Top ]