if I am understanding you right, this is commonly referred to as "custom fields", that is admin-configurable fields with customizable type, defaults, descriptions and labels.

While this is incredibly powerful from a user's point of view and makes many otherwise complicated things really easy, it also affects the code base complexity significantly and may make it less intuitive for people who want to browse the db structure, likewise there are also potential performance penalties associated with truly dynamic fields, as fields would no longer be logically grouped into related tables, but rather into possibly unrelated tables, so that there may be a minor regression in performance if you compare classical db structures and dynamic ones, simply because there's at least one additional level of indirection added.
Nonetheless, it's usually considered worthwhile to add the possibility for custom fields to most php-based webapps, simply because it may reduce the overhead of code that would normally required to implement this functionality conventionally.

Yeh, so additional 'custom fields' would be used in this way, while keeping all the basic/required fields in the default structure.

So a example could be instant messengers for the user, or more info like birth date, eye colour, about you, hobbies, intrests, etc. While things like username password and all the rest would still be in the default table.

Making a plugin with this is good, and is what i will be doing, and will label it "custom fields" instead of "more info" like i planned to do (makes more sense). But it would be nice if this functionality was considered for integration with the core, instead of with a plugin.

The only design problem i can think of is data types. As the fields could vary between, string, int, date, whatever. So how would the design be done so we can support different data types without duplicating columns etc.

balupton wrote:

The only design problem i can think of is data types. As the fields could vary between, string, int, date, whatever. So how would the design be done so we can support different data types without duplicating columns etc.

A "type" column would take care of it (like you've said already IIRC).

Ok cool, didn't think that would actually work :D

likewise you'd then also have a separate table containing the various types, i.e. along the lines of:

//table "custom_field_types"
INT type_id
VARCHAR(64) type_name (i.e. string, date, number, text, radio button, checkbox, list,multi_select_list etc)
VARCHAR(255) description

and yet another table that contains the possible values for more complex types, i.e. :
//table "possible_values_for_custom_types"
INT value_id
INT field_id
VARCHAR(128) field_element

however, from a database management point of view, and also to properly support localization, it would be much better to completely have all VARCHARS in a translation table where each string is stored, along with a language flag-that way, things could be easily localized:

//table translations
INT item_id
INT identifier
UINT language
TEXT value

so that basically all strings used natively in the code, would be retrieved from the db, in order to facilitate for easy internationalization, even of custom fields-possibly from within the admin panel.

Ok, theres two different ways i can interpret what you said...

Have different columns for the value for each type, so field_value_int, field_value_text, etc.

Or just have field_value as text and then directcast it based on type (this would be a long if command yeh?)

balupton wrote:

Ok, theres two different ways i can interpret what you said...
Have different columns for the value for each type, so field_value_int, field_value_text, etc.

actually, I would say *rows* rather than columns, simply because each custom type would be represented on the corresponding table as a new row.

balupton wrote:

Or just have field_value as text and then directcast it based on type (this would be a long if command yeh?)

well, that wouldn't be particularly powerful and wouldn't even work that well either: think about a type "radiobutton" or "checkbox", where there may be an arbitrary number of configurable/selectable options, for example to represent the following using custom types:

Question: What's your favorite color

O blue
O red
O black
O pink
O grey
O green
etc

anything hardcoded would be pretty inflexible rather soon, so it would make sense to actually separate the types of custom values, as well as the types of custom value-specific options (which may be represented using lists, combo boxes, radio buttons, check buttons or whatever)

anything hardcoded would be pretty inflexible rather soon, so it would make sense to actually separate the types of custom values, as well as the types of custom value-specific options (which may be represented using lists, combo boxes, radio buttons, check buttons or whatever)

Yeh sure i already have made a hardcoded system that handles lists, etc as well. All i need is the database part of it now.

actually, I would say *rows* rather than columns, simply because each custom type would be represented on the corresponding table as a new row.

But how would the database be designed?

As wouldn't having seperate columns for each data type be wastefull (to me this is the only possible way, besides directcasting)

balupton wrote:

As wouldn't having seperate columns for each data type be wastefull (to me this is the only possible way, besides directcasting)

yes, it would be somewhat wasteful and also inflexible, that's why I proposed the above approach, basically you simply put everything into separate tables and link the info together using SQL joins, as in (without doing anything i18n related):

- custom_field_categories (i.e. name & description)
- reply_types (button, checkbox, radiobutton, combo box etc)
- data_types (text, number, date etc) - for validation
- response_options

So, in order to add a new category for a custom field, you'd add a name & description to the "custom_field_categories" table, which should have a primary key int field.

Then your reply_types table would contain various supported types of replies (as shown above) - these would mainly be set up by the programmer, as each individual control will have to be dealt with separately, whereas each individual row would also require its own index key

Then for data validation purposes you would optionally also have a data_types table with input types that you may automatically want to validate (mainly for the plaintext input)

And finally in response_options you actually associate everything by having columns that take keys for the previously configured tables, mainly: custom_field_categories.id, reply_types.type, data_types.type etc

Danny is 90% ready with a plugin for custom fields
We are in the proces of betatesting

:) You guys really should post about what your doing / planning to do ;)

That is what we need those custom fields for
for THAT project ;)

Haha fair enough, does the plugin come with a rendering system for data types, and handling of incorrect data, cause i'm in the middle of building my own anyway for my own projects. I just need the rendering system done, which i will be workin on this month...

Plus i was gonna do this myself in a plugin called 'More Info'...

Hopefully when that project does finish their will be less people working on the same thing unknowingly ;)

Don't ask me how the thing is done
it is danny/personman who works on it

For the moment it works, it just has a few minor issues and we/Danny are working on the skintags..

Scott and I, both no-coders, will set up the project
but for that we needed 3 plugins that are not written yet/were halfly build ;)
voting thing (more advanced that star-rating)
tagsplugin
custom fields

I thought stk/scott was a coder, he seems to be hacking away at things a lot...

Tagging i read is 70% done in your other post, custom fields is being done now. The voting thing i would assume is getting done as well...

I had sketches of a new voting/digging plugin around somewhere if it could be usefull, it's just design but may help out. I need it for one of those future projects that you plan to get out the door but never do.

And how do you guys find out what each other people are working on? What's the underground channel? I feel left out :( :P jks.

Oh and would the tags plugin replace the categories system? I was showing some stuff to yabba about a tagging/category system i did a long while back, may come in handy (if i can find it)

hello there,
sorry to get this old post from the past back, but I'd be very interested in this plugin that let you add custom fields in the user perfil and the post writing.
I searched in the plugins collection for both "More info" (as in your blog balupton) and "custom fields" but without ant luck. :'(

Could you tell me if there is something done yet?
thx, cu