Would like to add code to allow login and registration to have separate logos. Also, would like to better integrate with WordPress’ media library, currently files are uploaded to the same location, but are not visible from WordPress’ media library. Should use the same interface as adding an image to a post or page.
When an admin adds a new user through user-new.php none of Redux’s required fields are shown, of course an admin isn’t tied to the same requirements as a regular user, however, I would like to tier it, a true admin can add a user with or without whatever fields they want. An editor or such that is allowed to create users but is not a system admin will be required to enter the same fields as a new user. Also, user-new.php doesn’t check if a username already exists, this can be a problem with the unverified user queue.
An uninstall sequence would have to ask if you want to preserve all the metadata created by Redux. This would tie into my idea for a metadata browser, since the uninstall could trigger a metadata browser session with the metadata visible so that the user understands the repercussion of deleting that data. Of course if the user never created metadata it wouldn’t even trigger.
Create a widget that enables users to register without having to visit the registration page. This only works with a simple form, like, username/email address only. Someone else might have already created this, but I can’t imagine their implementation would be compatible with Redux.
Old request from Register Plus was to have user redirected to a particular page depending on which invitation code they used. This has great potential but can’t be implemented until I get the redirect working.
Another improvement in my mind would be to create a page where you can see view the users based on which invitation code they used.
Another idea, group page that users can check to see other people that used the save invitation code. There could be a setting on each invitation code, private, if the code is set to private that groups members will be kept private from other users, if not set then a group page would be accessible for that group. I see this being a link on the users profile page that links from their invitation code to the group page for that code. Neat feature. For example, should a teacher create a blog and give different codes to different classes, the classmates can see who else registered from their class.
A neat feature might be to track the date the user accepted the disclaimer, or license, or whatever. Right now that seems pointless since the date will match the date registered, however, with a future feature, we could push a new disclaimer and based on the date of when the user agreed to the disclaimer show them the disclaimer when they logon. If they refuse to agree they will be booted out of the system. If they agree the date of agreement will be changed so that the cycle can start all over again should the admin wish to update the terms again. This creates a new class of user, not quite unverified, but un… informed? I’m not sure, there could be another page added that let’s admins purge users that haven’t agreed to the updated terms, or send these users notification that the terms have been updated. It’s a bunch more code, but might be useful to someone.
Not all disclaimers need a checkbox, add option to enable/disable the accept checkbox.
UPDATE 10/21/2010: Added this feature in 3.6.20
Biggest issue with this feature had to do with the Settings Page behavior. Normally, when savings the settings, I create a new array with all the settings from the settings page. If a setting is blank, I don’t save it, subsequently when something checks against that setting a blank is equivalent to it being unchecked. This conflicts with the behavior of the default settings check. The default settings are checked to ensure any new, or renamed settings are available to the admin. However, when the default settings is enabled, and we saved the setting as disabled (effectively deleting that setting), the default check sees this as a new settings and adds it back, enabled.
I dealt with a similar issue when saving the custom fields which are in a series of arrays. I still haven’t gotten that working perfectly, but the method I used there will work perfectly in this scenario. Now when a setting is saved, if it has a value (checked) it saves that value (1), if it does not have a value (unchecked) is saves a null value. The null preserves the fact that yes, we intentionally disabled this setting, and stops the default check from reloading the default value. In fact, I believe I will rewrite all the settings to save this way. It’s much more logical. Interesting how the smallest features create big changes.
skullbit’s datepicker code is so disgustingly outdated, and oddly enough, no one cares. I saw a few mentions about this on the Register Plus forum, but not a lot of complaining. Well, ok, I want to fix it, because I expect to have all the same functionality as the original Register Plus, but this isn’t a huge priority.
UPDATE 10/20/2010: Completed for 3.6.20
There’s a few caveats, first off, Datepicker doesn’t currently feature any of the customization Register Plus had. Secondly, I didn’t add any i18n. I’ll deal with either of these issues if/when someone asks for them.
The hardest part of implementing this was adding the datepicker to the user-edit and profile pages. I eventually figured out how to isolate the admin-head to those pages but it was far harder to research then I expected. I’ll have to write something up for future reference.
Just a quick update. I am looking to release one final 3.6 version with jQuery working in browsers other than Firefox (done), the jQuery Datepicker working (done), and one final enhancement, an option to turn on/off the accept checkbox for the disclaimer, privacy policy, and license (done). Once those features have baked for a week I will finally release 3.7 with i18n, l10n, f-u-n, etc. That will mark the end of Register Plus to Redux. Following 3.7 I will add WordPress MU and MS support. I’m currently working on that, but I’m going to put it on hold for a day or two to get 3.7 out. Also following 3.7, but perhaps not 3.8 I am going to rewrite the settings page. After reviewing a competing product I find Redux a little bit wanting in both ease of use, and power. A working framework is fundamental though, so 3.7 will stay pretty much the same, followed by 3.8 with some new features, and 4.0 rewritten from scratch to satisfy all your friends and family.
Also, I’ve mulled over the issue of charging users to register. I don’t see this on the immediate roadmap, but I think I’ve found a compromise I can live with. This will be a paid feature, I haven’t figured out all the logistics of it, but I’ll probably create a little addon that enables the feature. As of yet, this will be the only paid feature I write. I write WordPress plugins to improve the community, to give something back to all the other generous coders out there making valuable websites and other plugins. My heart isn’t it to charge people for this plugin, but, I can see the value of this feature and I want to provide it to my own exacting standards. The way I see it, if you are going to charge people to register, you can pay me to charge them. The only thing I really need to figure it out is how much should I charge? It definitely won’t be anything exorbitant, I’m thinking $10-$20. I’d welcome anyone’s opinion on the matter, for or against charging, cost, implementation, whatever.
In the meantime, look forward to a little stability. It’s time to take this stuff seriously, people are actually using this plugin for professional sites, I want a professional product for them, and myself.
