Awstats does not show September's stat!

DirectAdmin Support said:
Hello,

Sorry, I'm wrong. The default is always "stats". I'll have to update that default in the DA code.
The symbolic link needs to be /awstats or else images and urls will be broken.
Click to expand...

That is strange. I have now tested with a site using something else then the word "awstats", and the cgi versions still works fine. All images and URLs is working, nothing is broken.

But there is another problem. I tested another domain by creating a folder named "awstats" from the control panel, and then I password protected the "awstats" directory using the file manager in DirectAdmin, the result was that the domain.com/awstats returned a 404 not found page instead of statistic. That happen because the code for password protection was added to the existing .htaccess file at awstats directory, and that made a conflict resulting in 404 not found on domain.com/awstats.

I hope you will find a fix for this, because it is important that my clients can password protect the awstats directory using the file manager in DirectAdmin.
 
Last edited:
Hello,

I've set the "path" variable to be readonly so awstats much be used when creating the link if awstats is enabled. I ran into the "other word" situation where it still worked, but that was because the /awstats link still existed, so all images were still using the /awstats path, even though the pl file was being accessed via some other path. It needs to be awstats, and the next release of DA will enforce that.

As for the password protection, if you're getting issues, can you paste the resulting .htaccess file you've got? I tested adding password protection on our build system, but didn't have any issues.

John
 
Hi John,

ive a question, if i enable /stats or /awstats link to a domain.. how can i remove it if i dont want to have "public" stats anymore?

Thanks
 
Hello,

You should be able to delete it from your filemanager.
The link is a file in the public_html directory.

John
 
DirectAdmin Support said:
As for the password protection, if you're getting issues, can you paste the resulting .htaccess file you've got? I tested adding password protection on our build system, but didn't have any issues.
Click to expand...

I have tested more, and the trouble with .htaccess and password protection is only visible when using WordPress with permalinks. Here is a description:

1: The domain use WordPress with permalinks set to this: http://domain.com/2010/11/sample-post/ and then have the following .htaccess at this path: /home/username/domains/domain.com/public_html/.htaccess:

Code: 
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

2: Using DirectAdmin file manager I browse to this path: https://hostname.com:2222/CMD_FILE_MANAGER/domains/domain.com/awstats and then I pasword protect it.

3: Then trying to browse to domain.com/awstats give a 404 not found error

4: If I remove the following WordPress code from .htaccess at /home/username/domains/domain.com/public_html/.htaccess, then the domain.com/awstats work again:

Code: 
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

5: So when setting password protection on domain.com/awstats using the file manager, it result in a .htaccess file in awstats directory to look like this:

Code: 
Options -Indexes +ExecCGI
AddHandler cgi-script .pl
DirectoryIndex awstats.pl
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain.com$ [NC]
RewriteRule ^(.*)$ http://domain.com/awstats/$1 [R=301,L]
AuthGroupFile /dev/null
AuthName "passord"
AuthType Basic
AuthUserFile /home/username/domains/doman.com/.htpasswd/awstats/.htpasswd
require valid-user

And it is this that is not compatible when using Wordpress with nice looking permalinks. This must be changed to be compatible with users running WordPress sites installed at public_html - also when testing, please be aware that the browser will cache the awstats statistic page. If you visit it when it works, then test and change so it should not work, it will look like it works because it is cached. You must then after doing changes restart the browser to see if there is problems or not with domain.com/awstats

Just to make sure you don't misunderstand me: What we need is for the password protection of "awstats" folder, or the placement of the default .htaccess file in "awstats" folder, to be in such a way that it will still work when people have the following WordPress .htaccess file in public_html:

Code: 
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
 
Last edited:
DirectAdmin Support said:
I've set the "path" variable to be readonly so awstats much be used when creating the link if awstats is enabled. I ran into the "other word" situation where it still worked, but that was because the /awstats link still existed, so all images were still using the /awstats path, even though the pl file was being accessed via some other path. It needs to be awstats, and the next release of DA will enforce that.
Click to expand...

This does not make sense to me. When we created the stats folder with a different name, it was for the first time, and we had never before created any stats folder with the word "awstats", only doing it ones with a different word. And it works.

Also it don't make sense to me, because when I run your new awstats script in custombuild and installed it, after that all my domains was having a awstats folder with the new files and values, the only thing missing until setting it in the control panel, was the symbolic link.

When setting a different word, it only seems to set a symbolic link to the existing awstats directory, so therfor it don't make any sense to me why it should not work with a different name, and it does work when I test.

But it is fine with a read only "awstats" word for this, we don't need to let customers choose another word. No problem. I just do not understand you, and it works for us when testing.
 
Change
Code: 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

to

Code: 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-s
 
No, that is not a acceptable solution. I am running a shared webhost, and my clients needs to be able to use WordPress permalinks without them needing to change anything manually. So this must be fixed by DirectAdmin so that it is compatible with the WordPress permalinks structures available.
 
ditto said:
No, that is not a acceptable solution. I am running a shared webhost, and my clients needs to be able to use WordPress permalinks without them needing to change anything manually. So this must be fixed by DirectAdmin so that it is compatible with the WordPress permalinks structures available.
Click to expand...

This is a system issue and has nothing in common with Directadmin itself.
WordPress's rewrite rules do not take into account symbolic links at all.
Without this fix you won't be able to visit any page located within a directory, that is a symlink.
 
I had an issue where awstats started making .xml file instead of html.
 
ditto said:
No, that is not a acceptable solution. I am running a shared webhost, and my clients needs to be able to use WordPress permalinks without them needing to change anything manually. So this must be fixed by DirectAdmin so that it is compatible with the WordPress permalinks structures available.
Click to expand...

Unfortunately, it is the solution. The error doesn't have as much to do with awstats, but rather the use of links which is done in other areas as well (like webalizer). It's nothing new. Add the line to your main .htaccess as mentioned by zEitEr, to allow links.
Code: 
RewriteCond %{REQUEST_FILENAME} !-s
It might be good to push Wordpress to add that line by default.

If there were definitive checks that could be done to determine if a site is using wordpress (let me know what's unique about a wordpress site), it would be easy enough for me to do them add have the script add the line, but I do say that's slightly out of the scope of the script.

John
 
After adding the line to .htaccess in public_html, it still does not work. If I passoword protect the "awstats" folder using the file manager in DirectAdmin, then domain.com/awstats still give a 404 not found error. This is the content of my .htaccass file at public_html folder:

Code: 
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule . /index.php [L]
</IfModule>
 
# END WordPress

You should make the statistic folder, and the file manager ability to password protect the statistc folder, flexible enough so that this does not happen. This is a DirectAdmin problem, not a WordPress problem.
 
Hello,

There might be something else at play.
I just tested that .htaccess file, with the awstats link, while using directory password protection on the /home/user/domains/domain.com/awstats folder, and it worked fine for me.

I may need to take a look at your box to see what's up, but I'm not sure what the cause of the error in your case is.

John
 
Hello,

FYI:
http://www.directadmin.com/features.php?id=1125

You can grab the new pre-release DA binaries from your Clients Section. Click your license, and follow the instructions.

The new pack will contain the most recent awstats_process.sh as well as new DA binaries which allow for dynamic awstats.pl processing both within DA, and through apache. No need for the static html pages anymore (but they are still generated for now)

John
 
You must log in or register to reply here.
Back
Top