redsand

Hey rockstaremperor,

I’m sorry to hear you’re having this issue, but I’ll be happy to help.

That’s an odd issue to have. There may be a configuration issue on your server.

Would you mind taking a moment to fill out a support request at our WordPress plugin Support Page? We’ll need to get a little more info, and email back and forth with you as we look into this. Thank you.

– Scott

You’re very welcome. Have a good one. 🙂

– Scott

Hi micsu,

I’ll be happy to answer your question.

That’s happening because your server isn’t configured correctly. It needs to either allow ExpiresActive, or disable the Apache mod_expires module.

The code in the plugin is already set correctly.

The plugin tests to see if the mod_expires module is installed, and it’s testing true…in other words…it’s installed on your server. That’s why that line of code in the .htaccess with ExpiresActive On is being run. (If the module wasn’t active, then it wouldn’t run.) Yet your server is set to not allow it. So, your server admin should either allow ExpiresActive, or disable the Apache mod_expires module.

You’ll need to contact your admin and have them make that change. Once they do things will function as they should, and you won’t see the error anymore. 🙂

If you have any further questions, feel free to get in touch with us at the WP-SpamShield Support Form and we’ll be happy to help you out.

– Scott

Hi ac1643,

I’ll be happy to answer your question.

No, you would not be correct in thinking that WP-SpamShield only needs to load on contact form pages. It cannot be removed from other pages for a number of reasons. It protects a lot more than contact form pages (please see documentation for full list of features). Also, remember that it is not just simple JavaScript…There are two layers of protection, so in addition to the JavaScript, it has an algorithmic layer. Things won’t function correctly if you stop it from loading as it’s designed to.

However, you don’t need to worry about site speed with WP-SpamShield. The plugin is extremely well-optimized already, and no further optimizations need to be made to it. I do realize that not all plugin authors keep site speed optimization in mind…but we definitely do.

Keep in mind that just because a script comes up on a list of scripts from an automated analysis tool labeled as “render-blocking”, that doesn’t necessarily mean it is actually slowing down your site.

Installing WP-SpamShield actually helps speed up a site on the whole.

We cover all the specifics in depth in two FAQs – please give these a read:

• Q: I’m trying to optimize my site for speed, and Google PageSpeed and/or Yahoo YSlow are telling me I should move the
  wp-spamshield/js/jscripts.php file to the footer. Should I be concerned about this script slowing down my page?
• Q: Will WP-SpamShield slow down my site, and is there anything I can do to optimize my site for it?

This will answer your questions in detail. 🙂

Let us know if we can help with anything else.

– Scott

Hi Mick,

You’re very welcome! 🙂

I’m sorry to hear about the issue you’re having and I’ll be happy to help.

If you haven’t had a chance to yet, please take a few minutes to work through the Troubleshooting Guide and FAQs, as these solve over 90% of issues users have.

Please take special note of Troubleshooting Step 15 as it relates specifically jquery and moving it to the footer.

From the Troubleshooting Guide:

Make sure that you have not moved jQuery to the footer. WP-SpamShield depends on this…

There is a possibility you could get it working by using Compatibility Mode. (No guarantees though.)

A few things regarding this:

• You’ll need to make sure that your site is actually loading jQuery.
• You’ll need to check your dependencies and script enqueue priorities.
• When you enqueue it in the footer, you really need to know what you’re doing.

Keep in mind that many scripts depend on jQuery. It’s risky to put it in the footer, and we don’t usually recommend it because most people can’t pull it off without breaking some code. It’s one of those things that really only people who know they can pull it off should do it, at least on a production site.

I understand you’re probably going for performance improvements. Site speed optimization is one of the things we do day in and day out for clients, so we know a bit about this. If you do what you can to reduce code bloat, losslessly optimize your images, use CSS sprites, properly leverage browser caching, use a minification/concatenation plugin and a page caching plugin, and use other good optimization practices, jQuery won’t be your bottleneck…so you may want to consider putting it back in the header. We’ve got some sites loading in .6 seconds with jQuery in the header. Just my two cents on that.

Hope that helps!

Keep in mind that we said Compatibility Mode may help those who make mods and move jQuery to the footer. No guarantees. When you make mods like that, the debugging is up to you. 🙂

– Scott

Hi marikamitsos,

You are very welcome! I’ll be happy to answer your question.

I understand your concerns completely, and please know that before we add each feature we always weigh the pros and cons thoroughly, along with doing a lot of research and testing, and getting extensive feedback. We don’t just look at one small sector or demographic…we look at the broad base of WordPress users, and try to determine what will do the most good, on the whole.

I’m glad you read my previous response on another user’s question about why we add those fields. I’m going to reiterate some of those points so the second half of my response makes sense.

