Alvaro Degives-Mas

Hm… Is email being sent out at all by the contact form? With the rampant problem of spam (and botnets, and harvesters, and…) some hosting companies go to great lengths to ensure that the PHP mail() function is tightly regimented. Then, there’s also the possibility that the WP system sends email but the local MTA (the outgoing mail server) of your webhost is not trusting the script. Have had a few of those cases, too.

Also, triple check (and this can be tedious if you have a complex install) that all other plugins with email functions are set up properly, e.g. none is set to change email settings (like setting sender to a certain value). It’s really a pity that there’s no good “email management engine plugin” to act as the equivalent of an air traffic controller out there. There are very good SMTP plugins, but they are sadly very sensitive to other plugins mucking about the settings.

Finally, again: some hosts (sites) are simply not trusted by the big email service handlers (e.g. Gmail) so the effect is the same of email not going out: it simply never arrives at the destination, or is categorically marked as spam and deleted on sight. So, make sure your host (account) has the email server configured very tightly, e.g. look into setting SPF headers at DNS level.

If everything else works, i.e. all other plugins properly generate email really going out, and it’s really just Grunion misbehaving, I’ll bow out and leave it to the true Grunion experts. I’ve tinkered with Grunion and found that it works quite well, but that’s of zero consolation to you. Good luck.

Start by figuring out whether your WP install can send email to begin with. That is often where the problem is. Once you get WP to send email (e.g. new registration notifications) then Grunion Contact Form should in principle work also. Contact your webhost on how to properly address the mail server from PHP, then use those settings (perhaps you need a SMTP plugin). But the Grunion Contact Form is not likely the issue.

Since you mentioned a university, they often have a restrictive email address policy; i.e. if you want to tighten registration (new signups) for your site as restricted to only those with a given university email address domain – say, xxx@example.edu – you might want to look into a plugin that does that, for added security. The downside of course is that someone with a different email address will be SOL.

I suppose it depends on how you define “form text fields elements”…

There is no single plugin for the “secure” feature, just as (alas) there’s not a plugin for people to add a “happy” feature.

Security and WordPress is incredibly complex; out of the box WP is quite secure. If you want to tighten it more, start by studying the Hardening WordPress page.

If you want to shield off pages / posts based on access privileges (say, you create a separate “members” user group that can access those) you may want to think about User Access Manager.

Security, as I started out saying, is complex: you have to juggle and occasionally struggle to combine these three sometimes opposing factors: usability/functionality, performance, and security.

If what you want is to ensure that people can log in from unsafe places (say, open/unprotected WiFi networks) without sending the sensitive login information over open air, consider the Semisecure Login Reimagined plugin. However, please realize that the content of the page/post itself (e.g. sensitive data listings) will not be shielded from snooping eyes. That requires at least using SSL and that’s not as easy as it seems, even though the fantastic WordPress HTTPS plugin makes it a lot easier. You still need access to a valid SSL certificate and (ideally) a static IP for that.

Just remember: security is not something you switch on by adding a simple plugin.

Thanks, Frederick. It’s better to try and occasionally err on the way to improvement than to sit back and b*tch about the status quo… Still, I’m a little bit intrigued by the idea that there’s at least some tension between what you call “WP’s native behavior” and what I’d call “optimization”.

Obviously there’s stuff far outside WP’s grasp (i.e. the rest running on the servers) but it’s a bit of a troubling realization that performance is treated almost as an afterthought on self-hosted WP sites. It’d be nice if there were an extra quality label available for plugins and themes out there – somewhat like the energy impact label on electric household items – so as to point out the severity of the performance hit resulting from installing and using a given plugin and/or bad known interactions (“bad combos”) with other plugins. I guess that’s a noble pipe dream, though.

Of course, you as the developer of W3TC are just looking at the mess, and your effort in bumping up performance for us poor souls is still enormously appreciated. But as undoubtedly frustrating as it is to read variations of “your plugin doesn’t work” you have at least my word appreciating your effort, Frederick.

So: thanks again.

You’re mixing apples and oranges: controlling access versus security. What I mean is this: the WordPress Access Control plugin serves the purpose of letting you, as the site administrator, define how and which pages / posts are shown to certain members, i.e. it lets you set the access to the front-end of your site. So, that plugin doesn’t deal with access to (visibility of) the back-end of your site, i.e. anything that’s under the /wp-admin/ directory of your site. And because it’s a WP plugin, it deals with user access within the scope (direct control) of WordPress

On the other hand, applying .htaccess typically is done to control access to parts of your website (e.g. the wp-admin parts) as essentially a security issue. The key here is that .htaccess is not specific to WordPress or even PHP (the internal code “language” spoken by WordPress) but applies generally to anyone accessing the website: it works at the server level, i.e. (much) higher than WordPress. Therefor, if you set access rules via a .htaccess file (by requiring certain valid users and passwords) it is separate from WordPress users. In plain English: you’ll have users (and passwords) defined as “members” within WordPress, and separately from them, users (and passwords) at the .htaccess (server) level to access certain directories. Now, the thing with using .htaccess to password protect the /wp-admin/ folder (directory) is that anyone accessing that directory will be required to enter a valid .htaccess user/password combo. So for example, when a WP “member” user tries to access (to edit) his/her profile – usually via the /wp-admin/profile.php page – that user will have to enter basically two sets of credentials: one to login as a WP user, and another to access the wp-admin back-end.

This is why admins of membership sites have an extra complication when they want to harden their WP installation: they have to either fiddle with code to offer e.g. profile pages outside the back-end (e.g. via a specific page on the front-end) or accept the double credentialing issue, which few “normal” members will understand (and less so like, because it’s user unfriendly)

To successfully (and in a user-friendly manner) combine the two methods (not a bad idea) you’ll have to either make sure that your users (members) understand that they need two sets of access credentials to change their password, or offer a page outside the wp-admin area where they can change their password.

That’s why using a membership type plugin together with .htaccess restriction is hardly recommended, except for advanced admins / coders.

Now, your problem seems to be fairly limited, as you’re just interested in allowing your member users to change their password. That might be solved by resorting to another plugin; instead of the WordPress Access Control I suggest using the functionally somewhat similar but much more powerful WP Members plugin, which is also free. The reason I recommend that other plugin is that you can use shortcodes on “special” pages (access protected by the plugin, i.e. restricting it to certain members only) to let them change their profile information (or just the password).

Good luck!