Print

[slausen]

Hi-

Is there an easy way to export the configuration info back into the old-style "flat file" format?

It looks like the code is conditional and will run as long as there is a file config.inc.php in the right place.

There are many reasons why this would be useful.

Is it as simple as just exporting the cpg143_config table?

Thanks!

[Nibbler]

Try it and see. I've not heard of anyone doing this before.

[slausen]

Try it and see. I've not heard of anyone doing this before.

OK I will give it a shot - but before I start, do you know of any reason why it shouldn't work? Based upon what I saw, it seems like there is code in init.inc.php that reads the config.inc.php file (which contains only DB connect info) and then connects to the db and reads the config table into variables - after that, CPG is just driving off of the variables that have been read in (right? )

If it works, I can report back with the results.

Flat files are cumbersome, but for things like version control, and rolling back to a stable config when things go wrong, I have found that it is good to have an archive copy of config files. Databases are great at managing large sets of information, but it can sometimes be difficult to track what/when/how/who has changed information inside a database.

[slausen]

OK I will give it a shot - but before I start, do you know of any reason why it shouldn't work? Based upon what I saw, it seems like there is code in init.inc.php that reads the config.inc.php file (which contains only DB connect info) and then connects to the db and reads the config table into variables - after that, CPG is just driving off of the variables that have been read in (right? )

If it works, I can report back with the results.

Flat files are cumbersome, but for things like version control, and rolling back to a stable config when things go wrong, I have found that it is good to have an archive copy of config files. Databases are great at managing large sets of information, but it can sometimes be difficult to track what/when/how/who has changed information inside a database.

I forgot to add that I realize that a CPG install running only on a "flat" config.inc.php would need to have the config.inc.php "refreshed" whenever a change is made to the DB config in the Admin, but that can be easily automated (via cron).

[Joachim Müller]

Is there an easy way to export the configuration info back into the old-style "flat file" format?

The coppermine config has never been stored in a flat file, in no coppermine version ever. The only thing that is stored in a plain-ext file is the mysql connection data (that is of course needed to make the script connect to the database in the first place). I can't see why you would want the config to reside in a plain text file - coppermine will still be a database-driven app, as everything else (pics, users, comments etc.) resides in the database. I can't see any reason why you should want to just  put your config into a plain text file.
Refreshing a config file is of course silly, it would have to be refreshed every time you change it. If you decide to change it manually, you'd have to come up with a custom script that triggers the refresh.
Doing what you're up to would make a lot of code changes necessary, especially if you're trying to make coppermine use plain text files exclusively (converting it from a database-driven app to a plain-text file app), as coppermine hasn't been built to contain a database abstraction layer.

[slausen]

The coppermine config has never been stored in a flat file, in no coppermine version ever. The only thing that is stored in a plain-ext file is the mysql connection data (that is of course needed to make the script connect to the database in the first place). I can't see why you would want the config to reside in a plain text file - coppermine will still be a database-driven app, as everything else (pics, users, comments etc.) resides in the database. I can't see any reason why you should want to just  put your config into a plain text file.
Refreshing a config file is of course silly, it would have to be refreshed every time you change it. If you decide to change it manually, you'd have to come up with a custom script that triggers the refresh.
Doing what you're up to would make a lot of code changes necessary, especially if you're trying to make coppermine use plain text files exclusively (converting it from a database-driven app to a plain-text file app), as coppermine hasn't been built to contain a database abstraction layer.

Hi GauGau-

I think maybe you misunderstood me.

I understand that Coppermine is a database-driven app. 

I've been doing some customizing, and so I have been poking around the code. I have also logged in through mysql and poked around the table structure. Been developing for over ten years, mainly on the database side. Still new to PHP but learning. I have written many database-driven apps. So I know that a lot of info is being stored in the DB.

But when I (quickly) looked through the code and DB, it seemed to me that:

1) The table cpg144_config contains nothing but the config data.

2) There is a call on line 150 of init.inc.php to include the config file if it exists. Inside the config file the connect info to the DB is defined and put into the config array.

3) There is a call on line 173 of init.inc.php to read the config info from the database if "mb_internal_encoding" is set. The info in the DB is added to the same config array.

So as someone who has written code before, it seems to me that if I place the config info directly into config.inc.php, and comment out Step 3, the system should still work. And this would allow me to have an Admin version of CPG as well as a User version. The user version could drive off of the static config file. The Admin version could drive off of the database. And every night a cron job could regenerate the User config.inc.php file - this company already has many processes that run like that and no one feels they are "silly". I am not suggesting that Coppermine would be "converted" to flat file. I am talking only about the info in the config table. I didn't see any other references in the code, where this info is not just included - but if there are it would be great to know where they are or what functions to look for... which is why I started this thread.

The reasons why you might want to have the config info in a flat file are many - probably running two Coppermine versions(User, Admin) against a single DB, version control and rollback capability are the main ones for this project. When you have a lot of users, you have to be concerned with maintaining an audit trail of changes, not because you don't necessarily trust your Admins, but because if something goes wrong, you want to be able to roll back to a previous configuration.

