Problems, need help? Have a tip or advice? Post it here.
17 posts Page 2 of 2

And one more question please: is it possible to have an extra Login-page for administrators and extra one for members? Because, as far as I understand, either the original Couch Login page shows up (that I would like to preserve for Administrators), either the users/loing.php - that replaces the Couch page....

I suggest to use the same beautiful login for both members and admins. In case of admins, redirect them to their page, be it a dedicated page on website or simply a top-most template in backend <cms:redirect k_admin_link />.
Than, in the website I make, there are some older members who do not have e-mail address, and should be able to loggin - because there will be a member Area only for members....How would it be possible to solve this with one Login Form? And, even though I decided today, there is no need that members register themselves, how could that theoretically be solved, to login with the Username, because they are so complicated string of numbers? Or should in that case the administrator or the user be advised to change their username to an easier one, for the purpose of Logging in?

In Extended Users documentation, there is a code that puts a "<cms:random_name />" to a 'k_page_name' field. This results in a 'complicated string of numbers' which is a mere md5 hash of some random string. You are free to explicitly put a username there instead, or make that field in your form 'bound', so users type their desired usernames.

Also, the 'process_login' tag in login form expects 'k_user_name' field, which can be either username or email. Both will lead to successful login, so there is no problem with that.

A side note is that email is a mandatory unique field, so your oldest members should/must really get one. 'Forgot password' and Verification procedures require email to send user links to click and verify their requests to password reset / new registration.
And, how can I explain to my clients, why we have members in two places? I can imagine they would ask me "What do I do with this one and what I do with the another listing?"...

I will try to explain why this question should not bother you, really.

If you ever worked with Extended Folders, there is a similar setup with one template being completely dedicated to store editable fields for folders. Your clients will find it easy to navigate through system 'Users', since data is present in a table. Also system template offers a comfortable checkbox to enable/disable user, whilst extended template does so via publish/unpublish.

A side note, if you had a custom admin based off data-bound forms and regular html pages, it would best deliver for any kind of tailored experience. It seems so, that your customer can afford such improvement :) if he is so peculiar about having one page instead of two.

See, Default Admin Panel is best suited for holding data. That's why we have a list of countries in a separate template, for example, to relate cloned pages (companies, users, portfolio items, ec) to countries. To illustrate it better - a gamer doesn't have the best gaming experience in a powerful server's room, since it's best suited to fit servers over individuals. So, in my opinion, default backend is for best data storage, comfortable for data.

And for best admin's experience - to manage data, export/import, quick search/filter, grouped view (from various templates in one place) - a developer should prepare a good 'gaming corner', a separate admin pages in html that are best fit to clients expectation. With such setup, you may have user list the way you dream it to be.

As @trendoman tried to explain, normally it shouldn't be that difficult for clients to get the difference.

However, if you don't agree with that assertion, we can try to normalize things somewhat as follows (thanks to v2.0)

Broadly speaking, there are two points that are bothering you -
1. The same user accounts appear at two different places.
2. The field layout of the accounts are slightly different at both the places.

