Change sitedetails setup

[torinfo]

I have started to work on changing sitedetails into a key,value kind of table.

'CREATE TABLE configdetails ( config_key char(255) COLLATE utf8_unicode_ci NOT NULL, value text COLLATE utf8_unicode_ci NOT NULL, description_key text COLLATE utf8_unicode_ci, mandatory smallint(1) DEFAULT ''1'', category char(255) COLLATE utf8_unicode_ci DEFAULT NULL, base64encoded smallint(1) DEFAULT ''0'', PRIMARY KEY (config_key) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci'

The idea of the extra fields is to be able to generate the management page to edit the keys:

decsription_key: A key in the language files for the management page description mandatory: whther the field has to have a value categoryM: for sitedetails fields, this would be xertem but I can imagine that plugins and modules can insert there own parameters in this table. category is then simply a way to organise the management page base64encoded Whther the field is encoded

You can also add fieldtype and pattern

For example for key AuthType I would like it to be a selection, with pattern "Guest,Static,Db,Moodle" etc.

Ideas and comments welcome!

[pgogy]

Easier to make a completely new table for when upgrading?

On 26 Sep 2013, at 19:56, Tom Reijnders notifications@github.com wrote:

I have started to work on changing sitedetails into a key,value kind of table.

'CREATE TABLE configdetails ( config_key char(255) COLLATE utf8_unicode_ci NOT NULL, value text COLLATE utf8_unicode_ci NOT NULL, description_key text COLLATE utf8_unicode_ci, mandatory smallint(1) DEFAULT ''1'', category char(255) COLLATE utf8_unicode_ci DEFAULT NULL, base64encoded smallint(1) DEFAULT ''0'', PRIMARY KEY (config_key) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci'

The idea of the extra fields is to be able to generate the management page to edit the keys:

decsription_key: A key in the language files for the management page description mandatory: whther the field has to have a value categoryM: for sitedetails fields, this would be xertem but I can imagine that plugins and modules can insert there own parameters in this table. category is then simply a way to organise the management page base64encoded Whther the field is encoded

You can also add fieldtype and pattern

For example for key AuthType I would like it to be a selection, with pattern "Guest,Static,Db,Moodle" etc.

Ideas and comments welcome!

— Reply to this email directly or view it on GitHub.

[JohnSmith-LT]

Remind me again why some fields were base64 encoded? I never quite understood that when i suggested this change to the table...

[torinfo]

@Pat, it is: (configdetails)

[torinfo]

@John,

You're right, we can just skip/change that when upgrading.

I also would like to get rid of some of the fields (like the form_strings and the play_edit_preview_query....)

[pgogy]

why are some base 64 encoded, because it worked when I did that, and it didn't when it wasn't

(think it was string escaping issues)

On Thu, Sep 26, 2013 at 9:32 PM, Tom Reijnders notifications@github.comwrote:

@John https://github.com/John,

You're right, we can just skip/change that when upgrading.

I also would like to get rid of some of the fields (like the form_strings and the play_edit_preview_query....)

— Reply to this email directly or view it on GitHubhttps://github.com/thexerteproject/xerteonlinetoolkits/issues/28#issuecomment-25201236 .

[JohnSmith-LT]

Ah ok, makes sense.

[pat]

Probably want to be careful when referring to each other with the @ prefix - best to use full GitHub names (and then I don't get all the notifications ;)

[torinfo]

@pat, Sorry I wasn't even aware GitHub did a name match to send notifications. Won't happen again (at least not by me...)

[pat]

No worries - it's a rare occurence on GitHub, though I have it happen a lot on Twitter :)