Databases are great at managing large sets of data. But for something like configuration data, how can you store versions and rollback to a previous config if it's in the DB?

P.S. - Regarding your comment about refreshing a config file being "silly", there is no need to be rude just because you have a difference of opinion. I am just asking a question, which is the whole purpose of this board, right? Frankly, that kind of comment is petty, uncalled for, and unprofessional, and it reflects poorly upon you, IMHO.

P.P.S. - the whole idea behind open source is that people can change the source to meet their needs, isn't it?

P.P.P.S. - I was searching the CPG forum on this topic and I thought I pulled up some threads referencing a flat-file based config in an earlier version, but maybe I was just thinking that because there is a flag "mb_internal_encoding" that there were probably two options for that...since you wouldn't need a flag if there is only one option, right?

[Nibbler]

mb_internal_encoding is related to multibyte character encoding in php. It has nothing to do with loading config settings. Restoring from an automatically backed up database table is just as easy IMO and you don't need to worry about code changes. The config array is generally used when raeding config details, but there are some places you will hit issues, from memory the config table is read directly in the bridge manager and on the search page.

You are of course free to do what you like with Coppermine, and we are equally free to offer you our opinions when asked

[Joachim Müller]

to add to what Nibbler said: I'm sorry that I have upset you, it was not my intention. Maybe this has been caused by a misunderstanding on the word silly on my side. Please accept my apologies - English is not my first language. I wasn't suggesting that you're silly, but just that the approach is wrong. Imo you should edit the core as little as possible, as upgrading will be harder, and there will be some other issues (as Nibbler already pointed out). I can see no benefit in storing the config in a flat file, and it's quite easy to do regular backups of particular tables (e.g. the config table) automatically when the server is yours to configure (when you have shell access and cron jobs available, just do a mysql backup using "native" mysql commands, backing up database content into different files, with rotating file names).
You can easily set up two instances of coppermine on one database, and it's easy to even make it use one config table (one line of code needs modification).
Of course you are free to do whatever you like with coppermine and mod it as you see fit, but after all you asked for opinions - that's at least how I understood your question. If this is not the case and you just wanted to let us know what you're up to do, then thanks for the information and good luck.

Joachim

[slausen]

to add to what Nibbler said: I'm sorry that I have upset you, it was not my intention. Maybe this has been caused by a misunderstanding on the word silly on my side. Please accept my apologies - English is not my first language. I wasn't suggesting that you're silly, but just that the approach is wrong. Imo you should edit the core as little as possible, as upgrading will be harder, and there will be some other issues (as Nibbler already pointed out). I can see no benefit in storing the config in a flat file, and it's quite easy to do regular backups of particular tables (e.g. the config table) automatically when the server is yours to configure (when you have shell access and cron jobs available, just do a mysql backup using "native" mysql commands, backing up database content into different files, with rotating file names).
You can easily set up two instances of coppermine on one database, and it's easy to even make it use one config table (one line of code needs modification).
Of course you are free to do whatever you like with coppermine and mod it as you see fit, but after all you asked for opinions - that's at least how I understood your question. If this is not the case and you just wanted to let us know what you're up to do, then thanks for the information and good luck.

Joachim

I'm not upset - I am just trying to keep this from devolving into a flame war.

But thanks for the apology - I appreciate it.

I can understand your perspective about editing the core to make upgrades easier, but in my case I am less concerned with upgrades and more concerned with:

1) Running two separate installs against one DB
2) Putting the config into a file-based version control system.

so my perspective is different than yours. The highest priority for me is not future upgradeablility.

As far as you being unable to see any benefit in flat-file config - you are entitled to your opinion, but I have listed several benefits I see throughout this thread.

