Zend Framework: Hackish Include Path Solution

Posted by santosj on October 1, 2006

Looking over the Zend Framework Tutorial and trying to get the php_value to work, seemed to have no results. This is from the my script running in a CGI environment and the php_value working in a mod_php environment. The solution for a CGI environment is a simple one, but it did take a little bit of research to find.

For the tutorial, totally awesome, but I would add a few things to it.

  1. Reference that php_value requires mod_php environment.
  2. Example for those who don’t use mod_php.

<sarcasm>
I’ve had problem with Zend Framework not being able to find its files, which is usually not good. The “workaround” of adding the realpath works, but would be overwritten when updating. Besides, going through the files just to add realpath locations is a hassle.

The php_value only works with mod_php, so good luck if you are running PHP using CGI/FastCGI. Actually, you’ll have no luck, because it won’t work using CGI.
</sarcasm>

The Ultimate Hackish Solution

Doing some research bought up that ini_set does allow you change the include path for the script.

ini_set('include_path', PATH_TO_ZEND);

Change PATH_TO_ZEND to the absolute path to the root folder where zend.php is located. (Should be the directory that contains a Zend folder also.

Update: Better examples are in the comments.

Possibly Related Posts:


Projects

11 Comments.

  1. Foo October 1, 2006 at 11:47 am

    About fcgi, it can accept custom php.ini (per defintion) or -doption=value as argument.

    You should also use set_include_path instead of ini_set.

    A last advice, using “..” in your include_path is a bad idea. An absolute path and the current directory (“.”) are the only safe (and sane) paths to use.

  2. Jacob Santos October 1, 2006 at 12:11 pm

    Thanks, foo!

    That is sweet. Less hackish method. Accept I have no idea on how to do the custom php.ini method, since I’m on shared hosting. I would rather have something that is transferable to other servers. Other servers that might have a security setting not allowing that method.

  3. Sor October 1, 2006 at 1:20 pm

    Sorry to say this having kept my eye on your blog for a while it seems that you _always_ blog first and then do the research. I’d appreciate it if you’d do it the other way around, for everyone’s sake.

  4. Geoffrey October 1, 2006 at 3:02 pm

    You may consider using get_include_path() and PATH_SEPARATOR instead of an hardcoded path string:

    set_include_path(get_include_path().PATH_SEPARATOR.PATH_TO_ZEND);

  5. Edward Z. Yang October 1, 2006 at 7:30 pm

    I agree, this is a slightly strange blog post, but I see where you are coming from. While ini_set is not the best way to go about doing things (use set_include_path() and friends), it is worth mentioning that php_value won’t work if PHP is being used as CGI. (Which the tutorial fails to mention)

  6. Philip Hofstetter October 2, 2006 at 5:02 am

    Hi,

    actually, set_include_path() and even ini_set() (ini_set was there before set_include_path got in), is the only sane solution to the include path problem in PHP.

    Setting it via php.ini is no option as that would affect all virtual servers. Using php_value is no option as it’s both dependant on webserver and SAPI.

    ini_set has the advantage of being completely under the applications control. You have the guarantee not to accidentally include the wrong files and you can make sure that only files in a designated include directory will be found (my not including .).

    In all my apps, I usually use set_include_path() to set the path to the correct directories determined by some parsing on $_SERVER['DOCUMENT_ROOT'].

    Philip

  7. Jacob Santos October 2, 2006 at 7:39 am

    The critique that I should do research first before posting is valid and I am trying that more. I suppose it isn’t the set_include_path that you are mad about, but all the other posts, on top of this one. If not, then why be so mad about a single obscure function?

    I did do more testing and research for once, on this article. I must ask, how much research is needed? If searching for “Include Path” on google doesn’t bring up set_include_path, then how do I search for something that I have no idea exists? Truthfully, I was looking for a better method and was hoping someone would point something out.

    The rant I was going to post before was even worse as I was going to recommend including zend.php and using Zend::loadClass. After looking at the zend.php code, I realized that method wouldn’t have worked and searched for a better method of setting the include path. If you must know, I never found a reason to have to set the include path, since I don’t use PEAR, and I usually include using the absolute path. I think the including using absolute paths is a better method. However, I suppose realpath and dirname would have overhead, but doesn’t “include path” also?

    However, if you’ll read the set_include_path page you would have seen that only versions above 4.3 have that function. The article is good as is, and if the reader reads the comments, then they would see a better alternative.

  8. Edward Z. Yang October 2, 2006 at 10:15 am

    Me being pendantic: Versions is a moot point: Zend Framework only works with PHP 5.1.4 or later.

    However, you do set forth an interesting question: require_once dirname(__FILE__) . ‘Class.php’ versus set_include_path? Personally, I prefer set_include_path because the cost is upfront and only once: with the other method you have to call dirname everytime you want to include a file, which is also more verbose. In truth, the performance hit is probably negligible.

    You could also compromise and create a stub file that uses dirname(__FILE__) to automatically configure the include_path, so all you’d have to include is that stub file and whammo things work.

  9. Jacob Santos October 2, 2006 at 10:23 am

    Well, I have noticed that I’m calling dirname() each time and defined a constant. Other packages do the same thing, but my current project doesn’t have any consistency, sometimes I use the constant, sometimes I don’t. If I know that the file will always (or should always) have the constant available, I use, if I feel that I might use the file in another project, I use dirname().

    As many files as I’m including, I’ll probably feel the punch soon enough.

    As interesting as a benchmark would be, I don’t have the tools to do one. Searching for one on google turned up no results. I suppose no one has really pondered the overhead hard enough. I could probably get the “cost” of using dirname, but I’m not sure using microtime() would do set_include_path() justice.

  10. David Zülke October 2, 2006 at 3:24 pm

    Jacob,

    what I’m saying is that since your blog is syndicated on planet-php, you reach a very, very large audience with what you say. If you decide to complain about something in front of such a large audience, you should be 100% sure that what you’re saying is correct and, more importantly, can withstand criticism. And this posting can’t.

    Let’s put this set_include_path thing aside – my problem with ini_set was that you post about PHP, you’re syndicated on planet-php, but you don’t know that method, and even “research” didn’t help you to stumble across it.

    The actual issue is that you complain about having to set your include path, which you also call “hackish”. That’s wrong. There’s nothing bad about modifying the include path at runtime. That’s why set_include_path exists. So you can add your own stuff to the include oath, and so you don’t have to use ini_set. It’s common practice, and a lot of libraries require it. Also, the Zend Framework README says

    No special installation is required, however the Framework classes
    expect that the /library directory is in your include_path. You will also
    find a /demos directory with some code samples to run.

  11. Eko October 3, 2006 at 6:06 am

    About PHP include path, Check other alternative at http://snipplr.com/view/1278/php5-include-path/