2

I've seen a number of questions on this site regarding this exact issue, but I'm fairly certain that my case is a bit different. I recently upgraded from ZF 1.9.6 to 1.11.11 and since then things stopped working on my production server.

My localhost is running PHP 5.3.8 while the server is running 5.2.11. I am not sure if that has anything to do with it but I figured I would mention it just in case.

When I first upgraded the framework, I was getting a bunch of open_basedir restriction in effect. errors. I resolved that exactly how several others mentioned, by removing the get_include_path() from the call to set_include_path() in the index.php file. As mentioned here.

That fixed the open_basedir errors, but now I'm having issues elsewhere. In several different files for various reasons I am including files via the include and require statements using relative paths.

For example:

require_once 'application/models/MyModel.php';

But now that suddenly doesn't work anymore! I've had to suddenly prepend all those paths with a ./ like so:

require_once './application/models/MyModel.php';

The problem is, there are way too may instances of that to manually go through and find all of them and change it. Rather, I want to figure out why those paths no longer work on the server but continue to work on my localhost.

My inclination is that it has something to do with the fact that I no longer include the get_include_path() part in the set_include_path() in the index.php file but I am not sure.

Can anyone shed some insight? Thanks!

Community
  • 1
  • 1
Yes Barry
  • 9,514
  • 5
  • 50
  • 69

1 Answers1

3

I suspect it has to do with this note about open_basedir:

The restriction specified with open_basedir is a directory name since PHP 5.2.16 and 5.3.4. Previous versions used it as a prefix.

The difference between checking it as a prefix and checking it as a directory would definitely cause problems like this.

A solution might have something to do with this note in the PHP documentation:

Using a . in the include path allows for relative includes as it means the current directory. However, it is more efficient to explicitly use include './file' than having PHP always check the current directory for every include.

So when setting your include path, I think you should modify the example you linked to like this:

set_include_path(
    APPLICATION_PATH . './../library' . PATH_SEPARATOR .
    APPLICATION_PATH . './../library/Zend'
);

Notice the "." I added before the first forward slash. This should make it relative to the current working directory and stop you from having to make your includes like ./file.

Also, that says this method is less efficient so you can also consider using a tool such as TextCrawler to do find & replace on multiple files.


Additionally, you can include '.' (current directory - or document root) in your include path when setting it. Like so:

set_include_path(APPLICATION_PATH . '../library' 
    . PATH_SEPARATOR . APPLICATION_PATH . '../library/Zend' 
    . PATH_SEPARATOR . '.' // <-- notice this!
);
Yes Barry
  • 9,514
  • 5
  • 50
  • 69
Jeremy Harris
  • 24,318
  • 13
  • 79
  • 133
  • Hey thanks a bunch for your reply, it was very informative! I'm gonna give that a try and I'll let you know tomorrow what the deal is. – Yes Barry Mar 30 '12 at 08:52
  • I solved this with the solution I added to your answer. Your answer was great though either way! Cheers. – Yes Barry Apr 02 '12 at 11:36
  • 1
    Awesome, thanks for adding that bit to the answer, hopefully it helps someone else down the road! – Jeremy Harris Apr 02 '12 at 23:56