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.