We're happy to help, but please provide clear details. In most cases, quick resolution depends on:
The more detail you provide, the faster we can help!
A blank/white page usually means PHP error reporting is disabled in php.ini. Enable error reporting to see the actual error messages.
Templates often contain many elements—tags, HTML, JavaScript, images—making debugging difficult.
When something fails, create a minimal test template with only the problematic element. For example, if you suspect the <!–ALT–> tag isn't working, create a simple template like:
<thumb num=1-10> <!--GALLERY_ID--> : <!--ALT--> <br> </thumb>
That's it, nothing extra, easy to understand which gallery doesn't output alt and solve the problem.
1. Check if cron works. Home tab. If there's no “check SCJ crontab job” text there - follow the next steps. If there is this text, it means someone deleted our cron task. You need to write a line like this to run every minute
cd /path_to_scj/scj/bin/; env HTTP_HOST=yourdomain.com /path_to_php/php -q cron.php
2. If you use SmartCJ index.php make sure there are no other index files in the same directory, for example index.html. Depending on server settings by default when requesting URL
http://domain.com/
it can take the index.php or index.shtml or index.html file etc. That is if the directory has index.html - the server loads it instead of index.php (SmartCJ file), i.e. the Smart script doesn't work and hits are not counted.
This is also a way to see where an external rotator redirects you, for example. Since each click goes through many rules - the only way to know why it redirects here and not there - is the headers. So in the HTTP protocol, roughly speaking, there's a concept of headers and content. Headers transmit service information, content - is the page itself, image or for example flash. 99% of all redirects happen using the Location header. When the browser receives such a header from the server it immediately goes to the specified URL.
So to see where the script redirects you, you need to see the headers. This is done as follows (there are many options, but I think this is the simplest and requires minimum effort):
Location: http://site.com/
this is the redirect.
So also in the headers there can be strings like Current-Click: etc. To analyze each specific situation you need exactly the headers.
2 options:
1. if you use include for click counting
It's very easy to check. If you use include.php rename it to include_scj.php and create a file include.php with the following content
<?php
$f = fopen('./log.txt', a);
fputs($f, date('H:i') . " {$_SERVER["HTTP_REFERER"]} \n");
fclose($f);
include('include_scj.php');
then create a log.txt file and chmod it 666
The script is very simple, it just writes referrers to a file. Set the script for an hour or day as you like and at the end of this period download the file to Excel and sort it - it will be easier to count how many hits were from the needed referrer and accordingly how many hits were from the needed domain.
2. if you use Smart's index
<?php
$f = fopen('./log.txt', a);
fputs($f, date('H:i') . " {$_SERVER["HTTP_REFERER"]} \n");
fclose($f);
include('index_scj.php');
Done. The script is very simple, it just writes referrers to a file. Set the script for an hour or day as you like and at the end of this period download the file to Excel and sort it - it will be easier to count how many hits were from the needed referrer and accordingly how many hits were from the needed domain.
If you need to count the number of CLICKS everything is almost the same.
<?php
if ($_COOKIE['from'] == 'trader.com') {
$f = fopen('./log.txt', a);
fputs($f, date('H:i') . " {$_SERVER["REMOTE_ADDR"]} \n");
fclose($f);
}
include('out_scj.php');
where trader.com is accordingly the needed trader.
then just look at the number of lines in the log file for the selected time period.
A: Clicks are counted by cookies. On IN the user gets a cookie that records which trader they came from. On clicks this cookie is read and the corresponding trader gets a click. If the script can't read the cookie when clicking (it's not there) - the script records such clicks as nocookie.
The technology of cookies is such that if a cookie was set on a page on the domain www.asd.com, then on a page with domain asd.com it will NOT be visible. Read more about this in RFC 2965 and RFC 2109.
What this means in our situation: if a surfer came to your page
http://www.site.com/
and the link to out
http://site.com/out.php
(i.e. without www), then cookies will NOT be passed to out and clicks will be counted as nocookie. To avoid this you need to make all links to out relative.
<a href='http://site.com/out.php'>Click here</a> - WRONG <a href='/out.php'>Click here</a> - Correct
There are special cases, for example : The trader has a Personal Page set. The trader sends you as
http://host.com/
, and in Personal Page it says
http://www.host.com/trader.html
, i.e. the cookie is lost. To avoid this it's better to specify the personal page as a path i.e. just trader.html (without http:/www..)
You need to enable in Settings - Debug out.php, click on the right link and see the headers (how to do this is described above). Usually by the headers it's clear what's happening. If it's not clear - create a topic on the forum with headers, we'll figure it out.
I often encounter the following situation: with web server errors (403, 404) it redirects to the domain root. When a picture is missing on the index the browser loads instead of the missing picture - the index, so we get 2 ins instead of one visit.
Option 2: the Smart index is on the root. At the same time in CJ Pages the same index is also specified, it turns out that the index includes itself.
In any case, it's easy to check this.
1. make a test template where just a line “test” 2. open the site as domain/?force_template=test 3. make sure that in the hit counting log there's only 1 entry from your IP 4. move to the test template piece by piece what you have in the index until you notice it counts 2 times
Most likely the problem is in the server's resolv settings. The script checks for presence of this service ban (http://www.uribl.com/about.shtml) by running the command in the shell
host -tA trader.com.multi.uribl.com
If the domain is not in the database the service should answer something like
Host trader.com.multi.uribl.com not found: 3(NXDOMAIN)
If you get “can not connect” or “can not resolve” - you need to contact the admin and ask them to fix resolv.conf. As an option show them the documentation (http://www.uribl.com/about.shtml) with a description of how it should work.
Check very simply: all parts of the script that work with traffic include the common.php file accordingly you can add a small simple code to this file that will log all script requests to a text file.
$f = fopen('full path to log.txt', 'a');
fputs($f, date('Y-m-d H:i:s') . " file {$_SERVER['REQUEST_URI']} ref {$_SERVER['HTTP_REFERER']} ip {$_SERVER['REMOTE_ADDR']}\n");
fclose($f);
Done. As you can see 3 lines in the script, there's no way to make a mistake, then you can count the number of requests needed to the right script (in\out) and compare with what's in the script. It's convenient to filter for example in Excel.
Now Google loves sites more that are signed with a certificate (https). The question of trading is that by default when switching from https to http the referrer is not transmitted, accordingly the traffic comes as noref.
In this situation there are 2 solutions:
The tag is added to the <head> of your document and looks like <meta name=“referrer” content=“unsafe-url”>
There are the following variant values of the tag:
Of these we're only interested in origin and unsafe-url. Technically for trading origin is enough. However, considering that the script often uses redirect to niche by trader referrer, it's better to use unsafe-url.
It's worth noting that this is not a feature of some script, but a feature of modern browsers.
99% of out problems are solved by viewing debug headers of out.php
Usually by the headers it's immediately clear what and why, if something is not clear - support on the forum will help figure it out.
To test clicks from a certain country you need to change the country for the server. That is, if for example you're in country 1, but need to emulate a click from country 2, you don't need to buy a VPN of country 2, it's enough to specify in common.php something like:
if ($_SERVER['REMOTE_ADDR'] == '1.1.1.1') {
$_SERVER['GEOIP_COUNTRY_CODE'] = 'DE';
}
where 1.1.1.1 - replace with your real IP, and DE - replace with the country code you need.
If GA cannot download statistics from another domain, then usually it's a problem on that domain. For example, the domain is on one IP, but DNS points to another, or the admin closed the Smart directory from Google, and as a company closed it from everything.
Check: in the shell on the server where GA is, do wget http://anotherdomain/scj_folder/bin/scj_ex.php
and see what the response is. Should answer something like HTTP/1.1 501 Password Error, if not - you need to see the admin where the request actually goes.
The script checks the correctness of the path of the main libs, including imagemagick. The check happens as
exec("/path/to/imagemaick/convert --version", $output, $error);
if $error is not 0 (i.e. some error happened, a warning is output. If the admin thinks the path is correct then they can make a PHP file
<?php
exec("/path/to/imagemaick/convert --version", $output, $error);
echo $error;
and check if the error is output.
In general most proxies http are determined by a header like X-Forwarded-For (in PHP it's denoted as HTTP_FORWARDED_FOR). When connecting Cloudflare the request itself doesn't come from the real user, but from Cloudflare. Here 2 problems arise:
What to do:
You can also try without mods config modification, there was an interesting example for nginx
if ($http_x_forwarded_for ~ "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}),(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$") {
set $xreal $2;
}
fastcgi_param HTTP_X_FORWARDED_FOR $xreal if_not_empty;
The script is managed by IonCube Optimizer, which requires its own files for different PHP versions. When you run the script installation in the shell, it determines the PHP version it was run with and downloads the files for the needed version
But sometimes there are several PHP versions on the server, one of them is the default. For example if you just write in the shell
user@server:~/$ php -v PHP 7.0.33-0ubuntu0.16.04.16+esm4 (cli) ( NTS )
you can see that the default version is 7.0.33, while for the web a different version may be enabled.
Open scj/admin/test.php - PHP Version 7.4.29
It turns out that files were downloaded for 7.0, but we run with 7.4, in this case IonCube won't work.
You need to ask the admin to unify the versions.
By default the slave has the same descriptions as the master. Actually it uses the master's table with descriptions. You can disconnect the descriptions of the master and slave, so that the slave has the same galleries, but with different descriptions. This is done on the master, rotation settings, master - slave.
Sometimes people disconnect descriptions, but don't change them.
What's the downside:
- for the slave a table is created with the same descriptions, but it takes space. - mysql caches both the master table and the slave table, although in fact it's the same data - takes space in memory
Therefore if you don't change the descriptions on the slave, it's better not to disconnect and save server resources.
In all systems there's a division of user rights. For example, root has the right to change all files, a user - only their own. This is done to distribute rights in the system and not let a user mess up with files of other users or crash the server because the user changed server settings without understanding what they're doing.
There's also a division of rights of users and web server (apache\nginx). For example, a user uploaded the script (files) to the server. For example, in the script or templates there's a hole\bug and a hacker through this hole decides to download a backdoor \ exploit to the server. In a normal situation, when user rights are divided, the hacker can't write anything to the user's file and the server will be safe, because by default one user (apache) can't change files of another user (the user)
Sometimes, for some files, permission must be given to another user to write, for example, the user gives permission to write to one specific file (conditionally log.txt) - to other users (for example apache), then 666 permissions are set on this specific file.
However, sometimes the server is set up wrong, and apache can write to any file of any user. Thus, if there's a hole in the template, the hacker can replace the script file and for example start redirecting traffic to themselves.
For the script it's important to correctly determine if a user is behind a proxy, since the easiest way to hack the script - is to make clicks from different IPs (through proxy)
Proxies are determined by the presence of headers in the request (HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR, HTTP_CLIENT_IP).
But often when setting up nginx + apache the transfer of headers is not set up. It turns out that a request comes with IP 22.22.22.22 to nginx, it should pass this request to apache and “pulls” apache, but since apache is on the same host as nginx the request to apache comes with IP 127.0.0.1, to pass the real IP nginx adds field HTTP_X_FORWARDED_FOR = 22.22.22.22 and apache already thinks this is a request through a proxy.
To prevent this in apache there are mods that automatically process such a situation (mod_remoteip, mod_rpaf) and set the real IP for requests with 127.0.0.1 (i.e. when apache is behind nginx)
If the grabber (trader thumbnails top, galleries etc i.e. any content that needs to be downloaded) can't download (can nod download, can not connect and so on) then
wget http://your_url or curl http://your_url
What can cause it: