Hello,

Currently OctoberCMS does not add a user, who is not yet activated, into a default group upon registration. This is NOT EVEN done after activation.

I find it a must.

Do you plan to add this missing feature?

Can one use Location fields in the Plugin to update location drop downs in the user profiles? Even this would be helpful.

Hey, thanks for the suggestions. I appreciate it.

First off, you can find the feature roadmap in these two places:

• https://github.com/ShawnClake/UserExtended
• https://docs.google.com/spreadsheets/d/1_-f5fTYbRb5FWZ0BI2wF9xhEJMZtzMtFxh-4T_GWdXA/edit?usp=sharing

I think adding users to a default group upon registration is a great idea and I'll add that to the feature list when I get some time this afternoon.

As for the location feature, I'm not quite sure what you mean. Are you wanting to store the country of users?

Hello Shawn,

A possibility to have Fields based on Location Plugin. For e.g.: I refer to the image you made available under the plugin page. In there, i.e. in the image 3 and 4, one cannot see the location of the user or his friend, in which country/state/city.

Last updated 7 years ago

Hi there,

I thought I replied to this several days ago, but it appears it may not have gone through. I do recall your reply having much more content to it at the time, though. Did you still have questions about those other points which you made? :)

I will definitely try to add in the feature your requesting for the location information. The reason a feature like this hasn't been implemented, is that the RainLab.User plugin doesn't support this out of the box. As you mentioned, the location plugin adds this functionality. However, rather then forcing the location plugin as a dependency, I may look into supporting location when the location plugin is installed and simply not rendering those fields when its not installed.

Hello Shawn,

Thanks for your answer. Adding Location Plugin support, which of course should be optional, would be good for users of the Plugin.

I have removed most parts of my feature request because I have seen the coding and thought you would never want to invest time on extending these features. Although I still think that these features are inevitable for a Plugin like yours to have and it just adds a multi-dimensional profile feature.

I had made a feature request regarding profile tables that could be created for each profile types. Then the profile data could be stored separately in each table. With this system, many other plugins could use the data.

With this plugin, you are bringing all the field configuration into one field and data remains unmapped. I did not like this as it restricts its reuse by other plugins.

I do believe that the feature of separation of profile fields and tables is one of the very important feature. But I dare to say that you will certainly not want to implement this. I am not using your plugin, because if it's built-in restrictive possibility. Thus, I removed it from my feature request.

Sorry, I'm a bit confused on this part:

With this plugin, you are bringing all the field configuration into one field and data remains unmapped. I did not like this as it restricts its reuse by other plugins.

Could you elaborate on what you mean by this? I think you might be referring to the new settings feature I'm working on, but I'm not entirely sure. I will admit the profile feature is not fleshed out at the moment as I refocused my time on features I considered to be higher priority.

When I was designing the plugin I had to make a choice between making it quite strict or fairly general. I opted for the fairly general route. In terms of plugin reuse, I'm not sure if you are referring to the code level or the page level. If it's the code level, developers aren't meant to interact with the tables directly. Utilizing the UserExtended models and the UserUtil class is a good starting point for reusing user data via other plugins at the code level.

If you mean at the page level via twig, then the data is mapped via arrays. For example, in the beta release I'm working on, if you add the UserExtended.Account component to a page and on the page you do a twig call such as: {{account.user.email}} you will get the users email. Or, if you do a twig call such as {{account.user.surname}} you will get the users surname.

In terms of adding additional information fields for users such as phone numbers, addresses, zip codes, birthdays etc., you can do this in the beta release utilizing the settings component I'm currently working on. If you would like to reuse settings or extend this concept in other plugins, simply use UserSettingsManager class which is a part of the UserExtended plugin.

After I get to the stable release, the goal is to link settings with user groups. This would more or less accomplish a very similar result as to what you were describing with having different fields for different groups of users.

My memory was also jogged and I believe in your original request you were asking for profile templates for different use cases. This is something I will also look into as it is a good idea. That said, all twig partials (even plugin partials) can be extended to be customized to a users liking, so I'm not sure this is a very high priority feature.

Thanks, Shawn

Here's a quick demo of my progress on the settings feature from a few weeks ago: https://www.youtube.com/watch?v=e9Nspuo1qGQ

Since then, I've added the ability to generate some form fields for registration and changing settings.

Hello Shawn,

"I believe in your original request you were asking for profile templates for different use cases."

Not directly but partly yes. My earlier request mentioned to have different profile tables and to generate a profile page from that particular table. A part of this would be having a profile template.

But there are lazy ways of doing this. An excellent and first class solution would be to have different tables, which you are not doing.

You want to store everything in "settings" table. That's where we differ.

If there is some data somewhere in the DB, there are many ways of using it. For me, a first class solution is to have the data fields separate in different tables. But to do this, a developer requires to invest more time in developing.

I have seen the videos and read all about it. For my taste, this is restrictive.