Welcome to Geeklog, Anonymous Thursday, March 28 2024 @ 09:26 am EDT

Geeklog Forums

Reading original manual $_CONF values


Status: offline

LWC

Forum User
Full Member
Registered: 02/19/04
Posts: 818
Up until v1.5b1, any dynamic change to $_CONF changed the default value too (for that session). Is there a way for a plugin to read their original manual values? That is, the values that are manually stored in config.php?

v1.5b1 stores static $_CONF values in the database, so it's as easily as, for example:
Text Formatted Code
$default_language = unserialize(DB_getItem($_TABLES['conf_values'], "value", "name='language'"));


But I don't want to make v1.5+ a system requirement for a plugin before v1.5 is even official.
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Text Formatted Code
if (file_exists('config.php')) {
    require_once 'config.php';
} else {
    $my_config = config::get_instance();
    $_MY_CONF = $my_config->get_config('myplugin');
}

bye, Dirk
 Quote

Status: offline

LWC

Forum User
Full Member
Registered: 02/19/04
Posts: 818
But I want to re-capture just one specific (Geeklog's own) config.php parameter. How is it done in v1.4.1?
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Hmm? As a plugin, you can always simply use $_CONF. It's always there and you don't need to know whether it came from the db or from the config.php

bye, Dirk
 Quote

Status: offline

LWC

Forum User
Full Member
Registered: 02/19/04
Posts: 818
Here's a line from lib-common.php:
Text Formatted Code
$_CONF['language'] = COM_getLanguage();

Get it? Since plugins are only ran after this line already took place, they get the dynamic $_CONF['language'] and not the original $_CONF['language'] (the one the admin wrote manualy in config.php).

In v1.5b1, I mentioned a way to get access to the original $_CONF['language'], but how do I do this in v1.4.1? I need the original value to know which language to display in a multilingual plugin (that initially accepts input in various languages) when it doesn't have the language the user currently uses in the site.

It's just one example as there are more $_CONF parameters that get changed (during a session) from how they are written manually in config.php. I'm sure there are all sorts of reasons to know the original values.
 Quote

Status: offline

jmucchiello

Forum User
Full Member
Registered: 08/29/05
Posts: 985
Text Formatted Code

$orig_language = DB_getItem($_TABLES['config_values'], "value", "group_name = 'Core' and name = 'language'");
 


 Quote

Status: offline

LWC

Forum User
Full Member
Registered: 02/19/04
Posts: 818
It's conf_values and you forgot unserialize:
Text Formatted Code
$default_language=unserialize(DB_getItem($_TABLES['conf_values'], "value", "group_name='Core' and name='language'");


But your addition just made sure my v1.5b1 code would use the core values only - what about v1.4.1? That's the big question.
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Quote by: LWC

Get it?


Yes. What you're after has never been available without dirty tricks and it won't be available without dirty tricks in the future. And I consider reading from the config table directly to be a dirty trick. Don't do it. We have an API for accessing the config - use it. Internals may change. You have been warned.

bye, Dirk
 Quote

Status: offline

LWC

Forum User
Full Member
Registered: 02/19/04
Posts: 818
How do I use the API to retrieve original manual $_CONF parameters then (they way they are before the session changes them)?
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
Quote by: LWC

How do I use the API to retrieve original manual $_CONF parameters then (they way they are before the session changes them)?


There is no supported way to get this particular value in its original state. But, as I said above, that's nothing new.

bye, Dirk
 Quote

Status: offline

jmucchiello

Forum User
Full Member
Registered: 08/29/05
Posts: 985
Quote by: LWC

How do I use the API to retrieve original manual $_CONF parameters then (they way they are before the session changes them)?

Why would there be a way to do that? In 1.4.1 you have config.php, the line $_CONF['language'] = COM_getLanguage() has no prior state. There is only one assignment. What you want doesn't exist.

If you are asking this for multifaq, just include a multifaq conf item "base language" and be done with it. Core GL doesn't have such a config item. Get over it and work around it. Make a feature request in the bug tracker "Create a CONF item 'orig_language' which contains the default language value before it is overwritten by the session." Then provide a use case (your fallback problem in multifaq) and wait for Dirk to move it to feedback since he isn't going to do anything about it in 1.5. Maybe it will show up in 1.5.1. Maybe it won't. But for right now, you have to work around it and that means storing it in your plugin's config.
 Quote

Status: offline

jmucchiello

Forum User
Full Member
Registered: 08/29/05
Posts: 985
Quote by: Dirk

And I consider reading from the config table directly to be a dirty trick. Don't do it. We have an API for accessing the config - use it. Internals may change. You have been warned.

bye, Dirk

Dirk, throughout GL you directly access the various db tables for all sorts of things. They are all version dependent and all can change without warning. How is conf_values any different really? My plugin can also just say $_CONF['path'] = 'fubar' and break the system. So what? If my plugin breaks the system, people won't use it. It's self-correcting.

For example, there's an API for reading stories from the database. But there isn't one for getting a list of stories. Is reading the story table directly dirty pool? Of course not. Can't I write code that reads the block table directly or MUST I go through COM_formatBlock? Any direct database access can be affected by internal changes. But GL is not known for its highly polished interfaces. Every table has been fair game up until now and I fail to see how conf_values is any different.

If it is different, please, what other tables are forbidden and where is it documented?
 Quote

Status: offline

Dirk

Site Admin
Admin
Registered: 01/12/02
Posts: 13073
Location:Stuttgart, Germany
My point was that you shouldn't rely on how the information is stored in the config table. This is pretty much the only place we actually have a proper abstract interface to information that's kept in the database and I just want to prevent people from starting to mess with it before it's even properly released Rolling Eyes

That you can wreak havoc by overwriting $_CONF entries hasn't changed.

bye, Dirk
 Quote

Status: offline

jmucchiello

Forum User
Full Member
Registered: 08/29/05
Posts: 985
I don't think it is abstracted enough. The config class should be divided into two classes. One that manipulates the database and a GUI class. That would make the config stuff easier to enhance. Right now the config class is pretty "dumb". It doesn't understand what it is manipulating. That's why I've proposed enhanced typing for stuff like paths and urls. If the config class knew a data element was a URL, it could verify that format of that data before saving it to the database. I've put this in the tracker and when 1.5 is stable, I'll release a patch.

I also think user config data should be stored in the same place. Stuff like date format. There's the system's default date format and the user can override it. If user data was also in the table, the initial conf load would pick up the user's override automatically and that eliminates a lot of code that jumps through hoops trying to figure out which data format should be used. Only problem here is conf is loaded before lib-session but I'm sure that can be worked around somehow.
 Quote

All times are EDT. The time is now 09:26 am.

  • Normal Topic
  • Sticky Topic
  • Locked Topic
  • New Post
  • Sticky Topic W/ New Post
  • Locked Topic W/ New Post
  •  View Anonymous Posts
  •  Able to post
  •  Filtered HTML Allowed
  •  Censored Content