Jump to content

Recommended Posts

I'm just looking for some tips here. I am developing and selling an eccommerce shopping cart software package, and it has been received very well from the early adopters. There's just one small problem that prevents the software from being a truly out-of-the-box solution: the include path. Not all users have access to their php.ini file, and it's not always a php.ini file anyway. So this is something the installation is unable to set for the customer.

 

I'm using object-oriented PHP5 stuff, so I have a folder named "classes" with all the relevant stuff in there. I am unable to search for paths to the folder and hard-code those into source files (there are ajax calls and other fun stuff; hard to know the exact relation to the path).

 

I guess I could use set_include_path on the top of a bunch of files, but that is a small performance hit (and totally inelegant code). I could put the folder path in the database somewhere and query for it (and cache it so it's not a performance hit). None of this stuff seems good. The path seems like the best solution.

 

Unless you have better ideas.... :)

Link to comment
https://forums.phpfreaks.com/topic/227223-ideas-to-avoid-include_path/
Share on other sites

Thanks but I'm confused: Where is that code supposed to go?

You would have a configuration/settings file that is always called and that code would reside there. So, no matter what page is called you would have those default "paths" defined. Then include your files with somthing such as

include($_PATHS['classes'].'somename.class.php');
include($_PATHS['settings'].'databaseconnection.php');

 

You can easily change the location of those "root" folders and just update that one config file. So, for the usersof your application as long as they install everything in the same relative locations it wouoldl all work.

OK. Well I did essentially suggest that in the original post ("I guess I could use set_include_path on the top of a bunch of files"), but this may be difficult with the AJAX calls and such. I'll have to test it. I didn't know about __FILE__ before, so that should be helpful.

 

Also, what is $_PATHS? I don't see this documented anywhere.

One more thing: isn't there a small performance hit by doing this, as opposed to just putting it in the path?

 

You wouldn't put something like this at the top of a bunch of files.  You would put it in an initialization of your bootstrap or main controller script.  Thus the environment would always be setup for use by any script.

 

As for "putting it in the path" that is what that function does --- define the "php include path" that php will use to look for scripts that aren't in the current directory.  The "default" path that is hardwired is the one in the php.ini, so this simply overrides that default, but once set, the performance hit is the same.

You would put it in an initialization of your bootstrap or main controller script.

 

Sorry, I don't understand this. Can you explain it? I know PHP code, but virtually nothing about the setup environment. Also, remember that my code is being run on other people's servers in which I cannot possibly know the environment... so how can I configure this bootstrap/controller script to work for everyone?

 

Thanks again.

Most web applications these days are built around the Model View Controller (MVC) design pattern.  In this pattern you have a front controller or bootstrap script that is the entry point of the application, through which all other scripts run.  You might want to take a look at some of the popular frameworks, like Zend Framework, Symfony or CakePHP to get an idea of how you can implement this. 

 

As for "knowing the environment" there is no need to know it.  Your application only needs to know and setup its structure, and to set the include path using ini_set() in a manner similar to the one described in the link mjdamato posted. 

Now I'm even more confused. Someone still has to modify the bootstrap script, right? I'm looking for a solution where no one has to modify anything.

 

NO, no one has to modify the bootstrap script. You simply create you applicatin so the bootstrap script is always called no matter what page is reqested. That script could set some default values (such as the example above), make the database connection, etc. Basically ANYTHING you want set/configured for every page. You would never want to add the same configurations to the top of every page because if there is ever a change you have to edit all those pages instead of just one.

 

So, you could simply set the include path in this bootstrap file.

 

As for $_PATHS it is not a system variable. In my example it is a variable that you would create (which is what I do).

You simply create your application so the bootstrap script is always called no matter what page is reqested.

 

Sorry to be such an ignoramus, but I don't know how this is done.  :-[

 

Again, I know the code, but not this environmental setup stuff. I appreciate your replies.

Just to go back to what I previously wrote -- and to mjdamato's code, you already saw the __FILE__ constant that helps all this work.  All it needs to do is set the base path based on where it is running from, which is an automagic PHP feature:  "Oh, the application is running from *here*". 

 

One other thing I want to point out is that the most difficult thing to deal with in PHP application installation is permissions.  There is no way for an application to do things like make directories and copy files without the right permissions configured.  So while you can strive for a zero configuration install process, you'll never truly achieve it.  Installers like the ones that come with Joomla, phpBB and other popular packages often will attempt to check permissions, and alert the user if they can not be set as needed.

 

Most packages are distributed in zip/tar-gzip'd files for this reason -- it makes sense to just have the application structure installed when the file is unzipped or untarred, and then you have a setup script that will do some configuration like the permissions checking, and storing of database user/credentials if that is needed.  Those values are often written into a config file, but again, if the permissions don't allow your script to write those values out, there is nothing you can do other than to present the user with the values they need to set, and instruct them to create the file manually.

I have talked with some local developers and they say that I should just generate a sample htaccess and php.ini, because there's no way to ever get it right (especially when one class includes another and then another) in the ways discussed here.

 

When you say to use __FILE__, that still sounds like something done for every source file, so this doesn't seem possible:

 

All it needs to do is set the base path based on where it is running from, which is an automagic PHP feature:  "Oh, the application is running from *here*". 

 

