redsand

Today I saw there was yet another update so updated the plugin, together with a few other plugins that had an update and after the update I got the dreaded http 500 error. Entire site was down. By trial and error I discovered that removing the spamshield folder from the plugins folder fixed the problem. I CAN NOT have plugins like this just crash my entire site! NO MORE spamshield for me!

Hi @edwinov,

I really am sorry to hear that you had an issue.

However, I have to ask, why would you post a negative review without even submitting a support request first?

The issue you were having has already been fixed, in version 1.9.9.8.7.

We really do offer outstanding support. You should give us a chance to help you.

It is important for all plugin users to read the documentation. We ask users to take a few minutes to work through the Troubleshooting Guide and FAQs completely, as these solve over 90% of issues users have. If you need further help, then we are happy to provide support.

Please ask yourself this…When developers spend so much time developing free plugins for the WordPress community, is it really ok to post a 1-star review without making any reasonable effort to receive support? That’s simply not the right way to handle things.

If you have an issue with something, submit a support request first, and give the author time to respond. We provide free support for our plugins…all you have to do is submit a support request at the WP-SpamShield Support Page. We provide some of the best support out there.

You might want to take a moment to check out these two posts:

• There’s a wrong way to give plugin feedback on WordPress.org
• How to Leave a Good Bad Review

I would ask that you reconsider your rating, as it simply isn’t accurate or fair. It can be updated by going to: https://wordpress.org/support/plugin/wp-spamshield/reviews/#new-post

Reviews like this simply do not help the global WordPress community.

– Scott

Hi folks,

Just an update. We’re putting the finishing touches on a fix.

– Scott

Hi @chaoti,

I’m glad to hear 🙂 Thank you for the positive feedback!

That’s outstanding that you’re getting to make use of the new feature.

If you put define( 'WPSS_AUTOUP_DISABLE', TRUE ); into your wp-config.php, it removes it from the settings page altogether, and forces the auto-updates to be disabled altogether. This is good for developers with clients and multi-site owners who want to make sure that the client or end-user with site-level admin privileges doesn’t accidentally re-enable it. If you just need it on your own site, you don’t need to add that code to wp-config.php. In this case, or if you set define( 'WPSS_AUTOUP_DISABLE', FALSE );, the option will appear on the settings page.

Thank you. 🙂 We work very very hard to make sure no issues like this happen. Once in a blue-moon, it can happen despite the best processes. We always will work tirelessly to fix issues ASAP though. (None of us have slept much the last few days.)

If you want to re-enable auto-updates in the future, you are welcome to. Let us know if you ever need help again! 🙂

– Scott

• This reply was modified 9 years, 4 months ago by redsand.

Hi @abigailm,

I hear you.

Scott, it is tremendously helpful for other users of a plugin when these errors are posted in a public forum.

I think that’s true if the developer doesn’t provide direct tech support, or if the developer isn’t dedicated to problem solving. If a developer is content to leave odd issues or quirks in place, then forums can be helpful so workarounds can be created.

The best though, is when the developer has an intense commitment to solving problems (like we do). In that case, using forums for tech support is much slower, and can create a lot of confusion. Also, posting tech data and logs to forums is not a real secure option. When doing support directly, logs and system data reports can be sent to the developer tech support, and issues can be resolved more quickly.

@abigailm, @darkwolf:

Just to give you a little background: People don’t realize it, but we literally won’t sleep until issues are resolve. You may notice that some of our tech support responses occur at all hours of the day. Our tech support team gets alerted via IFTTT (and a number of other methods) on our phones (and computers, etc) when a new support thread is posted on the forums, or when a new support request comes in.

We have WP_DEBUG running 24/7 on every site we manage, and on our test servers. We have scripts running around the clock that report to us every time an error shows up in the log files. We also get IFTTT alerts (and other alerts) for these within minutes of these.

We run every new release through tough pre-flight debug regimen. I’ll be happy to break that down in a blog post later on. Even with the best process, there can still be issues for a certain subset of users, due to the variety of site configurations.

@darkwolf: If you would like immediate relief, you can comment out the following line in the wp-spamshield.php file that have WPSS_Utils::append_log_data. Lines 2642, 7323, 7393 are the only ones you would need to edit. Just add “//” to the beginning of the line. (To anyone else not familiar with editing PHP files, just make sure you’re using a text editor like Notepad or Notepad++, and don’t use any Microsoft, Office, or word-processor-type apps. Also, always back up the original file first.)

We’re moving the append_log_data() function into the main file in the next update. It’s an upgraded version of the function that was previously in the main file. It was initially moved to the WPSS_Utils class, but that’s been an issue on some servers due to the firing order. Unfortunately including the WPSS_Utils class before rs_wpss_getenv(). runs creates other bigger issues. That’s part of the rub.

