Relative vs absolute paths
 

It's been so dead around here lately! I just had to say that.

Okay, so when I programmed this script for the oss community, I figured, you know, build an installation package for it. That'll make it hella easy for people to set up, because that'll take care of writing the config file, building the database, the whole nine yards. The only thing left for the end user is to go through a few pages (okay, 14 total) and edit one constant.

define('LIB_PATH', $_SERVER['DOCUMENT_ROOT'].'/bin/lib');

I figured set up like that, it would even cut down on the number of people that had to edit it.

However one of the biggest reports I get back about this system is that it can't find the necessary include files because they never edited that value, or they don't know what to edit it to (which ironically the failed to open stream error usually tells them where it needs to go, albeit indirectly).

So my first idea was fine, we'll take out LIB_PATH and we'll have the installation write an .htaccess which includes an addition to the php include path, so that none of the includes require a path. Then I instantly thought, well no, anybody not using apache would be left out.

So now I'm considering adding lib_path to the database config for those library files that still need it, and just making all the per page includes relative '../bin/lib/tuatara.config.php' paths.

What kind of problems this is going to raise, I don't know. Do you think making the paths relative is the best solution? Or should I just leave it how it is, and point people to the documentation? (which needs severe updating... going to go do that now.)
-m

You can try make everything idiot proof, but there comes a point when you just need to give the user the push to figure it out themselves. In this case, the documentation. So, as you said, update the documentation and guide them there.

See I don't mind making things idiot proof if they help somebody who needs the help, my problem is what level of idiot proof do I take it to. Which is why, as you say, I'm working on the documentation all day today.

The funny thing about all this, I really had intended this to be used by other developers as a base for their own system - basically, here's I just saved you a week of programming, now build on to it as you see fit. Which is in direct contradiction to my own style of build it all yourself, but eh.
-m

I'm sitting here chuckling to myself, that you have to genuinely think, "How can I make this any more simple for people." In my mind, if you've reached that point, that's where you need to draw the line for idiot proofing.

True that, but I also have to keep in mind differing levels of comprehension, I figure. I run into problems all the time in life where I understand something so I assume that others should too, and then I'm surprised when they don't follow along with a line of thought I have. I'm trying not to do that at least this once. ;-)
-m

All to true man. The workplace is a prime example of assumed intelligence. The only advice I can still give you is to just go as far as your willing.

And on another note, why is it that we are both on TalkPHP at 2 in the morning?

We're not, I'm on at THREE in the morning. Just on my way to the fridge though...
-m

Meh, it was two when I wrote the post. Were both in Nevada. Carson to be exact. Well, I'm in Carson, your in Vegas. That is beside the point. *Runs for another Dr. Pepper.*