5 replies to this topic

[MrPhil]

I am seeing (mostly in 2.2 support here) an increasing number of problem reports of included or required files not being found. Typically it is some 'includes/dir/file' being invoked from 'includes/application_top.php', but I seem to recall seeing other instances. PHP reports that the requested file was not found in the given (default) include_path. Apparently, recent versions of PHP are a bit picky about looking for "includes/..." when your file doing the including is already in "includes/...". Possibly, older versions of PHP were searching from the top-most page file (where "includes/..." is a subdirectory), but newer versions are searching from "includes/..." and the wanted path is a sibling, not a child?

What I have been doing is suggesting that people try explicitly adding their store's "root" directory to the "include_path" setting (if any) in php.ini. E.g.,

include_path='.:/usr/lib/php:/home/ACCOUNT/public_html/catalog'

where .:/usr/lib/php is whatever is given in the PHP error message as the default or existing include_path.

Today, while trying to help with a problem where apparently the wrong splitPageResults() is being invoked, it occurred to me that this fix (adding the store root dir to include_path) may be locking users out of the admin side. It might be forcing a search from the store's root to "includes/...": /home/ACCOUNT/public_html/catalog/includes/... rather than the desired /home/ACCOUNT/public_html/catalog/admin/includes/... Does it look to anyone else like this might be happening? If so, what's the best fix? Is there anything yet in github that I could point people to?

When you include or require application_top.php, you have to use a relative path, because the various DIR_WS_* definitions haven't yet been defined. So, I suspect that on the admin side, you'd have to explicitly add "admin/" to the path: require('admin/includes/application_top.php');. This is only if you are using an explicit include_path pointing to the store root. Very messy, as it means that users doing that have to go in and update all files in the admin tree. I'm not sure how you could make it work "out of the box" for with and without the include_path entry. Any ideas, other than putting both application_tops in root/includes/ (includes/application_top_public.php and includes/application_top_admin.php)?

Once application_top.php has been called, all the DIR_WS_* defines should exist, so there's no reason not to give explicit full paths on any include or require: require(DIR_WS_INCLUDES . 'header.php'); rather than the lazy require('includes/header.php'); etc.

Does this problem also exist in v3.0? The same solution should be usable for both.

[MrPhil]

Still no joy. I have posted my question to the PHP development site, and it disappeared. I have given up on Computing.net, as only questions pertaining to Windows seem to get answered. Where else can I try?

Is the proper long term solution to give a relative path only for the top-most call (application_top.php), and in there define an absolute "base" path for everything else? That way you would

include('includes/application_top.php');

and it would define DIR_FS_CATALOG, which you use instead of a relative path:

include(DIR_FS_CATALOG . 'includes/languages/english.php');

and something similar on the admin side? The idea would be only use a relative path once, to find application_top.php, and thereafter only use absolute paths.

Would this work, and is it necessary for PHP 5, or is there something else going on?

[Mark Evans]

I've never had this issue before and have used a pretty wide range of hosting companies so I suspect there is something specific in the php configuration on the servers where this problem is found.

It would be interesting to take a look into the PHP config of people who have had this issue to see if there is something which is common across them all

[FWR Media]

I'm pretty much with Mark here .. never had an issue with the set paths.

Having said that the MS2.2 includes/configure.php methodologies seem a bit unnecessary now in my mind as realpath( dirname( __FILE__ ) . '/' to my current knowledge will sort out all the root app paths on initial bootstrap. ( both *nix and IIS )

Edited by FWR Media, 31 May 2010 - 10:31 PM.

[FWR Media]

FWR Media, on 31 May 2010 - 10:28 PM, said:

I'm pretty much with Mark here .. never had an issue with the set paths.

Having said that the MS2.2 includes/configure.php methodologies seem a bit unnecessary now in my mind as realpath( dirname( __FILE__ ) . '/' to my current knowledge will sort out all the root app paths on initial bootstrap. ( both *nix and IIS )

Well ..

realpath( dirname( __FILE__ ) )

but you knew I missed a bracket speed typing right?  

Edited by FWR Media, 31 May 2010 - 11:08 PM.

[shane h]

Hi All!

I'm having some problems and I'm unsure if this is something to do with the same cause.

PHP Warning:  require(includes/application_top.php) [<a href='function.require'>function.require</a>]:

This happens on main index and product info page and I'm unsure if this is the same thing.

Incidentally I also have

(include_path='.:')

with the same error code.

I'd like to try putting this code into the area of code.

realpath( dirname( __FILE__ ) );

Although I'm unable to find (include_path=) anywhere in the oscommerce pages.

Has anybody any suggestions.

Regards. Shane