Here’s a bit more of an explanation, @darkwolf:

Particularly the info we need is an RS System Diagnostic Data report. If you want to install it, and post a link to the temporary report URL, you can do that. (When you change the URL, it will disable the previous URL.) We have to put together a pattern of the characteristics of the affected servers so we don’t cause issues on these in future updates.

As I mentioned above, there’s a bit more to resolving an issue than the providing a line with the error message. It only occurs for a limited subset of users, so we have to run backtraces on which function is called in which order, and under what conditions. If we don’t get all that locked down, then even if we change the line with the error, it may not fix the actual issue. We also have to make sure that the fix does not create a new issue.

Asking us to basically “just fix it” without providing any real diagnostic info about your setup…doesn’t get us anywhere. Of course we’re running our own tests, but if users can get us diagnostic data, we can narrow down the specifics a lot quicker.

Some of this may seem unnecessary or redundant, but we ask users to do the following:

1. Work through the Troubleshooting Guide and FAQs. Even if you can just skim through and run a mental checklist, this is important.
2. Check for known conflicts. This will help rule out any known issues.
3. Submit a support request at the WP-SpamShield Support Page. In your support request, if you can provide any error logs, please include those (it’s best not to post them on forums). It’s even better if you can provide data from RS System Diagnostic Data plugin in your support request, it will expedite things. (The form is secure and encrypted, so that’s another reason why this is a better process.)

I realize this can be annoying or frustrating, but we just ask our plugin users to keep in mind there are far more plugin users than there are of us, so if each user can take a few minutes to work through these guides before submitting a support request, it allows us to solve support issues much more quickly. The process works, and we always get to the bottom of the issue, it’s just a matter of how quickly. The more info you can provide as a plugin user, the quicker we can solve things. Thank you!

– Scott

• This reply was modified 9 years, 4 months ago by redsand.

@abigailm,

I realize that I may not always express it, I do genuinely care about every single one of our plugin users. Most of the time, I’m pretty blunt, and I can often be overly business-like, and that can be misinterpreted by those who don’t know me. If we interacted one-on-one, I think it’s easier to see the context. We do not want you to be frustrated. We felt that we were being professional, but if that didn’t come across, then I apologize. I also genuinely apologize for any miscommunication or further frustration.

We will keep your thoughts in mind. 🙂

Again, thank you for heeding my suggestion…. the check box in the settings page is exactly what I wanted to see and resolves my concerns and frustrations.

You are very welcome.

I hope you enjoy the new feature. There is even a further step that you might like. If you have client sites, and you don’t want the client to have the option to auto-update, if you define a constant in wp-config.php, the plugin will not only disable auto-update, but it will even remove the option from appearing on the settings page.

Just add the following code to the wp-config.php :

define( 'WPSS_AUTOUP_DISABLE', TRUE );

We felt this additional setting would be useful for developers with clients and multisite owners.

– Scott

• This reply was modified 9 years, 4 months ago by redsand.

Hi @liddika and @tierten,

I’m sorry to hear about the issue you’re having on your site.

We do test everything out on a variety of test servers, PHP versions, and hosts, but there are certain configurations that may trigger something that another does not.

Right now this issue does not seem to be affecting a large percentage of users, but that doesn’t mean we aren’t looking into it. We have been, and will continue until the issue is resolved. We do take each report seriously, no matter how many users it affects. Please know that.

There’s a bit more to resolving an issue than the providing a line with the error message. It only occurs for a limited subset of users, so we have to run backtraces on which function is called in which order, and under what conditions. If we don’t get all that locked down, then even if we change the line with the error, it may not fix the actual issue. We also have to make sure that the fix does not create a new issue.

You can help us solve it quickly if you can follow a few steps.

Some of this may seem unnecessary or redundant, but we ask users to do the following:

1. Work through the Troubleshooting Guide and FAQs. Even if you can just skim through and run a mental checklist, this is important.
2. Check for known conflicts. This will help rule out any known issues.
3. Submit a support request at the WP-SpamShield Support Page. In your support request, if you can provide any error logs, please include those (it’s best not to post them on forums). It’s even better if you can provide data from RS System Diagnostic Data plugin in your support request, it will expedite things. (The form is secure and encrypted, so that’s another reason why this is a better process.)

I realize this can be annoying or frustrating, but we just ask our plugin users to keep in mind there are far more plugin users than there are of us, so if each user can take a few minutes to work through these guides before submitting a support request, it allows us to solve support issues much more quickly. The process works, and we always get to the bottom of the issue, it’s just a matter of how quickly. The more info you can provide as a plugin user, the quicker we can solve things. Thank you!

– Scott

• This reply was modified 9 years, 4 months ago by redsand.
• This reply was modified 9 years, 4 months ago by redsand.

We’ve got a fix in the works.