A small list of feature ideas

[tomdickson]

Hi, I've just recently upgraded from usercake to userspice. Outstanding job! Looking forward to the next development (where are those snazzy looking graphs by the way - are they hidden somewhere?).

I'm glad about the move to PDO and keeping userspice files clearly separate (my project already has a custom.css and font-awesome library which forced me to think during the last upgrade). These seem to be the most important to me personally.

Keeping in mind that usercake/userspice started as a 'base-level' that developers could modify, there are only a few things I could think of to suggest:

(1) configuring when recaptcha should be/shouldn't be applied: everyone seems to ask for disabling recaptcha, but there may be parts of a project that needed, and parts that don't. In my own circumstance, I have two forms for signing-up users. One is public, and the other is private (only available to a type of authenticated user). I would like to enable recaptcha on the public pages (public login and public sign-up) and disable on selected private pages (the private sign-up page).

(2) some easy configuration of the email activation or some more documentation on it. At the moment people need to hunt around for info how that works.

(3) allow administrator to trigger a password reset. I'd like the ability to prompt a selected user to change their password on their next login. This would be handy for a number of scenarios. In my case, my system has an 'executive teacher' that makes their class lists for 2016 in Dec 2015. They need to add a new teacher to the system before the teacher starts working at the school (they may only be starting in the school in 2016). So the executive teacher signs-up the new teacher in advance and then configures information about that new teacher's class. It would be great if the first login of the new teacher triggers a request for a password reset. (or some other solution to that long-winded problem)

(4) a nice upgrade experience: upgrading to userspice was ok, but two things stood out.

(a) The password strengthening experience. For a future release, could there be the option of a staged approach? E.g. stage 1: make 1 modification that prompts a password reset among the userbase (get the stronger password into the system), stage 2: administrator deals with those who have not strengthened their password with a manual process, stage 3: upgrade the rest.

(b) Integration into existing systems. The userspice system is great for the lovely styling with bootstrap and fontaweome. For existing projects that don't use these frameworks, integrating upgrades would be easier if a few 'bare bones' templates (sign-up, login) and the success/error messaging system was totally independent of the presentation/styles (e.g. currently funcs resultBlock is echoing out div tags).

5. Admin option to use email address instead of username (or allow username to be an email address?).

6. Adding, removing fields. Its not too hard right now, and I can understand why some hard coding is required.

Just some thoughts to help with your dev process. Great work and good luck.

T

[mudmin]

FANTASTIC observations, Tom. I need more feedback like this. It helps a lot when I'm sitting in my closet office (cloffice?) deciding what direction to go.

The snazzy graphs are in the blank_pages/special_blanks folder. Obviously they're just examples to steal code from at the moment, but that is some of the direction that we're going with the administrator panel for UserSpice 4 (and hopefully backporting into version 3 as well.

I'm going to try not to miss anything in replying to all of this stuff!
Being able to select your CSS files is definitely in the works and will probably even be a feature before US4 officially launches. It's not in the beta just yet, but it's coming.

1. Great feedback on the recaptcha. I just made a flag that turns recaptcha off completely which took an insane amount more logic than I ever thought it would. It has to do with the fact that each page calls recaptcha in 4 places and the checks are in nested if statements that didn't play well with the logic. I've also come up with another solution. I'm going to start providing "naked" forms...especially for the front end. The way I see it, the only things that really NEED to be accessed by the front end users are the login/register/user settings forms. (No one ever really "sees" the logout form. For those, I think I'm going to provide them stripped of all css/styling so people can get an idea of the bare minimum needed to login/register/update information and style in their own way. This will give the maximum flexibility. It wouldn't be that hard for me to provide the forms styled with the UserSpice system as well. Options are good. I might not even include them in the package, but as an addon.

2. I never touched a single piece of code in the email system. That was all purely UserCake. To be honest, I was afraid to touch it. haha. This is a screenshot for US4's email settings http://puu.sh/mWQk0/b4b316a471.png I'm basically making it work with nearly any email system on the planet and it provides a way to test your settings before you force users to verify emails etc. There is a second or two wait while the email actually sends, but overall, I'm pretty happy with it. It should work with normal free email that comes with hosting packages as well as all the fancy Mandril/Constant Contact Systems.

3. Absolutely. I totally agree with the force password reset. I have to think through the logic on that, but it should just be one more check in the login and that should be possible. I'm adding that to the todo list right now.

4. Ahh. Yeah, we got back to the idea of providing naked forms. That would help a ton. One of the things I love about US is that it's pretty agnostic as to what you do on your frontend. If it's php and contains the security check, US can manage it, but giving you a blank slate is really important. I'll work on that. I already have naked forms for US3, if you want them, let me know.

As far as the upgrade process, that was sort of the point of US 2.5 was to provide a bridge to US3 without forcing users to change their password and things like that. Over time the gap between US 2.5 and 3.x got a little farther than I would have hoped.

Regarding going from Usercake or US 2/3 to US4, I do have a plan for that. Included in US4 is Composer and included in Composer is Phynx, which is a database migration tool that will allow me to continue to evolve the database without (hopefully) breaking things. The neat thing about it is that the migrations keep piling up so even if, let's say, I make changes to the db in 4.0, 4.1, and 4.2 and you upgrade from 4.0 to 4.2, it will automatically migrate your database from 4.0 to 4.2 even though you skipped a step. I need to get US4 completely released and get the database the way I want it before starting that process, but once it's done, upgrades will be a lot more doable. People with existing projects should most definitely not upgrade to 4.0 until that's all worked out, but it's fun to play with.

I'm also not sure if you read the instructions on the password upgrade. There is a flag you can change that if someone enters a correct username and an incorrect password, it prompts them to change their password. That was kind of my hack-y solution to that issue. Let me know if you need help with that.

5. When I made the change in my code to use usernames instead of email addresses to login, I was AMAZED at how many things it broke in the system. This function calls that function but this one was expecting one thing. I made some of that more generic, so I will take a look at making that an administrator option. I think it will be a lot simpler now. I remember having a bad 4 hours when I was trying to figure out why something was broken. haha

6. Adding/removing fields. I made a walkthrough for this for US4 http://www.userspice.org/2016/01/16/regi...dd-fields/, but the one thing I am going to do is to make some "generic" database columns in the user table where you can ask for 10 or 12 more things without breaking anything during the upgrade process. They will just be columns that will be there for your own use. The US4 user table has a lot more columns now because it is preparing for being able to take payments, but some generic extras would be nice. You also always have the option of simply adding more tables that contain the User Id and US would never touch those.

Again, thank you SO much for the feedback. All of this stuff is going into my notes for further development.