To fix the first issue, please place the following in your 'addons/kfunctions.php' file -
Code: Select all
// Exclude non-admins from the listing in users section
if( !$_GET['debug'] ){
    $FUNCS->add_event_listener( 'alter_render_vars_content_list_inner', 'my_alter_render_vars', -10 );
function my_alter_render_vars( &$templates, $render ){
    global $CTX, $FUNCS, $DB, $KUSER;

    if( $render=='content_list_inner' ){

        $route = $FUNCS->current_route;
        if( is_object($route) ){

            $tables = K_TBL_USERS .' as u, '. K_TBL_USER_LEVELS .' as lvl';
            $where = 'u.access_level = lvl.k_level AND u.access_level >= '.K_ACCESS_LEVEL_AUTHENTICATED_SPECIAL;

            if( $route->module=='users' ){
                // modify SQL for cms:query within the template to exclude non-admins from core users listing
                $fields = ' as id, as name, u.title as title, as email, u.system as is_system, lvl.title as level_str, lvl.k_level as level';
                $orderby .= 'u.access_level DESC, ASC';

                $sql = 'SELECT ' . $fields . ' FROM ' . $tables . ' WHERE ' . $where . ' ORDER BY ' . $orderby;

                $CTX->set( 'k_selected_query', $sql );
            elseif( $route->module=='pages' && is_object($KUSER) && $KUSER->users_tpl!='' && $route->masterpage==$KUSER->users_tpl ){
                $fields = array( ' as name' );

                // exclude admins from extended-users listing
                $rows = $DB->select( $tables, $fields, $where );
                $str_users = '';
                foreach( $rows as $r ){
                    $str_users .= ',' . $r['name'];

                $exclude = $CTX->get( 'k_selected_exclude', 2 /*global*/ );
                $CTX->set( 'k_selected_exclude', $exclude.$str_users, 'global' );

And now when you visit the core users section you'll find that it shows only the admin/super-admin/special accounts (i.e. skips all lowest level accounts that are created from the front-end using the extended template).

If for (perhaps debugging) you'd want to see all accounts listed here, add a &debug=1 to the URL in admin panel and that would remove this filter temporarily.

So now, the accounts are neatly segregated in two places -
1. All admin level accounts are in core
2. All lower level accounts (usually created from front-end) are in the extended users template.

I suppose this should be a reasonable distinction for the client to come to terms with without getting confused. What do you say?

Coming to the second issue (different field layouts), we can normalize that by using <cms:config_form_view> in you extended template.

Following is the full code of your template with the new configuration -
Code: Select all
<?php require_once( '../couch/cms.php' ); ?>

<cms:template clonable='1' title='MITGLIEDER'>
        If additional fields are required for users, they can be defined here in the usual manner.

    <cms:editable name='test_field' label='Test field' type='text' />
        config form GUI
                <cms:if frm_my_disabled='1'>
                    0000-00-00 00:00:00
                    <cms:if k_cur_form_mode='edit' && k_page_date!='0000-00-00 00:00:00'>
                        <cms:show k_page_date />
                    <cms:else />
                        <cms:date format='Y-m-d H:i:s' />
            #settings-panel{display: none; }
        <cms:field 'extended_user_id' hide='1' />
        <cms:field 'k_page_name' label="<cms:localize 'user_name' />" desc="<cms:localize 'user_name_restrictions' />" order='-7' />
        <cms:field 'k_page_title' label="<cms:localize 'display_name' />" order='-6' />
        <cms:field 'extended_user_email' label="<cms:localize 'email' />" group='_system_fields_' order='-5' />
        <cms:field 'my_disabled' label="<cms:localize 'disabled' />" group='_system_fields_' order='-4'>
                field_label="<cms:localize 'disabled' />"
                value="<cms:if k_page_date='0000-00-00 00:00:00'>1<cms:else />0</cms:if>"
        <cms:field 'extended_user_password' label="<cms:localize 'new_password' />" desc="<cms:localize 'new_password_msg' />" group='_system_fields_' order='-3' />
        <cms:field 'extended_user_password_repeat' label="<cms:localize 'repeat_password' />" desc="<cms:localize 'repeat_password_msg' />" group='_system_fields_' order='-2' />

<?php COUCH::invoke(); ?>

Visit the modified template as super-admin for the change to persist.
Coming back to the admin panel, you should see the cloned pages of the extended-user template display their fields as follows -
b.png (22.64 KiB) Viewed 1781 times

Compare that to how the core user account shows up -
a.png (22.37 KiB) Viewed 1781 times

Baring a few minor differences, I am sure you'll agree that both look almost the same.

Does this help? Please let me know.
To other questions, starting with "Why is ...?".

When someone asks 'Why', I consider it be a good reason to rise above less interesting questions 'How.. ?' and speculate over philosophy of matters. My previous reply had a similar flair, because any default backend is a mere representation of what's in a database, structured and designed best to show data put together in groups, with very little data-management options.

So, an honest answer to naming practices or matching fields with different names - it's because it is comfortable for data and data only. Also sometimes it is comfortable for @KK to maintain some older code compatibility - he knows that better, of course. Again, it was best suited for code or data, not end-users.

Think of how we should be thankful to @KK - 1. for the way we can quickly build a live php-based backend without knowing php. 2. for extensive tools that he created for devs - to change default backend and customize it up to some point (not very much) && build a completely custom backend with data-bound-forms, which would sit aside and cater to those with highest expectations about data-management experience. Really, some admins need only one page wot work with website.. so a dev can create it and user would never go to default backend to see all templates or options.

I clearly see how one can be angry about experience with default backend. But it's because one has grown out the initial requirement of having a cms and now demands even a better way to do/see stuff. This is totally welcomed! It really motivates one to learn more and get better with achieving utmost customer satisfaction.
Hello trendoman,
thanks jumping in for CVS export and import, and explaining your point of view, regarding the administration panel and two sections with member lists!!!!

Although I do not quiet understand your last post. I am not asking philosophical questions - just questions that would help me understand what I find confusing - so I cannot follow your logic about philosophy, which seems to imply something pejorative. I am also not angry and I cannot follow your thoughts here. I just need to understand what I am doing and also to give that understanding to the client if they require so. None of my questions was meant in any other way, and I am completely sure that KK understands my questions the way they are meant to be...

Thanks anyway for the effort to explain what I was asking for!
Hi KK,
thanks a lot :P :P for these extra pieces of code for hiding extended users from Core Users, and for customizing field in the extended user template...That looks to me now much more clear and not confusing indeed....I am checking that right now !!!!
I think what was confusing to me moved into the proper light now, also thanks to @trendoman!

KK - thanks a lot, as always, for your patience, responsiveness and friendliness!!!

17 posts Page 2 of 2

Who is online

In total there are 10 users online :: 1 registered, 0 hidden and 9 guests
(based on users active over the past 5 minutes)

Users browsing this forum: ewanmc and 9 guests