Geeklog Forums

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:


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

bye, Dirk

But I want to re-capture just one specific (Geeklog's own) config.php parameter. How is it done in v1.4.1?

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

Here's a line from lib-common.php:

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.

It's conf_values and you forgot unserialize:


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.

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

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

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.

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?

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

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

bye, Dirk

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.