Support

Feel free to email me at bengebre@eyebeam.org if you have questions.

FAQ

Setting up FastCGI
500 Errors (Problems importing links)
400 Error (Trailing slash issue)
Use MySQL instead of SQLite (It might fix a lot of your problems)
Upgrading to v.2

Setting up FastCGI
SlashLinks runs with Fast CGI turned off because there are some stability issues on some platforms (mostly shared host machines). If you want to try Fast CGI though (and assuming your host is configured for FastCGI), you can edit the .htaccess file found in the public directory and change the line that says:

RewriteRule ^(.*)$ dispatch.cgi [QSA,L]

To:

RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

Just change the suffix to .fcgi instead of .cgi. If you get 500 errors from your website when viewing your links, it’s probably cause FCGI is taking up too much resources from the machine and your processes are being killed.

Trouble importing links – 500 errors
I sometimes have trouble doing a full link import on my shared host account when they have a high load. There’s some things you can do to minimize the chances of getting 500 errors however. First, don’t try to do it in FCGI (Fast CGI) mode. FCGI mode is just plain more sensitive, and the multiple instances that start up due to the AJAX stuff on the backend are going to push that sensitivity even more. Generally things work pretty well in CGI mode. If you are still having problems in CGI mode though you might be able to start up SlashLinks with Webrick for the initial import. Try this from a shell the slashlinks directory (not the web directory but the program directory):

slashlinks/script/server –e production

Then go to your site like this:

www.example.com:3000/configuration

The Webrick server runs over port 3000, so SlashLinks will be available over that port and under that root directory until you kill the process. However, it will write the same database as the Apache run version and is generally more stable on a hosted machine. Once you get the import done hit control-c to kill the process. Then try to view your links via the normal web path (e.g. www.example.com/links/).

Yes, I know this switching between servers thing is not ideal. I hope that as I learn more from the Rails community I’ll be able to find a more user-friendly solution to these occasional 500 errors.

400 Error with no trailing slash
I’m still trying to come up with a good solution to the problem of not resolving www.example.com/links to the same thing as www.example.com/links/ I think I should be able to get it going with the appropriate mod_rewrite rule, but I haven’t gotten there yet. For the time being, make sure you specify the slash in the link to the base SlashLinks directory and you should avoid most of the trouble.

There's some Rails forums discussing this issue out on the Internet. Here's some places you might want to start at if you are willing to dive into .htaccess files and mod_rewrite stuff:

Rails Non VHost Installation
HowToUseRailsWithRewrittenURLs

Using MySQL instead of SQLite
There have been some issues reported with importing large amounts of links using SlashLinks with the default SQLite configuration. Some hosts don't have SQLite configured correctly for ruby/rails which leads to errors on the import. Additionally, the SQLite db can often be slower on import than MySQL. Why did I choose to use SQLite rather than MySQL in the release? Well, the amount of configuration for MySQL is more than the zero configuration required for SQLite. Of course, this ease of use gain is offset if SQLite has been installed incorrectly for use with Ruby/Rails.

So how do you set up MySQL with SlashLinks? It's not that hard. The first thing you need to do is create a database for SlashLinks to use to store it's data. Logging in to your host's MySQL server will be different for everyone, so I can't outline the exact steps here, but once you log in type CREATE DATABASE slashlinks; and then use slashlinks; (So the database is called slashlinks in this case, but you can call it whatever you want. I refer to it as YOUR_MYSQL_DB_NAME in it's generic form below.) Then copy and past the file in slashlinks/db called db_mysql.txt into the MySQL session. You should see a string of OKs if the process completes without error. Now type quit;

You've initialized the slashlinks database now. Now we just need to tell SlashLinks to look at MySQL for the database instead of SQLite. This is done in the slashlinks/config directory in the database.yml file. You need to change the production environment to point to MySQL. Here's an example of what it should look like (in v.1, you could still do the same thing in v.2, but there's an easier way -- look below):

production:
adapter: mysql

database: YOUR_MYSQL_DB_NAME (we used slashlinks in the example above)
host: YOUR_MYSQL_DB_HOST
username: YOUR_MYSQL_DB_USERNAME
password: YOUR_MYSQL_DB_PASSWORD

Of course, substitute your database host and your password in the appropriate fields. Now when you go to the SlashLinks configuration page you'll have to reimport all your links, but from now on they'll be in a MySQL db instead of SQLite.

Update for v.2
For SlashLinks version .2, I've modified the slashlinks/database.yml file so that all you have to do is change the production: production_sqlite line to production: production_mysql. You still need to configure the database,host,username and password section to reflect your configuration, but this should make it a little easier. Also, you can initialize your already created database by typing cat db_mysql.txt | mysql -u USERNAME -p DATABASE_NAME at a shell (you can use this method in any version of SlashLinks instead of the copy-paste method outlined above if you want).

Upgrading to v.2