WebloginPE for Revo - Any thought's

Hi Allan,

The Revo modx_user_settings table is meant to hold custom settings for the current user (or any user). It’s mainly meant to contain settings that override the system settings (e.g. upload_maxsize, manager_language, default_template, published_default, etc.) for a particular user, but you could easily add new, custom "settings" like:

weight => 210
shoe_size => D

OpenGeek would have to comment on the advisability of storing WLPE-style custom fields as user settings. It might be better to add them as extra fields in the user profile table or in a new custom table.

With any of these methods, though, it should be very easy, using xPDO, to store and retrieve the data once you decide which table it goes in.

Hi Bob

Thanks for the info.

IMHO I would think it best not to just add extra fields to ’core’ tables.

I was thinking of starting by using the Database tutorial to add a new modx_wlpe_web_user_attributes table with the same fields as the existing modx_web_user_attributes table with possible additions.

I was wondering if it is possible (thinking in the night) to create a component to create a new database with required fields and then generate the required maps etc for xPDO.

Is there such a component already written

I see we already have the generator and manager for xPDO (shown in tutorial)

Once we have a database working in xPDO we can then start adding seperate components for ’login’ ’register’ ’update’
’delete’ ’profile’ etc.

My starting point would be the existing Revo components ’login’ etc.

How does that gell with you.

If I am going in wrong direction please feel free to point out my failures.

OpenGeek ang rthrash I welcome you comment.

Thanks to all who replied
Allan

Hi Bobray,

It might be better to add them as extra fields in the user profile table or in a new custom table.

Why not use the modx_user_setting table? Isn’t this table supposed to welcome custom setting for each user?

Creating another table like modx_wple_user_settings will do just the same: save custom setting with a key => value model.
I don’t really understand why it’s such a bad idea to use what’s already in place and drive it with a component.

Both approaches are valid, and I hope to see solutions using custom tables as well as custom settings.

Thanks OpenGeek

I am thinking of starting some developement work on this.

I was wondering about dir structures for dev work on Revo.

/wamp |
|-- www |
| |-- Revo
|
|-- Component1
|-- Component2

Component1 would be same as in Database Tutorial with all sub dir’s as storfinder.

Is that the correct structure please advise

Regards
Allan

One advantage of using the user settings table is that everything in there for the current user is available with a setting tag:

and in MODx snippets with getOption():

Hi Bob

So I could use


and all fields would be stored in user setting table is that correct.
ie I don’t have to create schema and corresponding mapping.

If this is so I have seen the light at last. Before I went to bed I was thinking what are they taking about.
This could mean that we need only create the fields we need for each application.
Sounds to good to be true.

Would you have any say on the dbtype and precision and possible index

Revo one small step at a time.

Just downloaded Revo RC1 off to install.

Regards
Allan

That’s right.

The key field is "varchar(50)".
The Value field is "text".

That means all the values are stored as strings so there’s no concern about precision.

It’s still complicated, though, by the fact that a lot of what you’d want to store is already in the user_attributes table. It’s wasteful to duplicate all that in the user_settings table, but it’s also a real pain the keep track of which info is in which table.

I don’t know if it’s practical to add fields to the existing user_attributes table on the fly, but it would certainly simplify things once they were there.

If you use the user_settings table, you might want to create the settings with default values when a user registers for the first time.

Then, they could be retrieved with something like this:

Thanks Bob

Just installed Revo RC1 to local server no problems

One small hitch in only packaged template Andreas01 Wayfinder call

should be

Where should I post failing not realy a bug.
Not sure where to post this may be bad for newcommers as no navigation.
But not a train smash.

I have been studing dbtables for Evo & Revo with regard to logins

Evo
modx_users_attributes.


modx_web_users UserId,username,password,cachepwd
modx_web_users_atributes other fields similar to modx_users_attributes
modx_web_users_atributes_extended user added fields by param’s.

The first db is used by manager login.

The others by wlpe.

Am I correct ?

Is there a reason why wlpe does not use modx_users_ attributes db ?

There seems to me to be a distinction between manager and web login is this necessary in use of dbtables?


Revo

modx_user_attributes


I have installed login package.
No tables have been created by instalation.

I have been unable to find in the code what dbtables login component uses

Could someone please advise?

If login uses modx_users_attributes it does not appear to use all fields in this table.

All modx_users_attributes fields seem available in manager.

Do we have the same distinction between backend and frontend users ie users and web_users in
Revo ?

Would it be easier to just update wlpe for Evo first by using PDO for database queries and splitting and optomising code into smaller callable snippets with a common database query class (PDO)

Regards
Allan

Queries to deal with a settings-type table can get really nasty; it’s much easier to simply create a flat table with fields according to the custom fields specification and deal with that.