The First Name, Last Name, and Display Name fields are an essential part of the registration spam protection that the plugin provides.

These are the same fields that are included in the wp-admin/user-edit.php and wp-admin/profile.php pages of your WordPress Dashboard.

I’m not sure why you want to turn these off. If you’re really serious about having real human users register on your site, you would want them to fill these out anyway, especially because the user would need to fill these out before actually using any features of your WordPress site, such as commenting, writing posts, etc.

Having new users fill these fields out when registering (as opposed to later on) is a proven method of helping to make sure only legitimate human users register on your site, and is one of several methods this plugin uses to prevent human registration spam. (Automated bot registrations are all stopped automatically by different methods.)

You mentioned:

The only reason being that we have a special “set of customers”.
Little students. Kids (some with special needs)
Their ages range from 10 to 16. They get quite confused and easily discouraged from singing up.

I can understand the special needs children having some issues, but the 10-16 year olds? Kids that age are quite intelligent and savvy, and should have no problem signing up on a website. Kids that age are using smart phones, complex video games, websites, and writing code.

With the special needs kids…I’m not sure I would leave them to sign up by themselves on website anyhow, since they do have special needs. It seems like someone should guide them through the signup process (with or without the modifications you requested), or there should be some extra guidance on the site to help move them along, such as graphical explanations, or even short video clips.

I mean since they have not even signed up and are completely unfamiliar with the terms, it is quite puzzling for them to grasp the difference between “Username”, “First Name” and especially “Display Name”. The last one throws them completely off the scale. Even their teachers.

The terms you’re mentioning are WordPress terms, not ones we made up. If you go into your WordPress admin and look at the user profile pages, these are the fields that fill in those values. That’s where all those field names come from. Sooner or later people are going to have to learn these terms…that’s just part of learning new skills…learning new terms. WordPress powers about 25% of all websites, so even though some terms may not be familiar to people at the beginning, it’s just something they will need to become familiar with as part of using the Internet. (If it’s an issue regarding a specific language, then this would be rectified as soon as we get a translation in that language.)

Barring special needs or language translation issues, I’m not sure I can see people legitimately having trouble telling the difference between “Username” and “First Name”. Many video games have sites where kids (well below 10) can sign up and they all have a “Username” required to access their account. “First Name”…I don’t see that being an issue, because everyone knows their own first name. “Display Name”…I could see being confusing to people new to WordPress, but then again, that is just a matter of educating your site users.

To me the real issue is that if you have users that have special needs or learning disabilities, I wouldn’t leave them to navigate WordPress by themselves without some kind of help or guidance in the first place. That’s really up to the site owner to create the necessary modifications for their target audience, to make sure they get where they need to go without trouble.

So, this doesn’t really seem like a plugin issue to me. It seems to be more of an overall usability issue for the site’s specific target audience. I say this…because even if we made the changes you requested, I’m pretty confident it’s not going to make the situation any easier for those truly having trouble registering for your site.

I do have some recommendations that I think would go a long way towards making things more user-friendly for your target audience.

Maybe have someone show the kids how to sign up, and guide them through the process. Some changes should probably be made to the login page to provide some guidance in case no one is around to show them. There are some plugins that let you modify your login page. I would add some guidance on how to use the registration page and possibly even create a short how-to video if it’s going to be an issue. As an alternative, you can also modify your theme (through the use of a child theme) to add said modifications to your login page.

Within the plugin settings, there is an option already to “Disable Registration Spam Shield.” This will disable the registration anti-spam protection and remove those 3 fields. (Anti-spam will still remain active for comments, pingbacks, trackbacks, and contact forms.)

As far as creating an option to simply remove those fields, we can’t justify doing that, as I’ve mentioned above, it would weaken the anti-spam protection. One of the things that sets WP-SpamShield apart from other anti-spam plugins is its rock-solid anti-spam protection. If you want weak anti-spam protection, there’s already plenty of other plugins that provide that. 🙂 <–I’m hoping you see that as humorous and light-hearted, not snarky. 🙂

So, I apologize for the long response, but I figured it needed a bit more explanation than the previous post. I hope this helps shed a little more light on it.

Keep up the good work with the youngsters. 🙂

– Scott

Hey chltx,

I hear ya…that’s no fun.

Ah, so the IP lockdown isn’t practical. Some sites it is, others it is not. Totally understand about the time constraints.

Glad some of those suggestions can be helpful.

Regarding contact form, it’s quite easy… all the instructions are here: Installing a WordPress Contact Form on Your Site

The main plugin documentation page is here: WP-SpamShield and if you scroll down to “Quick Navigation – Contents”, there are links to every subsection of the documentation, with answers to just about everything you could need. 🙂

(Also, in your WP-SpamShield settings page, there are links to just about documentation and support pages as well.)

Have a good one!

– Scott