Frequently Asked Questions

Applying to multiple apps, or Encodable generally

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?

Emails sent from the app are not arriving.

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?

Are Encodable apps open source?

 

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.  If you also want it to have a separate app folder, then copy that folder (the "upload" folder in the case of FileChucker) to a new name, and update any settings in the new prefs file that refer to that folder: $PREF{app_base_folder} for all apps, then others on a per-app basis like $PREF{uploaded_files_dir} for FileChucker.  Finally, if you want to use the shortcut URLs from within the app folder, then you'll need to edit the various index* and call* files in the app folder, adjusting the variables within those files which refer to filechucker.cgi, so they now refer to f2.cgi instead.

[ 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 use the output to create a _prefs_extra.cgi file for you, containing all your customizations.  Then you can put that file on the server with your new copies of the app and the regular prefs file, and you'll have all your customizations in effect without having to modify the regular prefs file.

[ Top ]

 

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

When requesting an app upgrade, or a registration change, 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 ]

 

Emails sent from the app are not arriving.

Sending an email is only half the battle.  The message must then be passed from mailserver to mailserver until it reaches its final destination, and problems can occur in these later stages of delivery, which cannot be detected nor fixed by the app that sent the message.

However, you can at least verify that the app did send out the message successfully.  In UserBase, login with your admin account, then on the Account Center page, under Admin Links, click View Sent Mail.  In FileChucker and other apps, you'll first need to enter your database details, by going to Administration -> Settings, then scrolling down to the "database settings" link.  Once you've entered and saved the correct database details, go to Administration -> Settings -> All Prefs and find the $PREF{log_all_sent_mail} setting, and enable it.  Now, your Administration page will have the View Sent Mail link.

On the Administration menu, there is also a Test Email link, where you can adjust your email settings, and send yourself a test email.  This page includes further instructions and details.  But the general approach would be to send a test email; then disable the $PREF{path_to_sendmail} setting (set it to null/blank and save it) and send another test; then re-enable $PREF{path_to_sendmail} and disable the $PREF{smtp_server} setting, and send another test.  That should help you find which method will work on your server.  If not, you may need to enter a user/pass for SMTP authentication, or contact your hosting company to get the specific email-sending details for your server.

Be sure to try a few different To: and From: addresses when sending the test emails, too -- sometimes a server will only send emails if the From: address is on a certain domain (such as the server's domain).

In some cases, it's simply a matter of the emails being flagged as junk/spam, so be sure to check your junk/spam folder if you don't see the messages in your inbox.

[ 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:

Also be sure your permissions are set properly: on the script itself (whatever.cgi) the permissions should be 0755, or a+rx, or -rwxr-xr-x.  On your cgi-bin folder the permissions should be 0755, or a+rx, or drwxr-xr-x.

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 CSS and JS lines to your page's head section.  Previously, those lines called the CGI script, like this:

Those extra CGI calls could slow your page down.  So newer versions use static CSS and JS files, like this:

The newer versions will create those fc.js and fc.css files automatically (or ub.js and ub.css for UserBase, etc) in the appdata subfolder.  If you're using an older version and you don't have those CSS/JS files, you can create them manually: 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, named fc.css.  Do the same thing for the ?js output; save it as fc.js.  Then upload fc.css and fc.js into the /upload/appdata folder (or /login/appdata for UserBase, etc) on your website.

[ 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 ]

 

Are Encodable apps open source?

For most practical purposes, yes: when you download the trial version of an app, you get its source code, and when you purchase the full version, you get its source code.  You're free to view and modify this code as you like for your own use.  But technically, the term "open source" usually includes the ability to not only view and modify the source, but also to redistribute it, which is forbidden for Encodable apps: you can use and modify them but cannot redistribute them.

[ Top ]

Shopping Cart