helened

For Wassup to run with “WordPress Firewall”, “wassup_screen_res” has to be added to Firewall’s Whitelist as a “Form Variable”.

However, “WordPress Firewall” has 2 major problems that must be fixed ASAP before any Wassup user should use it:

1. Firewall redirects incorrectly when WordPress core files are in a separate directory from the blog. This can send visitors to 404 page or server error page.
2. The blogger’s own IP address is not excluded from being blocked. The current IP is NOT automatically added to Firewall’s IP Whitelist as a part of the activation process, so bloggers can find themselves blocked from their own blog once Firewall is active.

WordPress Firewall is a great idea, but it’s code is not quite ready for real world use. Until then, Wassup users can check out “Bad Behavior” plugin as an alternative.

Like all other server-side (PHP-based) applications, Wassup does have an impact on your host server CPU usage. Your blog visitors, your admin activities, and your plugins all impact that usage. How much of an impact Wassup has has never been measured, but it is safe to say that Wassup’s CPU usage gets larger as it’s tables get large.

You can reduce the amount of load WassUp consumes by keeping your table size down (see Wassup->Options), by not using Wassup widgets (both in the theme and dashboard), by reducing the frequency of page reloads in “Wassup Detail”, and by viewing “Top Ten” lists and “Wassup-spy” less frequently. In the end though, it is your high visitor count that is impacting your CPU quota most, not Wassup.

You would probably benefit greatly from a caching plugin. If you install a page-based caching plugin like wp-supercache, however, WassUp will no longer work and you will have to uninstall it.

Boge, RT…
I believe you are typing an invalid URL address for your WordPress install.

It is easy to confuse web URL addresses with the real folder path (or ABSPATH) for your web account. Both ‘wwwroot’ and ‘public_html’ are part of a physical path to your files on the host server that look like ‘C:\users\your-user-name\wwwroot\wordpress-folder\’ on Windows or ‘/users/your-user-name/public-html/wordpress-folder/’ on Linux. This physical path up to and including ‘wwwroot’ (or ‘public-html’) is hidden from web browsers for obvious security reasons.

This means that after you upload WordPress files to your ‘wwwroot’ or ‘public-html’ directory on your server, the correct URL to install WordPress via the browser is ‘http://www.mydomain.com/wordpress-folder/wp-admin/install.php’. If the wordpress files are in ‘wwwroot’ (or ‘public-html’) itself and not in its own a subdirectory folder, then your install URL would be ‘http://www.mydomain.com/wp-admin/install.php’.

Good luck.

When I downloaded WordPress 2.8.2 zip package and tried to install it on a new site, all I got was a blank screen for step #2. Checking the code, I found that the included ‘wp-config-sample.php’ file is missing the php closing tag, ?>, from the bottom of the file. I added it manually to ‘wp-config.php’ and only then was able to complete the install.

I don’t know if this would fix your problem, but it fixed mine.

In answer to your question is YES, it is safe to downgrade to Wassup 1.6.x from Wassup 1.7.1.

Your problem is unique and never before seen by me…very odd because WassUp does not do redirection of blog pages. It is possible that your Wassup 1.7.1 files were corrupted. Before downgrading, you should try downloading a new copy of Wassup 1.7.1, unzip it, and manually upload it via “ftp” to your “/wp-content/plugins/” directory, overwriting the bad copy of Wassup 1.7.1 (if it is still there) and that could possibly fix the problem.

An upcoming version of Wassup will likely include “sort by: URL requested” in a selection of “sort by:” options. This should meet your need.