helened

NewsArena,
The fix won’t be ready for at least a day.

You can stop this from happening right now by doing this:

Navigate to Wassup >> Options >> [General_Setup] tab
and under Statistics recording, UNCHECK Enable spam and malware detection on records and save settings.

Helene.

There is no way to stop autorefresh in “Current Visitors Online” panel (3 minutes auto refresh).

There are 2 ways to stop autorefresh in the “Vistor Details” panel:

1. To pause autorefresh: click the ticking countdown number before it reaches zero. This stops autorefresh. To resume countdown, click the “*paused*” message or just reload the page.
2. To stop autorefresh permanently:

• Go to Wassup >>Options >> “General Setup” tab.
• Under “Visitor Detail Settings” look for the option Set how many minutes wait for automatic page refresh:
• Enter ‘0’ in the text field and save settings.

Hi Michael

Wassup 1.9.1 with this fix is still undergoing beta tests. It will be out soon.

If you can’t wait and you are comfortable with PHP code, you can try edit Wassup plugin code to fix the preg_match error yourself:

• Open the file “wassup.php” in WordPress plugin editor by navigating to WordPress admin >>Plugins and click the “Edit” link below the “WassUp Real Time Analytics” plugin title.
• Find lines #2922-2923 (just a little over 1/2 way down the page):
  //#12 Exclude for 404 hits unless it is 1st visit or hack attempt
if($req_code == 200 || empty($recent_hit) || ($hackercheck && (stristr($urlRequested,"/wp-")!==FALSE || preg_match('/\.(php\d?|ini|aspx?|dll|cgi|js|jsp)|(\.\.\/\.\.\/|root[^a-z0-9\-_]|[^a-z0-9\-_]passw|\=admin[^a-z0-9\-_]|(?:user|author|admin|id)\=\-?\d+|\=\-\d+|(bin|etc)\/)|[\*\,\'"\:\(\)$']|administrator|bin|code|config|cookie|delete|document|drop|drupal|exec|function|insert|install|joomla|root|script|select|setting|setup|table|upgrade|update|upload|where|window|wordpress)/i',$urlRequested)>0))){
• inside the above “if” statement look for the word “administrator” and add a single left parenthesis “(” before it, ex: “(administrator|bin|” and that’s it.

  The corrected “if” statement should look like this:

  if($req_code == 200 || empty($recent_hit) || ($hackercheck && (stristr($urlRequested,"/wp-")!==FALSE || preg_match('/\.(php\d?|ini|aspx?|dll|cgi|js|jsp)|(\.\.\/\.\.\/|root[^a-z0-9\-_]|[^a-z0-9\-_]passw|\=admin[^a-z0-9\-_]|(?:user|author|admin|id)\=\-?\d+|\=\-\d+|(bin|etc)\/)|[\*\,\'"\:\(\)$']|(administrator|bin|code|config|cookie|delete|document|drop|drupal|exec|function|insert|install|joomla|root|script|select|setting|setup|table|upgrade|update|upload|where|window|wordpress)/i',$urlRequested)>0))){

  Don’t copy and paste the above code into the plugin editor because some characters won’t copy correctly and could cause Wassup (and your site) to crash. Just use your keyboard to edit the code.

Wassup 1.9 requires that you have the administrator capability ‘manage_options’ in order to update settings under Wassup-Options.
Please check that you are logged in under an account with that administrator privilege.
If you are already admin, try logging out of WordPress and then log back in to refresh your account roles and capabilities, then go to Wassup-Options and try update settings again.
If that still doesn’t work, please post here whether you have a multisite setup and what scheme your site uses, secure ‘https://’ or regular ‘http://’.

Thanks for providing your error details…and sorry that you are having trouble with Wassup 1.9.

It appears that the Wassup 1.9 update did NOT complete successfully in WordPress, but Wassup 1.9 activated, nonetheless. This is a bug in Wassup 1.9.

Though your site is down, your site content should be fine. Except for a single wp_options record (2 if using Wassup Widget), no WordPress data or files were impacted when Wassup updates. The update only affects Wassup’s own table data and files.

To restore your site and get back access to wp-admin, you must manually remove “wassup” folder from your “/wordpress/wp-content/plugins” directory:

• Login to your web hosting account then go to the CPanel (control panel) and open the “File Manager” or you can use an FTP client on your PC to connect to your web host.
• Navigate to “/wordpress/wp-content/plugins” sub-directory which is located in “/www_root” or “/public_html” or “/htdocs” folder on your host.
• Delete “wassup” folder.

You may need to refresh your browser a couple times to see your website after doing this delete.

Note that the old Wassup data is still around and you can install Wassup 1.8.7 to see it.
An update to fix the update bug is coming soon.

Thanks for reporting this. It will be fixed very soon.

Thanks for your very informative feedback. Hopefully it will be helpful to other users as well.

We weren’t aware that memory warning sometimes didn’t get displayed after an upgrade to Wassup 1.9. In your case, the disabled ‘set_time_limit’ function on your web host server is likely the cause of that problem too. Without the ability to increase the script time limit, a premature end to the upgrade script could occur…before the memory message is generated.

About that memory warning…40Mb is the minimum required memory for WordPress to run by itself (64Mb in multisite). Wassup can run with that amount of memory allocated, but only if there are few or no other plugins installed. With multiple plugins installed, 40Mb is just too small to effectively run WordPress 4 (with or without Wassup).