Check out the release here! Feedback is needed and appreciated!

I'm working on developing an administrator panel that gives admins a one stop shop to a bunch of options and requested features. Doing something that sounds simple (i.e. turning recaptcha on and off) is often not simple at all, but I'm working on it. If you have a feature that you'd like to see controllable from the admin panel, let me know! Here's a screenshot of it in development.

http://puu.sh/mYdpA/9caf81b075.png

Hello

I am trying to only allow admin user to create new user accounts. I took a copy of register.php, and removed the line if logged in die. However when you create an account it doesn't work. No error, just fails. I have been looking through the User.php class as I guess the problem is in the userCakeAddUser() function or User class somewhere, but I can see where it might be.

I am a PHP novice, learning as I go!

Any suggestions appreciated!

Andy

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

The download for UserSpice 4 is a little bit over 3x the size of the one from UserSpice 3. I know that sounds like totally inefficient coding, but it's not...really. The core of the program is almost the exact size as US3, maybe a little smaller. All the extra heft is caused by composer. Some people have a hard time configuring composer, so I decided to do it for you. The good news is that those files aren't being called constantly, so it really doesn't affect the performance of your site.

Just the opposite, actually. The new code is much smaller and better written. Not perfect, but better. There are no more long php echoes that have to be rendered twice. The functions file is half the size of the old 3.x one.

So what do you get with composer? You get a VERY flexible mailing service that lets you use nearly any email technology. You also get database migrations. This is HUGE. Now, I don't have to be afraid to mess with the schema of the database tables as functionality expands. Users can simply "migrate" to the new setup.

If there are outcries over the new file size, I'd be happy to make a stripped down version that will be about the size of the old one.

To check out all that composer brings to the table, check out...
https://getcomposer.org/

Also, to get an idea of the thousands of php packages that are at your disposal now that you have composer, check out...
https://packagist.org/explore/

Is there a one-liner to disable the recaptcha? it starts to get in the way when doing multiple login tests...

When creating a new user group, with US3, you need to go through every private page to modify permissions. How hard would it be to create a feature for mass/batch modifying the permissions for private pages or a selection of pages?

I'm new to setting up US3, and I created a new permissions group, assigned a user to that group, then tried to login. The user can login, but can't logout because I hadn't given permissions for the new group to access private pages. Maybe something to look out for in US4?

UserSpice 4.0 is being tested on various server configurations as I write this. After some initial bugs are worked out, the installer will be included and it will officially be sent to the beta testers who signed up. There's still time to sign up in the menu at the top.

Once our beta testers have had a crack at it, we will go into a brief public beta while working out their bugs and hopefully be in a full release soon!

In addition to the documentation, don't forget to check out the walkthoughs. I'm going to try to make them for frequently asked questions that would get lost in the class documentation. I hope they help everyone.