I've said it already via IM: I don't think it would make it noticable faster, but would also do no harm, of course.

BUT: I always use _config_TEST.php for my installations, because it allows to easily merge/update from CVS (without conflicts) and therefor, _config_TEST.php needs to get "conditionally included" at the end of _basic.php.

Btw: I've seen already a lot of application packages, which do it like this: they have a config_sample.php file that you have to rename to config.php (or the installer creates/generates a fresh one). config.php by itself is then not under under version control (and probably even in .cvsignore/..).

blueyed: I've seen apps with only a sample config file, too. IMO, it does make upgrading easier, but it may not be worth the trade off because it makes installing a bit harder. I would always lean toward making the first install as easy as possible. People upgrading should know to backup their files and merge the old config file back in. It's the first time users that need the most help. But, that's just my opinion. It's a minor difference.

Someone will need to enlighten me on _config_TEST.php ...

Because cvs includes_config.php (with default "I've never been installed" settings) you can overide it with a file called _config_TEST.php.

This enables developers to keep their files synched without having to edit _config.php everytime they update.

¥

personman: I don't think it makes installing harder at all.. in fact, the casual user uses the /install/index.php installer and therefor does not see any files at all.

It gets more difficult with the several files we have: there would be a sample-file for all of them and all would need to get copied by the installer to the real name. The installer itself only modifies _config.php/_basic.php.

Personally I find a single conf file better, because it would be all in a single file and you would not have to think about where a particular setting might be in (I'm ignoring grep etc here purposely).

And me - code-noob - wants to have as mutch parameters as possible in the backoffice.
I'm speaking of these onces (I have to change them several times a week, when people in our blog are posting articles in the wrong cat etc..)

/*** Cross posting  */
$allow_cross_posting = 0;

/*** Moving chapters between blogs  */
$allow_moving_chapters = true;

/*** Default status for new posts */
$default_post_status = 'private';

Also the stuff that is in _icons.php and _stats.php

François told me allready that i's not to difficult, only a lot of dumb work.

(I'm using 1.6 and haven't even looked at cvs)

Just got the latest cvs, and glad to see that this has been implemented :D

What EXACTLY is the gain here? Near as I can figure the only difference between then and now is that the exact same parameters are split between two different files.

Y'all are getting way heavy on the bloatware. The more y'all bloat the more I think of downgrading to .9.2 and leaving it that way.

It's doing exactly the opposite of Bloatware.

It's so plugins, and things that are accessed directly (not through the evocore) can access only the configuration they need, instead of loading up the whole config.

Whats wrong with that?

And when would a plugin NOT be part of loading up the core?

Note: You still want to run 0.9.2 on heavy loaded production servers because it's still more efficient than the feature packed Phoenix releases. If you have CPU to spare on your server though, then you may want to upgrade to Phoenix in a couple of weeks.

That comes from [url=http://b2evolution.net/news/2006/05/17/b2evolution_0_9_2_sparkle_released]here[/url]. Microsoft considers their code to be 'feature packed' too, right?

So when does someone visiting your blog, and therefore experiencing all that plugins have to offer, not need to load the core files?

Sure the 1.x versions are not 'stable' enough for 'heavy loaded production', but they are the future of b2evo.

I requested this because when i was working on my Gallery Plugin i needed a way to load up the database config, but the only way to do so, is to load _config.php along with the rest of the configuration.
What's the point of loading the whole config when all i need is the config of the database?

What about the File Manager, why would it need the blogging classes?

Or a seperate system that just wants to extract a few post titles to use in a sidebar somewhere.

Or even a system that wants to use b2evo's user database, but not any of it's blogging stuff.

It doesn't hurt b2evo at all, so why not?

balupton wrote:

It doesn't hurt b2evo at all, so why not?

But it does because it's bloat. EVERY instance of loading a blog will require 2 files to do the work of one. Carried to it's extreme, every single item defined in config.php will be defined in it's own private little file to serve some tiny little goal. That'll really help when the vast majority of instances are to create a page for a visitor to view.

Wanna know another great example of bloat in b2evolution? Do a raw installation and look at blog #1 then save the source code and look at it's byte size. Now go into _main.php and remove all the tabs that precede all the lines. In fact do that for all the files in the skins/custom folder, but be careful to not remove ALL the tabs because some are serving where a space would serve equally well. Now reload the page, save the new version, and compare the byte size. Each and every tab in the source code bloats the actual product even though it makes code-junkies happy by having nice little indents to follow. I haven't done it in a while but memory tells me something like a 12% reduction in the file size sent to the visitor happens by removing the tabs that serve no purpose other than to make groovy looking .php files.

What is the point of a blog application if not to deliver a web page to a visitor? Given that, what is the point of each and every file in a blog app if not to deliver a web page to a visitor? Restated: identify a plugin that doesn't support delivering a web page to a visitor. If you can you're identifying a pointless plugin.

What is bloat, is having to load more than what you need even for the simplist of tasks.

What are the disadvantages right now in terms of effeciency of this change?
And are they really that bad that they outweigh advantages?

Fair enough.

All I was doing was pointing out that if there is no gain to the end user then what's the point? To my way of thinking it's all about page generation and delivery - even for those who claim they don't care about traffic. Therefore anything that slows down page generation and delivery detracts from the overall point. Thus I pointed out how the tabs that make the source code look good are bloat because they slow down page delivery. They won't go away, but they don't need to be there and they don't enhance the visitor's experience.

But pluginability is cool!