[geeklog-devel] Adding "Core" Configuration Items

[Tom]

>>The last parameter is the tab to which the config value belongs. Note it
is not near the subgroup or the fieldset parameters as you would expect.

Yeah, I had talked to Dirk about that when I was integrating the project. In
the end we decided to do it this way to keep backwards compatibility instead
of adding a new wrapper function for adding config items.

>> Custom validation functions go here. They should be named
custom_validation_<rule name>. Return true or false.

Maybe for plugins we should suggest that the rule name be something like
custom_validation_<plugin name>_<rule name> to avoid duplicate function
names

>> public_html/docs/english/config.html:

>> Every new config parameter needs to have documentation added to this file
with appropriate anchor tag.

 

That is how core and the core plugins work (we kept it the same). You can
also use the regular tooltips as well. See
http://eight.pairlist.net/pipermail/geeklog-devel/2011-April/005457.html

 

Thanks for updating the Wiki.

 

Tom

 

 

From: geeklog-devel-bounces at lists.geeklog.net
[mailto:geeklog-devel-bounces at lists.geeklog.net] On Behalf Of Vincent Furia
Sent: August-10-11 3:31 AM
To: Geeklog
Subject: [geeklog-devel] Adding "Core" Configuration Items

 

Needing to add some configuration items, I noticed that there isn't really
good documentation noting all the changes that have to be done to add Core
configuration items. I'm going to write a wiki with a summary of all the
steps. But just so I know I didn't miss anything, here is the list of files
that need to be modified and how to modify them:

 

public_html/admin/install/config-install.php:

This is one of two locations where the "->add" config methods need to be
called. The parameters for the add function are well documented in
config.class.php, but I did note some items to watch for.

*	The second parameter is both the default value (also the initial
value) and can be an array.
*	If the 'type' parameter (3rd parameter) is 'select', the sixth
parater is an index (numerical) into the $LANG_configselects['Core'] defined
in the language file.
*	The last parameter is the tab to which the config value belongs.
Note it is not near the subgroup or the fieldset parameters as you would
expect.
*	The fieldset parameter doesn't seem to need to be set to any
particular value for adds of type 'tab', though by convention it seems to be
set to the first fieldset in the tab.

public_html/admin/install/lib-upgrade.php:

This is the second location that will need "->add" methods called. They
should be in the select statement associated with the current release that
the version you are working on will be superseding. You can copy and paste
the "->add" methods from the previous file, just be sure to replace "$me"
with "'Core'".

 

public_html/admin/configuration_validation.php:

This is where validation information is kept for configuration items. It is
not well documented. Here are the the list of pre-defined validation rules:

url

notEmpty

stringOrEmpty

boolean

inList

email

range

numeric

 

You can also define your own configuration rules, which get prepended by
custom_validation_ (see below).

 

public_html/admin/configuration.php:

Custom validation functions go here. They should be named
custom_validation_<rule name>. Return true or false.

 

public_html/docs/english/config.html:

Every new config parameter needs to have documentation added to this file
with appropriate anchor tag.

 

language/*.php

There are separate language arrays for config names, tabs, fieldsets, and
subgroups. There is also an array for selects as mentioned previously.

 

Please let me know if I missed anything.

 

Thanks,

Vinny

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20110810/34a80a38/attachment.html>