Hi,

While I am studying how the XOOPS Core is built I got confused with the way XOOPS developers have structured the config tables.

We have the following tables:
config
configcategory
configoption


I would be thankful for an explanation of how does this works and what is the main idea for the config of XOOPS.

Thanks,
Mohammad

These tables used for storing module and core configs in database.
configs can be changed in:
xoops256/modules/system/admin.php?fct=preferences&op=showmod&mod=MID

and configs come from modules/MODULE/xoops_version.php
example:

config table:
the below information will be stored in config table:
conf_id: auto generate id
conf_modid: module id
conf_catid: 0 not used in 2.5x series but reserve for 2.6
conf_name: $modversion['config'][$i]['name']
conf_title: $modversion['config'][$i]['title']
conf_value: The value selected by user from $modversion['config'][$i]['options']. The default is: $modversion['config'][$i]['default'] which will be stored once the module is installed.
conf_desc: $modversion['config'][$i]['description']
conf_formtype: $modversion['config'][$i]['formtype']
conf_valuetype: $modversion['config'][$i]['valuetype']
conf_order: $i : number of config in the $modversion['config'] array

A side note about changing conf_value:
the conf_value will be changed only by:
1- install a fresh module which $modversion['config'][$i]['default'] will be stored(as i described above).
2- select by user (as i described above)
3- In update when formtype or valuetype was changed in xoops_version.php $modversion['config'][$i]['default'] will be stored.
A developer may decide to change the value by this trick!!!

configcategory table:
In 2.5.x only used by core and not used for modules. reserve for xoops 2.6

configoption table:
information comes from $modversion['config'][$i]['options'] will be stored in this table.
if empty($modversion['config'][$i]['options']) => nothing will be stored in this table.
As an example for this option:


Below information will be stored:
confop_id : auto generate option id
confop_name: _MI_USERLOG_ACTIVE (will be parsed to user own language)
confop_value: 1
conf_id: the linked id in config table.

Note: options only will be stored in install and update process.

To expand beyond what irmtfan has said..

(I have only looked at the 2.5 code and built a C# program that actually manipulates these values on my computer for a project in one of my classes. I have considered further developing it into a full blown utility but haven't had the time to do so yet. )

These config tables you mentioned are used by the core to automatically build menu options in the admin preferences menu for both the core and modules. When you install a module the values from the xoops_version.php file are read and any menu entries and options from that file are installed in these tables. Based on the values in these tables the core knows how to automatically setup the menu's and store values. Module settings can be retrieved via core methods.

By table I will explain their values. Please excuse if I am repeating what irmtfan already said...

configcategory - this table is a simple look up table that defines the different types of categories listed in the admin preferences menu. It is only used by the core.
The fields as listed:
confcat_id = auto generated and is linked to the config field conf_catid. This would be the key of the look up table.
confcat_name = this is the value field of the lookup table and is a language constant that is loaded from the language files for the language selected. This would be the value that you are looking up.
confcat_order = weight to list the values by but I don't believe they are used in 2.5 at all. If they were used the lower the value the higher the priority.

configoption - This is a look up table as well and is related to select config options. Normally a menu option is spelled out in the config table and the value is stored in the conf_value field. The configoption table defines the available options for all of the "select" type menu option. The value field listed above then contains the selected value that is listed in the confop_value field of this table. This table is also used in modules and is setup as shown by irmtfan above.
The fields as listed:
confop_id = auto generated number for the id. Not used anywhere else.
confop_name = language constant for the option to select in the drop down menu option. This value will be converted to the one listed in the related language file.
confop_value = this is the value to actually be store in the conf_value field of the config table.
conf_id = this value is linked to the conf_id value in the config table. All values in this table that have the same conf_id are selections in the related menu option.
Final note on the configoption table. This table has no relation to a particular module or category. This table is tied to specific menu options regardless of what they are used for.


Will continue for the last table...

config - This table is the meat of the menu options for the preferences. This table contains the values for all of the options. By use of this table and related tables it simplifies building preference systems and standardizes how they are done.
fields as listed:
con_id = auto generated and is linked to the field by the same name in confoption table if this option is a select option.
conf_modid = This defines what module this menu option is related to. If it is a 0 then the menu option is a core menu option. All non 0 values are related to a specific module with that module ID.
conf_catid = only used by core and used in relation with the configcategory table. Will be a 0 for all modules and non 0 for core options.
conf_name = this is the name to be requested when asking for the value of this option. It is also the name used in the form that the selections are made in.
conf_title = This language constant is the title of the option and will be converted to the proper language constant when displayed.
conf_value = This is the value that is stored by the system. Will be displayed as the default option when the menu is shown or returned as its value when requested.
conf_desc = Language constant of the description of the option. This will be looked up and converted to the proper language at time of display. It is listed under the title if it exists.
conf_formtype = type of form item to use to make selection. If this value is "select" then the available options will be read in from the configoptions table.
conf_valuetype = this defines the type of data to store in the value field. I believe this is used to help with validation.
conf_order = This is a weight based listing method. The lower the number the first to show. Values that are the same will be listed by place in database.

Hopefully between irmtfan and my postings you will better understand these options.

As mentioned this method is used to simplify the method of selecting preferences for xoops and any modules and to build a similar interface. As also mentioned any settings made with this system can be accessed via the core methods designed for this. Although the methods used to retrieve the settings is very simple I am unfamiliar with the specific call so I won't spell it out here.

Does these tables follow the EAV model?

Thanks for the detailed explanations.

Other than a 2 minute lookup of what EAV is I can't say that it is fashioned that way.

Really you could do everything with just the config table.

The configcategories table really only just gives the categories labels for the menus.

The configoption table is really just a sort of look up table for "select" menu options which helps make them more secure and forces specific selections.

@redheadedrod;
Very good explanations. Thank you.
If i knew you worked on this before I did not put time on it.
We need more tutorials like this.
I will link this topic to the "how to write a standard module" tutorial.

Quote:

It's ok, you added stuff I wasn't aware of and showed some examples I likely would not have in my explanation.

I was working on a project for a class and I told Mamba about it but I never got the chance to do much with it. I had to learn the menu structure in order to duplicate it. I was able to duplicate about 90% of it in C#. I hard coded the tables in my code though. The next step was to pull the information from a local MySQL database and the local file system. Then once that is working add FTP support and make sure the database connector would work with remote databases. I never got quite that far. I may play with it some but I really need to get my other projects done... Trying to resolve some computer issues that cropped up over the past week.

Rodney