Cam

Just sent you a reply with my results. Updating the thread here for historical purposes, and to show others that progress is being made. ??

Thanks Andrew.
I have updated the plugin, added the filter into my files, and everything is working great.

Thank you for the update and for the great plugin!

~Cam

Cool. Thanks!

A tiny additional piece of info you can use for testing:

The plugin I am using on yourls to allow hyphens is the one called “Allow Hyphens in Short URLs” by Ozh. I believe it is one of the plugins that is bundled with all yourls installations.

Thank you again for your help.

~Cam

Yes.

So for example my shortlink would be “yourls.com/3-4”.

The yourls installation has a plugin that will allow hypens, which I have enabled. (By default, though I’m not sure why, hypens are not allowed as characters, so my case is definitely more “edge-like”.)

Thank you for picking this back up.

~Cam

Thank you. I’m looking forward to what you are able to find.

~Cam

Thanks for asking. Yes, I am still using the WP registration instead of Buddypress form, as I feel it will be more stable in the long run and future upgrade-proof. (Fingers crossed)

I think I used r-a-y’s code to do this that is found over here, but I don’t remember specifically. If it doesn’t work (the first block), then reply and I’ll dig into my code and post it here.

Also I found out that, since I use multisite, the s2member login customizations only format the main WP site, and not login pages on sub-sites. I have moved away from using s2member to customize the login page design, and moved my custom CSS into a seperate mu-plugin that applies it globally to the log-in pages — network wide.

Hope this helps. I have not had any complaints or sign up issues that I am aware of since then.

~Cam

Update:
I could not replicate this behavior on a clean install using Paypal Sandbox. I did uncover that s2member and the plugin “Unconfirmed” (used with BP + Multisite) are not compatible. If you activate a user via Unconfirmed, they will not have any of their purchase details or privileges enabled.

For my install, to keep future purchaser’s happy and minimize the chance of being hit with bugs, I am staying with the WP registration, and have used s2member to style this page to match the rest of my website.

Tip: To really customize your page, add all your custom CSS into the “Footer Design” field of the “Login/Registration Design” section, wrapped with the tags:
<style media="all" type="text/css"> [css here] </style>
(You may need to add !important to some of your css declarations to override some other “important” rules.)

Since I am unsure the root cause of my bug, and cannot replicate it with a clean install, I’m marking this topic as resolved.

~Cam

UPDATE:
This definitely appears to be a bug with s2member + BuddyPress 2.0

A workaround can be found by disabling BuddyPress’ custom registration page and instead, using the default page.

Instructions/Code for disabling BP registration can be found here.
(If you don’t have a bp-custom.php file, see instructions here.)

Hope this helps.
~Cam
P.S. Still looking for a solution to the issue, but I hope that this will help someone else who may be experiencing this issue.

Thanks @storyman for the compliment on my simple script/plugin. It is unlikely to be a plugin that would slow down a site any noticeable amount because it is so small and targeted.

I agree with everyone about wanting to keep the number of plugins in use down to keep our sites running as efficient as possible.

~Cam

Note: My previous post was being composed before @hehafner’s post above it, which I just read.

Thanks @hehafner for the clarification and update.

Hi Guys,
I have been mildly entertained by today’s earlier discussion/debate. I don’t think any of us disagree that WordFence can do what it has been programmed to, but that some of us want a little more fine tuning on what it can do (myself included, as I made two optional implementation suggestions above that would satisfy what has been suggested).

For restricting usernames, definitely check out the plugin that @sgpark suggested: https://www.ads-software.com/plugins/restrict-usernames/ as it will have additional options that go above and beyond what I’d recommend WordFence get involved in. (That is unless the WordFence developers want to go that route.)

For blanket blocking certain usernames, I didn’t find anything too specific online, so I wrote up a simple plugin script. All the variables (i.e. blocked usernames) are in the code itself, so if you know a little bit of php, it should be very easy to modify to your liking. Also, if any more savvy programmers want to turn this into an official plugin, be my guest.

I don’t know how involved WordPress runs when trying to log in users, but this plugin is pretty light weight in that there are no WP settings or really anything added to the DB to cause bloat. One should use WP’s internal plugin editor if they want to make changes (or FTP + your preferred code editor).

Note: My code doesn’t “ban” bad usernames IPs or anything, it just sets up a brick wall that stops the WP Login process for the usernames in its list. Also, its priority is set to run between WP’s initial checks and WordFence so you won’t get WordFence generated emails notifying you when this plugin blocks a login attempt from one of the banned usernames.

For those of you who are interested, enjoy. ??
~Cam

Hi Mark,
I am adding my vote to support blocking specific “admin” login attempts in addition to the two current features of “Immediately lock out invalid usernames” and “Prevent users registering ‘admin’ username if it doesn’t exist”.

The main reason I see the high need for this specific feature is for those of us who are running communities of sites, and who don’t want to block legitimate users who cannot spell their own username. This is the only reason why I don’t have the current block feature enabled right now. In my mind, if someone legitimate wanted to try the ‘admin’ username, they deserve to be blocked.

There are two different ways I could see this being implimented:

1. Adding a checkbox selection to the list next to the other two features, and/or making it a radio button option for (Immediately block all invalid users / Immeditately block admin login attempts / Standard blocking).
2. Adding a textbox or text area where we could manually type a comma separated list of usernames to block. We could then manually type in ‘admin’ and any other username we would want to block. You could combine this with the registering restriction feature and say that usernames included in this field will not be allowed to register, and they will be immediately banned if someone tries to login to them if they are not a valid username. (Adding an alert if a valid username exists that is in this banned list would help keep banned and current usernames from overlapping.)

These are two ideas I see for solving the issue we are suggesting. If I were to pick one of them, I would choose #2 because it seems to be the more powerful and flexible of the two options.

Please reply with questions and/or other thoughts.

~Cam

I’m on PHP 5.3.27
It’s possible, but unlikely in my mind.

@chillysky — Adding to @amsgator’s note:
If you’ve updated to 3.7, did your blogs work then, and if so, have your blogs by chance been auto-updated to 3.7.1? It may have happened automatically, and you may have received an email about it.

Just trying to determine if this issue is 3.7 specific that becomes amplified by 3.7.1, or something that is exclusive to 3.7.1.

~Cam