allow override of core in require'd script

[plb]

As mentioned here: http://userspice.org/forums/topic/verify...#post-2055

It is currently possible to override "pages" but it is not possible to override scripts which are brought into other pages by means of require_once() or the related include*() and require*() functions...

I believe that by changing the require_once() calls from absolute to relative:

Code:

require_once('header.php');

instead of

Code:

require_once($us_url_root.'users/includes/header.php');

and then making judicious use of

Code:

include_path

(presumably configured in init.php during installation) you could make these over-ridable.

Of course the disadvantage is the code becomes a bit less readable and you will suffer a bit of a performance hit (I would guess negligible).

[mudmin]

Hmm. I haven't messed with that.

I'm not 100{3bc1fe685386cc4c3ab89a3f76566d8931e181ad17f08aed9ad73b30bf28114d} sure what the issue is. I could be dense on that.

The reason the header and nav are split is to give you the opportunity to include per page scripts independent of what we've created right between the two.

It's also easy to make something like alternative_header.php and include that on the pages you want.

We used to have relative header calls in the past, but it became an absolute mess because we never knew how people's servers were going to handle them. People would get weird recursion errors.

Maybe if I had a usecase I might have better feedback on this.

[plb]

I made changes to header.php and DB.php as I was working through how to add functionality while staying as close as possible to core.

I wasn't looking for a change to every one of my pages to include alternate_header.php instead of just header.php, although that would have been a workable solution.

But when I extended the WHERE condition in DB.php there was no way I could use that without changing the core file. If I could have copied it to usersc/Classes/DB.php and have it automatically override users/Classes/DB.php that would have been nice.

This is a preference on my part, not a big deal. If it causes other problems and there's no obvious solution then better not to implement it...

[mudmin]

AHHH. Gotcyha. Yeah. You're right. It's really not a big deal to modify those classes. It's extremely rare that they get updated. (Although 4.1.5 will have 2 updated classes thanks to your work). The good news is that if we ever push out an update that has a class update, you'll know about it and you can manually fiddle with it. That's until 5.0 at least when hopefully we'll come up with a more elegant solution.

My only thought is that if we modify a class, it's almost always going to be for a real reason...so chances are you're going to want to merge our changes and yours.