Scoop -- the swiss army chainsaw of content management
Front Page Everything News Code Help! Wishlist Project Scoop Sites Dev Notes Latest CVS changes Development Activities
User Prefs New Code
By janra , Section Code []
Posted on Sun May 16, 2004 at 12:00:00 PM PST
Well, I'm getting tired of waiting for somebody to test my patches so 1.0 be released before starting new development, so I say to hell with waiting.

Here is my plan for re-doing user prefs so they're easy for admins to customize and easy for developers to add to.

First of all, prefs will be accessed the same way they always have been: $S->pref('prefname') or $S->{prefs}->{prefname} (the latter is the old way; the former is the preferred way.)

'prefname' will be arbitrary and set by the admin via a new admin tool. All of the current preferences will be converted and will keep the same names.

A good chunk of the user table (sig, displayed email, homepage, bio, etc) will be moved to prefs. They are already loaded into $S->{prefs} so there will be little external difference. This is so what is displayed on the user info page can be customized... the PGP key can be removed, and new fields more appropriate to the site's audience can be added. (I know I'm not the only one who wants to get rid of the PGP key field!)

Each pref will have a name and a number of properties, all set via the prefs admin tool. The user can only set the preference value.

  • name The name of the preference as used in $S->pref('prefname')
  • title The display name of the preference
  • description A short description which will be displayed on the user preference page(s) giving the user information on what the preference does
  • long description a more comprehensive description the user can access by clicking some sort of "help?" link by the preference, if there is a long description
  • public Whether or not the preference is displayed on the user info page. Most preferences will not be public, because they are for configuration, not display
  • html Whether or not HTML is allowed in the field value
  • perm The permission the user must have in order to use this preference - blank for always on (eg, if the user doesn't have permission to use spellcheck, choosing the preferred spelling variant makes no sense)
  • var The site control (var) that must be true in order for anybody to use this preference - blank for always on (eg, if the site does not use spellcheck at all, it makes no sense to offer the user the choice of a spelling variant)
  • default The default value for this pref. This will replace a number of existing vars that set defaults
  • length the maximum number of characters a user is allowed to put into this field
  • regex a regex the user's input is tested against for validity. Blank to allow anything (the input is still quoted for database safety)
  • page Which "preferences page" the info will show up on. Like var and block categories, simply putting a nonexistant page name in this field and saving the pref is sufficient to create a new prefs page
  • field The HTML that will create the form element the user will use to set the preference. The form element must use as its "name" the name of the pref. Any HTML is acceptable here, including calls to boxes for more complex form elements such as drop-down lists with the current pref selected. The special key *value* will be filled with the user's current choice, or the default value if the user has not set this preference
  • order What order the preference is shown on a given prefs page. If two preferences have the same order number they will be displayed in whatever order the database returns them in.
  • template Which block to use to format this particular pref on the user pref pages. (Like box templates.)

It will be very easy for developers to add a new preference for a new feature. Adding a preference will be as simple as a single insert statement into the database, then the preference can be used just like all the pre-existing preferences in whatever code or box the new feature uses.

The preferences page layout will be moved to a block, so the admin can customize the layout. The different preference page paths will be consolidated, so that they are all accessed via /user/nickname/prefs/pagename (or /my/prefs/pagename) with pagename defaulting to "info" for what is now the preferences displayed on the user info page.

The only preferences that will remain hard-wired into the system are the "real email" and "new password" fields, both currently displayed as "protected settings" on the user prefs page. Their display, however, will be moved to a block (and probably their own preferences page).

< Comments: easy way to go one level up | Cherrypitter.com >

Menu
create account
faq
search
report bugs
Scoop Administrators Guide
Scoop Box Exchange

Login
Make a new account
Username:
Password:

Related Links
More on New Code
Also by janra

Story Views
  66 Scoop users have viewed this story.

Display: Sort:
User Prefs | 10 comments (10 topical, 0 hidden)
Sweet (none / 0) (#1)
by coryking on Sat May 22, 2004 at 01:35:08 PM PST

This looks cool!

What is the behaviour of a preference if the user doesn't have permission to set it?  Does it not display the preference at all (both on entry & display)?  What happens if a user looses permission to edit that preference?

Maybe (just thinking out loud) you could get rid of "public" and "perm" and replace with "edit_perm" and "display_perm".  the "edit_perm" defines the permission needed to edit the prefernce and the "display_perm" defines the permission needed to actually view it.  Again, just thinking out loud.

--
Cory R. King
xlan.org (scoop hosting)
photographica (pictures)



partly done... (none / 0) (#4)
by janra on Sun May 23, 2004 at 01:51:40 AM PST

Well, I have the user end of it done as far as I can tell; the only things remaining are cosmetic (namely, making it look pretty, indicating which preferences will allow you to put HTML in them, and indicating which preferences will be shown on your user info page).

I'm also trying to figure out how to handle showing the "long description" - if it'll be shown right on the page all the time, the description field is adequate, but I'm not sure how to handle a "click for more info" kind of thing. Popups? (shudder)...

I have almost finished writing the admin interface, too. Once I finish that, there's the migration scripts, then I'll submit it for testing.

Until then, if anybody feels so inclined, please visit my dev site, make an account, and try to make the userprefs stuff choke, whether directly on the prefs form or in how the prefs affect the rest of the site. And post a comment if you do, with the error message and/or a description of how it choked, so I can figure out what went wrong.

Right now, the prefs that are available are all the same as in the regular Scoop install. If you'd like to see a new pref with some unusual features (see the story above for details on what kinds of things I can set, plus I added flags for things that require trusted user status, and I split 'perm' into view and edit perms).

--
Discuss the art and craft of writing




Opinions wanted (none / 0) (#5)
by janra on Mon Jun 07, 2004 at 02:32:21 PM PST

I'm trying to figure out how to handle the comment display preferences (specifically, the "flat up to/nested up to/threaded up to" pref).

Right now, I'm down to two options: figure out how to handle a "multiple related but independantly set options of which one and only one must be a '+'" without having special case code in the pref handling, or simplify that particular preference to a simple selectbox so users can choose only one display mode.

Simplifying the preference has a few advantages. The current setup is confusing to many people. Simplifying it would make it easier for users to choose which comment display mode they want. Quite a few people get as far as figuring out that putting a '+' in one of the fields will get them that display mode and go no further, with more people still just not touching the fields at all (and sometimes complaining that the default display mode isn't to their liking). It would also be much easier for me to handle in the new userprefs structure.

Keeping the preference as it is also has an advantage - for those users who know how to use it. It really is very neat and very convenient for the display mode to adjust itself based on how many comments are shown.

At the moment, I'm leaning toward simplifying the pref, but I don't know how useful the current method is. I know some people do use it - but I don't know how many, or if the number of people who use it is high enough to warrant confusing the rest of the users...

So, I'd like to hear your opinions. How many people actually use the feature beyond a single '+' mark? How many are confused or frustrated by it? Do you think it's worth losing the flexibility to clarify the interface?

--
Discuss the art and craft of writing




assignment writing service australia (none / 0) (#8)
by Courteous on Thu Dec 01, 2016 at 11:44:08 AM PST

Thank you Janra for this pretty impressive post here at assignment writing service australia. It was good to know about your plan for re-doing user prefs so they're easy for admins to customize and easy for developers to add to..



Check Cashing (none / 0) (#9)
by Pervez on Mon Apr 02, 2018 at 04:41:01 AM PST

I truly loved your site. I've already been searching for much high quality info; however I usually accustomed to wind up getting rubbish. Right now click here Check Cashing Many thanks permanently work.



kitchen remodeling city of yonkers (none / 0) (#10)
by Pervez on Sun Mar 17, 2019 at 07:16:49 AM PST

Most people cost that you choose to build that brilliant posting that can help most people convey more familiarity with that matter. Unbelievable web-site! I'm just hence shocked to check out that. I truly treasured this content and also right after discourse. Now follow-up kitchen remodeling city of yonkers That is definitely 1 daylight of your deliver the results done!



User Prefs | 10 comments (10 topical, 0 hidden)
Display: Sort:

Hosted by ScoopHost.com Powered by Scoop
All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest 1999 The Management

create account | faq | search