Regarding your comment about exporting a particular table as being an "easy" project, I can only say that the difficulty of a project like that lies in handling the exceptions (what if you can't connect to the DB, how do you test and trap for any responses, what about multiple updates between DB dumps, how do you manage all the different dumps of DB data, etc.).  This has to be full production, not just some code running on a server. So my preference is to use a proven tool like Openview, which is already being used by the company for other types of change management, rather than re-invent the wheel.

But I would still be interested in finding out how to run 2 installs against one DB - you said it's possible to change one line of code - I'd appreciate it if you could provide more detail there, that's useful info, thanks.

[slausen]

mb_internal_encoding is related to multibyte character encoding in php. It has nothing to do with loading config settings. Restoring from an automatically backed up database table is just as easy IMO and you don't need to worry about code changes. The config array is generally used when raeding config details, but there are some places you will hit issues, from memory the config table is read directly in the bridge manager and on the search page.

You are of course free to do what you like with Coppermine, and we are equally free to offer you our opinions when asked

Hi Nibbler-

I disagree with you about restoring from DB as being just as easy, but everyone is entitled to their opinion. 

But I want to thank you for the info about the config table being read form the bridge manager and search, that is EXACTLY the kind of info I was hoping for when I started this thread. Thank you!

[Joachim Müller]

But I would still be interested in finding out how to run 2 installs against one DB - you said it's possible to change one line of code - I'd appreciate it if you could provide more detail there, that's useful info, thanks.

edit include/init.inc.php, find

Code: [Select]

$CONFIG['TABLE_PICTURES']   = $CONFIG['TABLE_PREFIX'].'pictures';
$CONFIG['TABLE_ALBUMS']     = $CONFIG['TABLE_PREFIX'].'albums';
$CONFIG['TABLE_COMMENTS']   = $CONFIG['TABLE_PREFIX'].'comments';
$CONFIG['TABLE_CATEGORIES'] = $CONFIG['TABLE_PREFIX'].'categories';
$CONFIG['TABLE_CONFIG']     = $CONFIG['TABLE_PREFIX'].'config';
$CONFIG['TABLE_USERGROUPS'] = $CONFIG['TABLE_PREFIX'].'usergroups';
$CONFIG['TABLE_VOTES']      = $CONFIG['TABLE_PREFIX'].'votes';
$CONFIG['TABLE_USERS']      = $CONFIG['TABLE_PREFIX'].'users';
$CONFIG['TABLE_BANNED']     = $CONFIG['TABLE_PREFIX'].'banned';
$CONFIG['TABLE_EXIF']       = $CONFIG['TABLE_PREFIX'].'exif';
$CONFIG['TABLE_FILETYPES']  = $CONFIG['TABLE_PREFIX'].'filetypes';
$CONFIG['TABLE_ECARDS']     = $CONFIG['TABLE_PREFIX'].'ecards';
$CONFIG['TABLE_TEMPDATA']   = $CONFIG['TABLE_PREFIX'].'temp_data';
$CONFIG['TABLE_FAVPICS']    = $CONFIG['TABLE_PREFIX'].'favpics';
$CONFIG['TABLE_BRIDGE']     = $CONFIG['TABLE_PREFIX'].'bridge';
$CONFIG['TABLE_VOTE_STATS'] = $CONFIG['TABLE_PREFIX'].'vote_stats';
$CONFIG['TABLE_HIT_STATS']  = $CONFIG['TABLE_PREFIX'].'hit_stats';and edit accordingly. If a table is meant to be shared between the two installs, change $CONFIG['TABLE_PREFIX'].for that particular table (hardcoding the prefix of the "common" database).

[Nibbler]

You can search the code for references to the config table and see how they affect you.

Code: [Select]

nibbler[stable]$ grep -lr TABLE_CONFIG .
./admin.php
./bridgemgr.php
./exifmgr.php
./catmgr.php
./index.php
./include/init.inc.php
./charsetmgr.php
./search.php
./searchnew.php


[slausen]

edit include/init.inc.php, find

Code: [Select]

$CONFIG['TABLE_PICTURES']   = $CONFIG['TABLE_PREFIX'].'pictures';
$CONFIG['TABLE_ALBUMS']     = $CONFIG['TABLE_PREFIX'].'albums';
$CONFIG['TABLE_COMMENTS']   = $CONFIG['TABLE_PREFIX'].'comments';
$CONFIG['TABLE_CATEGORIES'] = $CONFIG['TABLE_PREFIX'].'categories';
$CONFIG['TABLE_CONFIG']     = $CONFIG['TABLE_PREFIX'].'config';
$CONFIG['TABLE_USERGROUPS'] = $CONFIG['TABLE_PREFIX'].'usergroups';
$CONFIG['TABLE_VOTES']      = $CONFIG['TABLE_PREFIX'].'votes';
$CONFIG['TABLE_USERS']      = $CONFIG['TABLE_PREFIX'].'users';
$CONFIG['TABLE_BANNED']     = $CONFIG['TABLE_PREFIX'].'banned';
$CONFIG['TABLE_EXIF']       = $CONFIG['TABLE_PREFIX'].'exif';
$CONFIG['TABLE_FILETYPES']  = $CONFIG['TABLE_PREFIX'].'filetypes';
$CONFIG['TABLE_ECARDS']     = $CONFIG['TABLE_PREFIX'].'ecards';
$CONFIG['TABLE_TEMPDATA']   = $CONFIG['TABLE_PREFIX'].'temp_data';
$CONFIG['TABLE_FAVPICS']    = $CONFIG['TABLE_PREFIX'].'favpics';
$CONFIG['TABLE_BRIDGE']     = $CONFIG['TABLE_PREFIX'].'bridge';
$CONFIG['TABLE_VOTE_STATS'] = $CONFIG['TABLE_PREFIX'].'vote_stats';
$CONFIG['TABLE_HIT_STATS']  = $CONFIG['TABLE_PREFIX'].'hit_stats';and edit accordingly. If a table is meant to be shared between the two installs, change $CONFIG['TABLE_PREFIX'].for that particular table (hardcoding the prefix of the "common" database).

Thanks GauGau - this is great info.

[slausen]

You can search the code for references to the config table and see how they affect you.

Code: [Select]

nibbler[stable]$ grep -lr TABLE_CONFIG .
./admin.php
./bridgemgr.php
./exifmgr.php
./catmgr.php
./index.php
./include/init.inc.php
./charsetmgr.php
./search.php
./searchnew.php


Thanks for this suggestion, Nibbler. I will grep on TABLE_CONFIG.