WSN Directory

Disabling mod_security

Thu, 11 Oct 2012 10:11:12 GMT

The so-called web application firewall mod_security is deployed by many web hosts, each with different rule sets. Although the core ruleset shipping with mod_security works great with WSN, many web hosts employ over-aggressive rulesets which kill all sorts of legitimate pages for such offenses as using a particular field name or uploading a file or typing something that looks like SQL in a form. If you're seeing 500 internal server errors or 403 forbidden errors which seem to happen randomly or when you type certain things in a form, it's likely you're seeing mod_security at work. In order to ensure that your site works correctly, you'll need to either get the ruleset fixed or get mod_security disabled.

reviously it was possible to disable with an .htaccess file, but most web hosts are now using mod_security 2 which can't be disabled from an .htaccess. Your only option is to ask your web host to disable the rule that was triggered on the particular page you see the error (or at least get them to say what rule was triggered and convey that to WSN support), or to ask your web host to disable mod_security entirely for your account.

Excessive Page Caching

Thu, 17 Nov 2011 05:31:20 GMT

Sometimes, on certain web servers, over-aggressive browser page caching is triggered which leaves you frustratedly seeing old versions of pages. To prevent such caching you can apply this special .htaccess code:

Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"

If you're using URL rewriting, enter the above in the extra .htaccess content box at Admin -> Settings -> SEO so that it'll get included every time the .htaccess is recreated. If not using URL writing, you can make your own .htaccess file with that content in the directory where you've installed WSN.

Enabling PHP 5

Wed, 11 Mar 2009 19:00:37 GMT

If WSN informs you that your host is running PHP 4, that means your host is defaulting to PHP 4. At this point, it's very unlikely that a host would actually not offer PHP 5 -- they just don't necessarily make it the default (though they should since PHP 4 is abandoned and insecure).

Ideally, you should ask your web host. If they tell you to rename files to a .php5 extension, tell them that you want the .htaccess alternative. On a host that has PHP 5, one of the following .htaccess files should enable PHP 5:

AddType x-mapp-php5 .php

AddHandler application/x-httpd-php5 .php

AddHandler cgi-php5 .php

Place the .htaccess in the directory above where you want to install WSN -- the parent directory. If installing WSN at /public_html/, place the .htaccess at /.

There's no way to know which type of host you have except to try all three options until one of them works -- or just ask your host which to use.

If you're looking to upgrade an existing WSN installation in which you're using URL rewriting, and thus already have an .htaccess file, you can either make that the .htaccess file for its parent directory or combine it into WSN's .htaccess by entering it at Admin Panel -> Settings -> SEO -> Other .htaccess content. Don't simply edit the file manually, as it will be overwritten regularly.

If this method doesn't enable PHP 5 on your web host, you'll need to communicate with your web host.

Not Getting Digest Emails

Fri, 05 Sep 2008 12:17:30 GMT

If some digests are getting through but others aren't, compare the number of members you have with the number of daily hits on the particular WSN installation you're dealing with here and the number of emails per queue being sent. Go to Admin Panel -> E-Mails -> E-mail Preferences -> "Number of emails to send at a time from queue:" to check how many are sent per page. If that number is 10 and you have 10,000 members integrated from a discussion forum, but the links directory you're dealing with only gets 10 visits a day, only about 100 digests will get sent out per day. This is because PHP can only run when someone requests a page, so it can only send out digests when someone visits. You can increase the number sent per page, but not too much or the pages will become noticably slow or error out at very large numbers.

A solution to get more emails sent without slowing pages is manufacture more (fake) visitors. You can do this on a unix or linux operating system by setting up a system cron -- please note this is NOT the same as the crons page in the WSN admin panel (WSN crons are php-based so can only run when people are viewing pages). Your hosting control panel should offer you a way to set a cron. If you have CPanel, you'll find a "cron jobs" option in the menu. Select "standard" experience level. Supply

wget yoursite/wsn/index.php

as the command -- replacing yoursite/wsn with the URL of your WSN installation first. Set it to run every minute. That should handle an additional 14,400 digests per day. If you need to handle more than that, you may need to set up another cron. You can also increase your items per queue on the email settings page to more than 10, but don't set it too high or the page will take forever when someone wants to view it.

Note: you may find that you can increase the queue if you use SMTP to send mail.

Clicking link to front page removes www

Sat, 19 Jul 2008 23:47:36 GMT

Does http://www.yoursite.com/ show as expected, but http://www.yoursite.com (without the trailing slash) redirects to http://yoursite.com (removes the www)? This behavior is a peculiar way some web servers have been misconfigured. When a web server receives a URL request that doesn't include a trailing slash, it internally interprets it as including that slash. Some web servers can be misconfigured so that they'll load it without the www. portion of the URL. This results in cookie data being lost if you don't use a .example.com cookie domain, and a possible loss of pagerank juice from links. Ask your web host to fix the problem in the web server configuration file.