Multi-App Frequently Asked Questions

How do I install multiple copies of an app?

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

Can I change text strings / translate the app into another language?

What's the best way to upgrade to a newer version of an app?

How can I verify that I've bought a license?

When adjusting the style, how do I know which CSS rules apply?

The CGI script code is displayed as text in my browser.

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.

My website's URL is a subdir on a different domain.

Do you offer free technical support?

How do I install multiple copies of an app?

Just copy the script and its prefs file to new filenames.  For example, if you're starting with filechucker.cgi and filechucker_prefs.cgi, you can copy them to f2.cgi and f2_prefs.cgi, and those will then be a totally separate app.

[ Top ]

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 ]

Can I change text strings / translate the app into another language?

Yes, most of the text strings for the app are contained within the prefs file.  Some are within various individual $PREF settings and templates, and others are within the large group of $TEXT settings (usually near the bottom of the prefs file).  All of these are fully adjustable.

[ Top ]

What's the best way to upgrade to a newer version of an app?

During an upgrade, you'll need to use the new versions of both the CGI script and its prefs file (for example, filechucker.cgi and filechucker_prefs.cgi), because the prefs change as the app changes.  But there are two ways to make the upgrade process easier.

If you haven't yet modified your prefs file, then you can make future upgrades easier by putting all your prefs adjustments into a new file named <appname>_prefs_extra.cgi (for example, filechucker_prefs_extra.cgi).  Simply find whichever prefs you want to change, copy them from the _prefs.cgi file, paste them into the _prefs_extra.cgi file, and then adjust them there.  Then during future upgrades, you can replace your script and prefs file with the new versions, but keep your _prefs_extra.cgi file, so your customizations will remain.

But if you've already modified your prefs file, and now you want to upgrade to a newer version, we can make that easier for you: just send us a copy of your current customized prefs file.  We'll run this against the default copy and then send you the output, so you can easily see just those prefs which you have adjusted, making it easier to re-apply those adjustments to the prefs file from the new version of the app (or better yet, to a _prefs_extra.cgi file, as explained above).

[ Top ]

How can I verify that I've bought a license?

When requesting an app upgrade, you'll need to verify that you have a license for the app in question, by doing one of the following:

• Provide your app license number, which was sent to you in the same email that contained your copy of the app when you bought it.
• Provide the PayPal transaction ID for the payment, which was sent to you via email from PayPal, and is also available in your PayPal account.
• Send us an email from the same email address that made the payment.

[ Top ]

When adjusting the style, how do I know which CSS rules apply?

You can edit the $PREF{css} setting in your prefs file to adjust the app's style.  But there are lots of style rules, so it's not always easy to find the ones that apply to the element that you want to change.  The best thing to do is use a web inspector; there's one built into Google Chrome by default, and there's a Firefox extension called Firebug that you can add.  With such a browser, you can right-click on any part of any webpage and choose "Inspect", which will open a panel at the bottom of the browser window, showing you the HTML code for the element that you clicked, along with all the CSS style rules that apply to it, including which CSS files on the server those rules come from.  You can even adjust the CSS rules right there in your browser, to instantly see how your changes affect the page.  Of course, those changes aren't saved back to the server -- you still need to update the relevant CSS file with your changes -- but they'll last in your browser until you reload the page.

[ Top ]

The CGI script code is displayed as text in my browser.

This means that your server is failing to execute the script, treating it as a plain text file instead.  If you're trying to install the CGI script in some location other than www.yoursite.com/cgi-bin/ then that could be the problem, because some servers won't execute CGI scripts unless they are installed in that exact location.  In some cases, you can enable proper CGI execution by creating a file named .htaccess within the same folder as your CGI script, and putting one or both of the following lines into it:

If that doesn't help, then you'll need to contact your hosting company or server administrator and tell them to enable CGI execution on your website.

[ 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 ublock.php).  This is essentially a PHP configuration error in the server, caused by over-zealous administrators having so-called "safe mode" and other restrictions enabled.  The solution is to disable "safe mode" and enable exec().  The fact is that "safe mode" is 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:

If your hosting company insists on crippling your server by disabling useful features like this, you should probably find a better hosting company.

[ 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.  You don't need to have the very latest version, but it should be from within the past couple of years for best results.  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 ]

My website's URL is a subdir on a different domain.

It's usually possible to work around this, but it's not an ideal setup.  The situation is that, instead of your website being at a URL like http://yoursite.com/, or http://subdomain.yoursite.com/, or even http://some-IP-address/ — all of which could be considered "real" websites — your site is actually at somesite.com/yourdir or maybe somesite.com/~yourdir.  So you don't really have a whole/real website; instead you just have a folder within a different website.

There's really no good reason for using this kind of setup nowadays.  Any decent hosting company will be able to give you a subdomain at the very least (for example, you.somesite.com), and a whole domain in most cases (for example yoursite.com).  Even for test/dev sites, where you may not want/need a dedicated top-level domain name (like yourtestsite.com), your hosting company should be willing and able to give you a subdomain (like yourtest.theirdomain.com) rather than forcing you into a subdir within their test site (like theirdomain.com/~yourtest).

The problem with subdir sites is that the server considers your entire account to be merely a subfolder, rather than a proper website.  Because of this, the server environment variables are incorrect for your "site".  This is not a big deal if your whole site is just a few static pages/images, but it's a problem if you want to use web applications like FileChucker or UserBase.  Web apps rely on the server's env vars to get their bearings and make sure things are set up properly, so when the env vars are wrong, the server is effectively misconfigured.

Fortunately, in most cases, it's possible to work around these problems; it just takes some extra effort to get things working.  The first thing to do is install the Perl server info script.  This will show you your server's environment variables, and you'll want to look for discrepancies between the DOCUMENT_ROOT and the SCRIPT_FILENAME.  On a real website, those variables will match, for example:

But on a subdir site, they'll be different, for example:

So your real docroot is actually /home/yoursite/public_html in this example.  The fix is to set the $ENV{DOCUMENT_ROOT} variable within your script so that it points to the real docroot.  In Encodable apps you can do this by setting $PREF{DOCROOT} (which is near the top of your prefs file) to the real docroot value.

You may also need to tweak other settings in the app's preferences; for example, any settings that deal with URLs may need to have "/~yoursite" added to the start of the URL.

Depending on the server and the app, that may be all it takes.  But if that doesn't get it working, you may also need to edit your script.cgi file (make a backup copy first) and add a line like this near the top of it (somewhere after the first line):

...or:

If all of this sounds like too much hassle, well, it is.  Again, no self-respecting hosting company in 2010 or beyond should be forcing its customers to deal with subdir sites, when subdomain sites are such a better alternative.  If your hosting company can't get its act together, you may want to switch to a better one.

[ Top ]

Do you offer free technical support?

Yes: see the contact page.  Tech support via email is free, and tech support via phone is free for the first 15 minutes; time in excess of that is charged at the normal hourly rate.  This is because tech support for web apps involves giving specific error messages, exact URLs, etc – things that are easy to copy and paste into an email, but a hassle to say over the phone.  Tech support phone calls tend to turn into hour-long affairs for things that would only take 10 minutes to resolve via email.  Plus, with email, both parties have the exchange in writing for future reference.  So it's always preferable to send your questions via email.

[ Top ]

Shopping Cart