WebloginPE for Revo - Any thought's

If you’re just trying to deal with user access to the Manager, you can just ignore it for the purposes of WLPE. Their access is controlled by the ACL entries created by the site admin. No user has access to the Manager unless the site admin explicitly gives it to him or her.

Thanks Bob

The documentation is starting to make sense now slowly. I did read it before I asked

I now know what a ACL is Access Control List.

I think it’s only when you try to use the documentation that it makes any sense otherwise it all seems so abstract.

I am sure I will have much more questions as I try and absorb this ’new’ way of doing things in Revo.
Please be very paitent as I am all too new at all of this.

Support from all has been a real plesure. Thanks again.

Thank *you* for all the work you’re doing. As I said, you probably shouldn’t worry about security at all at this point. You can always add a call to getLoginContext() later to see if the user is logged into the current context.

After spending time *fixing* WLPE and looking at the code for Revo ’login’ I think a lot of the functions that WLPE tried to accomplish have been provided for with ’login’.

When I first read lossendale’s post about using `modUserSetting` I realy did not understand what he was on about.

BobRay and OpenGeek showed us how elagant all built in tables for the user can be accessed.

I am not saying that all of the extra functionallity provided by WLPE is in ’login’ but we already have a Login Class and lgnValidator Class(which is extendable by using snippets or file system).

With the exception of extra fields that may be required by some developers. A lot of the work could be done by snippets with the necessary templates. I am thinking of ’Update User Profile’, ’Delete User Profile’, ’View User Profile’, ’View Users Profiles’ etc.

I am no sure but maybe @spittingred could say if this is so.
All that needs to be done is expand the `lgnRegisterFormTpl` to include the other fields in the database.

IF someone needs a registration system with no email address to validate the new user this can also be done. I am not saying this is a good idea but seems a requirement of many people reading old posts.

With regard to the extra fields required by some developers I am thinking along the lines of a program to :-
a. generate a schema file for the database from an input form
b. Run a build script to generate the class & map files required by xPDO using xPDOManager and xPDOGenerator.
This program could be used by other add-ons if a xPDO database is required.
As this would be a specialised case I am thinking of leaving that to last.

I would like to read your ideas

Regards
Allan

FWIW, I have decided to implement an additional field on the existing user_attributes table that will store an array of additional attributes (in JSON format to make it searchable and compact in the database). This will help meet most of the basic requirements that WebLoginPE provider for in the core. These fields will all be text fields, but it will provide a simple way to provide additional key/value pairs on the core MODx user profile.

There will likely still be demand for creating custom profile tables when those fields need to be indexed for quick searching or other specific requirements are not met by this simple additional feature. But it should help achieve most of what people need to do.

Thanks @OpenGeek for that info.

Awesome news, Jason! I agree that it will meet many basic requirements while still allowing for a lot of flexibility. Nice win.

@shaun/jason,

Great work so far on the Login Revo package!

http://svn.modxcms.com/docs/display/ADDON/Login