Sorry but the information here isn't very clear to me, and if other developers I know say to use php.ini, I guess that's the best way.

Sorry but the information here isn't very clear to me, and if other developers I know say to use php.ini, I guess that's the best way.

 

yeah, only beginner developers here. teeheeee :-P

 

with the method you describe, using php.ini and .htacess, there is then the assumption that php.ini will be parsed and used. that is a very poor assumption, as many hosts will ignore php.ini, or require that PHP ini settings be placed into .htaccess, and then the .htaccess php settings that work in one .htaccess may crash on another server. the method described above is used very often for product installations.

Yes, but as I do not understand the description above - I'm only told to "reread above and/or the link" - I am stuck this way.

 

I would like to have clearer instructions, please. I want to put some code in some place to fix this. I truly do not understand those two instructions, and I have asked a few times. Please be patient with me; but I do not feel I've received a response that dumbs it down enough for me.

At this point I don't really understand what problem it is that you are trying to solve, so we're speaking in vague generalities.  You keep bringing up the php.ini file.  I guess I assumed that you understood how that works but perhaps you don't.  It configures php, is a static file that gets shared by all php processes, and typically can not be changed without superuser access.  If the install is on shared hosting there is *no chance* that this file can be added to or changed.  Any changes made to it require that the *web server be restarted*.

 

I have never seen a single major php application come with the instructions to add or change the php.ini file.  Some of the variables set in the .ini can be changed at runtime.  This is the key to making the scheme work that has been presented in allowing you to setup your application structure, and then append to the front of all the relative paths, the base path section you derive from the __FILE__ constant.  Again you would do this in a routine that would be called in your frontend controller script.  If you aren't using a structure that has a controller script, then I can only advise you to take a step back and look at what you're doing, and ask yourself why you are not using the design pattern that nearly every quality application package or website uses.

 

Even if you don't see how you make this work, I have to assume that you have a config.php file that you load somehow in every script.  If you're using sessions, database connections, etc, you have to load up these routines.  The call to __FILE__ can be done in the config file, and you can set your BASE_PATH constant that way.  You do not have to use the include_path and can simply have every include and require append the relative path of those files to the BASE_PATH constant.

 

As for the __FILE__ constant, like most of these concepts that you don't seem to understand, I can only recommend that you experiment with them by writing simple scripts until you understand what they do.

 

We have also talked multiple times about the php include path.  Do you understand what it does?  If we're not on the same page, or there's a misunderstanding on your part, we have to get to an understanding of that if we're going to help you, because we keep providing and restating a solution to what your original question seemed to be, and you keep stating that you don't see how it can work.    I don't really feel I need to justify my answers, due to the thousands upon thousands of answers I've provided, but having invested some time trying to help you out here, if it makes you feel better, I've developed hundreds of websites visited by millions of users, not to mention having contributed to a few open source projects.  Some of those sites were for the Red Hot Chilli Peppers, alanis morrissette, Jerry bruckheimer films and scores of others I won't mention, so there's no question of whether this stuff works because I do this type of development on a daily basis. 

 

At this point I'll just leave it to you if you want to pursue specific questions. 

 

 

I desperately want to pursue specific questions. If you prefer to email me (does this forum allow it?) please do so.

 

My problem is simple: I have a bunch of files that are in a folder that must be in the include path. The only way I know to set the include path is to tell a customer to set their php.ini (or ask their web host for help determining how to set the path). I don't want to do that any more, and I want to know how to avoid it.

 

I understand what the php.ini file is. I understand why I don't want to tell people to change it. I understand what include paths are. That's my whole point.

 

I understand what __FILE__ is now, but you said The call to __FILE__ can be done in the config file; and I don't know what "the config file" is. Sounds to me like I'd need to alter every file to find this config file.

 

Specifically, I have structure like this

  • Root
    • classes
    • some other folder
    • a bunch of files

 

The "bunch of files" may include some class from the classes folder. Also a bunch of files in the other folders include classes from the classes folder. I call this by...

 

include( 'someclass.php' );

 

... without a path. Because it's set in php.ini. How else can I set it. Where does the mythical config file go? What is the mechanism that reads it?

 

Thank you.

Ok, so did you actually read the link that mjdamato provided, down at the bottom part, where he shows how he sets the include path using ini_set()  at runtime?  That code shows how the author sets up an array with a number of different paths.  He then uses an  __FILE__ derivation to get the basepath for his application and sets up all the directories he wants to have in the path.  The code then calls ini_set('include_path' ...) to change the default php include path to instead search the directories he wants searched, which are all the directories for his application (and this is what you would setup to match your application instead).

 

As for the config file... that is just a convention that people typically use.  They do configuration in this file, and it's included in all subsequent files, either explicitly or via inclusion in a frontend controller script that is the only script that is every called directly, and is responsible for controlling the flow of the application. 

Yes, I read the link on his first reply, but (obviously) I'm still unclear. The information is just too vague for me, mostly because:

1) I don't know where to put that code. In a config file? Okay, then...

2) What is this frontend controller stuff that knows how to find the config file?

 

I'm not trying to offend anyone, but I truly don't feel any answer has been specific to these questions. Hence the back-and-forth.

 

Thank you again for your time.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.