Try the Draupnir demo
Detailed Features Guide
Find Trusted Networks
or get your network found!
Friends and associates
You MUST install draupnir in the same directory as or higher than the page(s) you
will track with it.
Because the Draupnir script uses some very advanced networking features, it expects certain files to be
located in certain directory paths relative to the root page.
If you want to track http://www.yourdomain.com/yourpage.php then Draupnir must be installed in http://www.yourdomain.com/
If you install draupnir in some other subdirectory and try to track a page in the root, it will not work correctly.
More frequently asked questions:
- I am getting an error message upon installation that says the IonCube loader is not present.
Ask your hosting provider to install IonCube, it is available for free. If they tell you that you already
have IonCube, then show them the page which says it is not present. Sometimes hosts make mistakes, but if
the script says that IonCube is not available, then it is not available to it ;-)
- I have PHP 5 installed, but the script will not run.
You must use at least PHP 5.2 or newer. Newer versions of PHP have some extra commands available for security
measures, that is one reason why I prefer using it instead of earlier versions of PHP.
- Toplists are not updating.
This might be due to one of several reasons:
- cron is not set or is not running (see below)
- The .tpl template files are not uploaded into draupnir_toplists/
- In the Site Config menu under 'Toplists', make sure "Toplist template files:" are each named without the .tpl extension and with one space between each filename such as: toplist1name toplist2name toplist3name
- Make sure the draupnir_toplists/ directory has permissions set to 755 or 777. If one does not work, try the other.
- Trade stats are not displaying, yet I can view clicks in the trade logs.
- Most likely, cron is either not set or not running (see below)
- Make sure the draupnir_data/files/ directory is set to 755 or 777. If one does not work, try the other.
- Cron is not set or is not running.
- Cron is not set automatically. You must follow the installation instructions and set it manually.
- Make sure that cron is set to run every minute.
- Go to the Site Config menu in admin and scroll to the bottom of the page. Your cron settings should be listed there, you may choose to run either the setting for wget or the setting for lynx. Do not run both!
- If using the wget cron setting:
- Make sure that the wget path listed in the cron setting is correct for your server. On most servers, this will be /usr/bin/wget. If you have SSH access you should be able to determine the path by logging in via SSH and typing "whereis wget". Draupnir tries to do this automatically, however not all systems permit doing so.
- Make sure that the wget file has the correct permission settings. This will typically be 755.
- Alternatively, it might be easier to use the lynx cron setting. Lynx utilizes slightly more system resources, however unless you have dozens of copies of Draupnir on one server, the difference should be negligible. I did notice a difference in switching from lynx to wget on a server with ~60+ installs.
- If none of the above solves your problem, then feel free to post a question in the forum, however it is almost certainly a problem which will need to be resolved with your hosting provider. I would suggest showing them the command that you want to run and telling them that you need to make sure it is utilizing the correct wget path.
- My outlinks keep going to /st/draupnir_out.php or similar, which generates a 404 error.
Try one of the following:
- Prepend ../ to your draupnir_out.php statement within your tgp script, such as ../draupnir_out.php?pct=60&f=1&url=
- Generate an absolute path to your draupnir installation, such as:
- I am getting error messages on my .php page about headers that have already been sent.
If you are using .php pages, you MUST include the draupnir_in.php statement in the very first line of your code. It cannot appear anywhere except for line #1 on your page.
- I am using subdirectories and am having problems including draupnir_in.php
To include draupnir_in.php from a page within a subdirectory, you have two choices:
These examples are for .php pages. Modify them for .shtml as appropriate.
- Alter the statement to something like:
<?php include "../draupnir_in.php"; ?>
<?php include "../../draupnir_in.php"; ?>
etc. (use one ../ for each directory it needs to change up to)
- Use an absolute path. You can usually determine this most easily by logging in via FTP and taking note if your FTP program lists the full filepath when you switch into a directory. It might look something like this:
<?php include "/home/domain/public_html/draupnir_in.php"; ?>
- I am using subdirectories and am having problems including toplists or other files.
Once draupnir_in.php has been called correctly on a page, the system filepath will now be pointing to the same
directory where your Draupnir files are located. Typically, this will be your root directory; so if you
want to include toplists you should include them relative to that directory, or by using an absolute path.
You might use something like the following:
These examples are for .php pages. Modify them for .shtml as appropriate.
Another way to avoid this problem is to use the statement below for the include. This will change your filepath
back to the original directory after including draupnir_in.php:
- <?php include "draupnir_toplists/example_one.htm" ?>
- <?php include "/home/domain/public_html/draupnir_toplists/example_one.htm" ?>
Keep in mind that you may need to change "../../../draupnir_in.php" to the correct path. Big thanks to
Overlord_45 for this tip.
- I want to track hits on multiple pages, what extra code do I need for the include statement?
Nothing at all. This script requires only the standard draupnir_in.php statement to be placed on every
possible entrance page of your site, you do not need to wrap it in other code. Do not try to wrap it in code
provided by another trade script, it may cause it to malfunction somehow.
- Why don't you include a toplist editor in the admin like script XYZ has?
I had considered doing that and it would not be difficult to do at all, however I view that as a potential
security problem. If a hacker were ever to breech your system, the most obvious and sensible way for them to
cause problems would be to insert extra, unwanted code into a toplist, a task which is made much easier when
a toplist editor is built into a script.
In light of this, I will not build a toplist editor in this script; I consider them as a potential source for
many security problems and they offer very little practical advantage compared to simply editing a toplist
template in notepad or something and using FTP to upload the file. Doing that is a lot easier than cleaning
up some unforeseen mess after a security breech.
- Why does this script require a cron setting when script XYZ does not?
This script actually ran without cron in early development, however I discovered some potential problems in
doing it that way. This gets a bit technical, so I'll give you a short answer and a long answer.
The short answer:
The long answer:
- Some of the more advanced features of this script make running it without cron impractical and unreliable.
Doing so would inevitably lead to some visitors experiencing a significant performance lag. Not good if that
visitor would have been the one to make a sale ;-)
- PHP cannot run simultaneous tasks concurrently (without some improper and unreliable coding trickery).
This means that, for instance, if the script requires
stats to compile at the top of the hour, and it needs to update the blacklists across the entire network, and
it needs to run anti-cheat on some trades, and it needs to lookup the IP's of some domains to run anti-cheat,
then it must either do that as a separate process run by cron, or else it must wait for a visitor to arrive
then make that visitor wait while it does all of that before it lets him see the page or sends his click to
another gallery or trade. Needless to say, some of the above tasks can become quite time consuming,
especially if some of the site(s) it is trying to connect to are slow to respond or are offline.
If this script were to run without cron, some visitors would get stuck staring at a blank page while all of
the above was waiting to take place. Scripts which do not make use of some of these advanced features do
not have this same concern, so they can run more easily without a cron setting.
Draupnir users enjoy features that other scripts do not provide, and to do so it requires setting up cron
to take care of some of the tasks described above. This way, when someone visits your site or clicks on a
link, the only thing he is waiting for is for the site to load or to go to the intended link, and he is not
stuck waiting around for stats to process or for other tasks to complete a lengthy run.