• Fixed 36 vulnerabilities of version 3.7.3.1 (almost all holes, except two one). Including Insufficient Anti-automation hole – added CAPTCHA (from Register Plus, which was removed in Redux) and turned it on by default.
• Added option for autologin user after registration. Note, that in version 3.8.1 the autologin future was working. But after version 3.8.2 version, it is broken (for some unknown reasons).
• Added option for removing Confirm Password field.
• Fixed bug with saving user’s password at registration.
• Fixed bug with incorrect username in emails to admin and user at enabled option Email Verification or Admin Verification.
• Fixed bug with Require Agreement checkbox.
• Added option to send administrator an email after verification of new user.
• Fixed bug with user verification with using of verification code.
• Fixed 2 vulnerabilities of version 3.7.3.1 (last two holes).

This, with my own changes to data verification (esc_attr instead of stripslashes for example), a complete re-write of Register Plus Redux settings, support for WordPress Networks (which I still haven’t verified), and whatever other changes I forgot about along the way equates to Register Plus Redux 3.8.4. I still consider this unofficial, partly because I haven’t completely reviewed all MustLive’s changes, but mostly because I can’t vouch for my own changes since 3.7.

So where does that leave us? Well I’d like to get Redux back on WordPress proper, but I think I need help. I would like to take this from a one-man show to a team. I am looking for anyone who wants to contribute to keep Redux alive and growing. If you have contributed patches, or forked your own build, please, contribute. I’m not a glory hound, I want everyone to get the credit they deserve. I want to open up the repository, contributors can make changes and when we as a group feel like they have taken shape, we can branch off and publish builds. I can’t say I’ve ever worked in a group before, but there’s a first time for everything. We aren’t writing an operating system, I think this can be done, effectively, and relatively easily. Also, what to do with any donations, if they ever occur needs to be discussed. I would say split them equally among contributing developers, but that’s just my opinion.

If there’s anyone out there interested, let me know. I’m not going to lose sleep over the death of Redux, but I’d like to see it back out there benefiting the community.

Finally, here it is, Register Plus Redux 3.8.4, “There be Dragons Edition”.
register-plus-redux-mustlive

Take Our Poll

Take Our Poll

Maintenance Mode
Resolved in version 5.3 of Maintenance Mode
Was loading pluggable.php from constructor. Please refer to The Case of Maintenance Mode for more information.

Login with Ajax
Resolved in version 3.0b3 of Login with Ajax.
Defines its own wp_new_user_notification. Plugin now only defines wp_new_user_notification under certain conditions.

Absolute Privacy
Defines its own wp_new_user_notification.

Events Calendar
Is loading pluggable.php from constructor.

Mingle
Is loading pluggable.php from constructor. But not quite so bluntly, Mingle’s code determines whether it needs to load pluggable before loading it. There must be some calls that need to be moved around to get Mingle to stop loading pluggable. This could be traceable, but only by a dedicated Mingle user or developer. The root offending file is MngUtils.php located in the mingle\classes\models directory.

PDF24 Article to PDF
Is loading pluggable.php from constructor.

TDO Mini Forms
Is loading pluggable.php from constructor.

Cimy User Extra Fields

WP Better Email

However, today, two completely different users came to me with two completely different questions, and between the two of them, I realized I’ve been dealing with these conflicts all wrong; I should be reducing my dependency on wp_new_user_notification. I tried to do that when I first starting developing Redux, but at that time I couldn’t make much sense of WordPress’ complicated code base. My how things change over two months. I now see the error in my ways.

The following functions are executed in order when a new user registers:

func register_new_user (wp-login)
func wp_create_user (registration)
func wp_insert_user (registration)
-> action user_register (registration)
func wp_new_user_notification (pluggable)

Previously the user metadata was taken from the $_POST and entered into the database within a defined wp_new_user_notification. Because of this, our wp_new_user_notification had to handle conditions where no changes were made. This could lead to problems in the future should WordPress change their default message I would need to modify Redux to reflect that. Not something I particularly want to keep track of (not that I even know how). Upon digging around, I found the user_register hook that happens within the wp_insert_user function, which happens just before wp_new_user_notification is triggered. Now Redux more appropriately does its metadata entry within the wp_insert_user function and only defines a wp_new_user_notification function if the user has enabled any options that modify the user or admin messages. As of 3.7.0, the following options will trigger Redux to define its own wp_new_user_notification:

verify_user_email
verify_user_admin
disable_user_message_registered
disable_user_message_created
custom_user_message
disable_admin_message_registered
disable_admin_message_created
custom_admin_message

Therefore, anyone taking advantage of those options still needs to worry about conflicting plugins, but otherwise, many users should see fewer conflicts.

This is a great change for the better and it wouldn’t have been possible without feedback from Tevya Washburn and Theron Welch. Redux wouldn’t be where it is today without dedicated users willing to report their troubles, questions, and ideas. Thank you to all the users. I’ll keep making this plugin the best it can be.

[adams-form]