UserSpice 5.0 Roadmap as of 9/11/2016

[mudmin]

Here is some information from our internal documents to give you an idea of where we're going. These are just internal documents that Brian and I had for our own use. As things change, I will update this post and the date in the title...

Feedback is always appreciated

Big picture goals
Dan(a.k.a. mudmin)
-When possible preserve backwards compatibility and file structure.
-Write something we won’t have to rewrite in 6 months
-Provide better support for the international community. Even Canadians.
-Ideally US5 should be able to control a page with just 1 or 2 lines of code. Everything else should be optional.
Brian
-Focus time on cleanup rather than rewrite. I believe the bulk of code is good, but some decision making logic could be made more clear

New in UserSpice 5
- Multilanguage support
- Standard (easily replaceable) Bootstrap/PHP template including success/error check and display
- Naked UserSpice (or at minimum naked forms) - YOUR styling restyles UserSpice - You're not stuck with our branding
- Additional settings stored in the DB to avoid having to replace files to make updates work or to add features whenever possible.
- Autoload “plugin” system (similar to the class autoloading)
- Toggle for version check with UserSpice website
- Auto patch to latest release level (beta support?)
- Built in optional panel for announcements.
- Social media login plugins (To be at least Beta'd in 4.2)
- Built in pagination feature for user lists, etc
- Breadcrumbs/better navigation for admin section
- Password strength meter?
- Database prefix for better integration with existing projects
- Heavily promote use of SSL/TLS for securing communications containing username/password

Updated from UserSpice 4.x
- Cleaner CSRF token/validation
- Class/helper cleanup for consistent success/error messaging, variable naming, etc.
- PHPMailer/native mail improvements (streamline email configuration/defaults)
- Installation routine update to simplify/reduce pages/reduce options/etc.
- Updated user profile/admin page (looking to reduce page count for example)
- Improve page permission mass updates/handling
- Improve usersc/ functionality
- “Hands off” UserSpice core would be ideal. Define a place for custom functions.
- Timezone management (global server and per user)
- Update database structure to remove unused “reserved” fields
- Improve ability of designers to add tables or fields like plugins
- Updated password management, reset

[firestorm]

pickin up on the reserved fields, i noticed there are also quite a few custom fields i.e custom 1,2,3 in a couple of tables. i like the direction this is going, as i have been rewriting all the html to bootstrap std and removing the align attributes and replaced with bootstrap helper class's etc, im currently close to finishing my work on the install wizard and have moved the reCapture and copyright fields to the settings page to be stored in db rather than init, the db test button i renamed to save tables as it doesnt actualy just test the connection but infact saves the tables to the db. so it was a little misleading. i have also the save button renamed to save init. in the next step that was recapture is now general settings which store name, store url, owner email, username & password creation that updates those preset in sql.sql. in cleanup i may to just a nag to remind users to delete install files as it doesnt seem to happen automagically despite alerts say it has.

I have to say userspice outstanding. keep up the good work

[mudmin]

Thanks for the encouragement. I love what you've done with the installer.

The settings moving to the db is a great move I think. It will make for a lot less reason to edit the init file.

You're right about the test settings thing... my thought was that if I was going to test the settings, I might as well test by writing the code. If there was a problem with the test, an error would have come back...so it was KIND OF a test. haha. That was my first project ever writing files and checking server configs in php. Overall it's worked, but I love the updates.

[mudmin]

Oh and your install files aren't deleting? Hmm. I'd like to know more about why that's not happening. Every server is a little different on that sort of thing.

[plb]

As you move more Config items to the DB, you may have already thought of these items, but they were churning in my brain this am and I thought I'd throw 'em down somewhere:

• Having a multi-row config table rather than a single-row table with multi-columns allows adding new config items much more easily. And if they don't exist then code can provide an appropriate default.
  Code:

  $myValue = Config::get('myValue') : ? 'something';
  (Note in my pseudo-code below I just allowed an optional 2nd arg to Config::get() for the source-supplied default.)
  
• It would be nice if the primary/system config table drove the HTML form as a dynamically created form. Perhaps storing HTML snippets in the DB, perhaps having a separate config_choices table, perhaps a few columns which designate how to present this to the user, etc.
  
• One of those columns in the primary/system config would include whether users can override that pair. Then those overridable items could be presented (dynamically) in the profile editing section.
  

config
------
id
key varchar(100) # Life will be a lot easier for the developer if this replaces the usual id, but it's kind of non-standard to do it that way. Renaming the key in the future also becomes a bear. Probably better to keep with the standards
value varchar(500)
html_input_type defined(checkbox,radio,select,text,number,etc) # dynamically create the form from this (plus config_choices)
html_snippet varchar(2048) # This overrides html_input_type and config_choices
allow_user_override boolean

config_user
-------
id
user_id
config_id
key # proper db normalizing says no - probably stick with just config_id
value

config_choices
-------
id
config_id
sequence
value
label

Config::get($key, $final_default=false)
-----
Check in config_user if config.allow_user_override
Check in config
Check in Init.php $Config # if this still exists (probably makes sense to keep it for developer options rather than admin options)
return $final_default

Config::make_input_snippet(config_id)
-------
if config.html_snippet exists
return it
case config.html_input_type
'text': return "<input type='text' name='$key' value='$value' />"
'radio': query config_choices and loop through appending options
'select': query config_choices and loop through appending options
'checkbox': get the label from a single row in config_choices
etc

[brian]

If I understand your requests correctly, you have read at least a part of our minds.

At the start of US5, I toyed with the idea of using a config table with Key/Value pairs like you describe (or as I understand you are describing them) and this is what Wordpress does. It also allows plugins to define their own config settings without an extra table. Now, we shouldn't use it "just because" Wordpress and others are using it, but I know that isn't your motivation anyway. At the start of US5, since there were a few other things I wanted to clean up, that idea got tossed by the wayside for a bit. But now, we have quite a few more options in the settings table, and a key/value lineup would work much nicer in some regards. On the other hand, running an ALTER query to add or modify a setting isn't the end of the work, but it is still a schema change in the end. @mudmin is doing another project with some intense table work, and is (maybe) now also really getting the idea and value of key/value pairs. The downside to this is that we would need to redo all the settings through the whole application. BUT, I don't consider that necessarily a downside, since it forces yet another review of the code. That being said, it also requires some planning upfront for key naming schemes, a get/set API type blocks of code, etc. It all boils down to "we still want to consider it, though there are quite a few things that stand in the way that we would need to commit to".

Again if I interpret you correctly about the forms, that was also an idea that I had. If the forms configuration could be stored in the database, with either some predefined snippets or classes or even just functions, then people could fully customize and store that form configuration in the DB, maybe with some JSON for each field, which contains validation requirements, limits, etc.

Do you think I understand at least those two points somewhat? If not, feel free to expand as needed.

[plb]

Hmmm... I had forgotten about this conversation...

(1) Config - yes, you've understood what I'm talking about. I tend to think you wouldn't need to re-code anything except the Config.php class which will now look in the DB before it looks in the code or something like that.

(2) Forms - no, I wasn't talking about anything about a forms configuration generically. I was just talking about how the config/settings table would be edited. Or maybe that's what you're saying and I'm misunderstanding?

[brian]

Hmm, I think the trains of thought left the station a little while ago, for me at least. In general, I wouldn't mind picking up the modifications/features discussion again. I think most of the low hanging fruit I'm aware of has been addressed, though I've likely introduced some as well. As I mentioned elsewhere, I struggle now since I don't have a use case(s) in mind, and am lacking creativity to evolve the software on its own.

If there are some features you want to implement, then we can discuss them in detail, and I would be happy to take some that I believe I understand and run with it. At this point, you have been one of the most vocal, so the reward for that is pretty much that you get a good say in how some things might evolve.

[plb]

There was some discussion a while ago about a different implementation of usersc wrt forms. IIRC the place the discussion ended in my mind was with a bunch of identical files (perhaps even linked?) in users/ which did nothing except include from either users/bare_forms or usersc/custom_forms or something like that. Did that ever go anywhere?

Another option would be to have a single script (userspice.php?) in users/ and you would call it like this:

Code:

http://www.example.com/mydir/users/userspice.php?f=admin_user&id=3

userspice.php would BE just like those "identical files" mentioned above, but it would get the name of the form it was loading from the $_REQUEST['f'] parameter and do the include based off of that.

I'm not sure if this is an improvement or not - it avoids the redundant copies of an identical file, but makes things a little less simple/standard, perhaps...

Presumably it would be nice to have a configurable variable which contains an array of directories in which userspice.php would look for these bare forms. That would allow a developer to put their bare forms elsewhere besides mixed in with the userspice code. The Redirect() could then take advantage of this as well...

Which, since we're on the topic, the Redirect() could use some tender loving care. I had put in a suggestion a while back to avoid all these redirect problems (I get them all the time until I re-apply my fix). But standardizing on either an absolute or a relative redirect across the entire project and then making sure Redirect() works regardless of what directory we start in would be a nice direction for US5 to take in the near future...

[brian]

I think the forms discussion is something that needs to be addressed in a discussion about where UserSpice 5 is going (this is the right thread name, but I think warrants a much more detailed discussion to figure out where it is going. I do have a form builder that includes validation and can hold the values through the form display and submission, but at the moment the implementation is a solution to something, but I'm not exactly sure what. In the end, I think we want a UserSpice package that can be updated without worry of overwriting someones code during a semi-automatic update, people want to customize existing forms, and people want to extend existing forms as well as potentially supply their own forms.

If we limit the scope of UserSpice intervening only during sign up, sign in, sign out, and general permission handling, then we don't need to go too much farther, and we will limit the front end exposure of UserSpice. The simplest solution to that could be what I suggested before which was having a multi-step form, but that hurts the user experience. To this then, we need to address what aspects of the user experience we want UserSpice to be a part of.

Regarding redirects, in US5, the variables $abs_us_root, and $us_url_root are still present, but have been replaced throughout the code with the constants ABS_US_ROOT and US_URL_ROOT. I personally think that the method of using US_URL_ROOT with the redirect URL is the right way to go, rather than including US_URL_ROOT within the function itself. This would match the use of US_URL_ROOT in links, or other url access. In this manner, the redirects will work no matter where the page is located, as long as the link is supplied with the path between the website root and the file itself (which I think is prudent anyway). That said, I'm open to a specific discussion on how it *should* work, given some potential or likely use cases.