I am trying to get my Zend application started on production environment, but i get this error:
Warning: require_once() [function.require-once]: Unable to access /var/www/web1/html/tool/lib/Zend/Loader/AutoLoader.php in /var/www/web1/html/tool/public/index.php on line 24
On development environment everything works just fine, so I figured it has to be a misconfiguration of the server.
Any ideas what could cause the problem?
I'm guessing the development system is Windows and the production environment is *nix.
The correct filename should be:
Zend/Loader/Autoloader.php
not
Zend/Loader/AutoLoader.php
Note the L vs. l. Windows filesystems are case-insensitive but your production environment is most likely case sensitve which is why it can't open that file.
If that isn't the problem, make sure the permissions on the Autoloader file and parent directories are readable by the web server.
Related
This is structure I have. Page add-product.php is in folder public_html. Partial page ConnectQuery.php I need to access is in folder partial.
My project worked fine on localhost with wamp. Now I uploaded it to server and pathing got screwed.
Error I get:
Warning: include(/storage/ssd3/728/17657728/public_html/partial/ConnectQuery.php): failed to open stream: No such file or directory in /storage/ssd3/728/17657728/public_html/add-product.php on line 13
Line 13 in add-product.php is
include __DIR__ . "/partial/ConnectQuery.php";
EDIT: There is one more error
Warning: include(): Failed opening '/storage/ssd4/729/17661729/public_html/partial/ConnectQuery.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /storage/ssd4/729/17661729/public_html/add-product.php on line 13
usually paths never work the same way unless the development machine and server OS are same and they handle directories and files the same way -
Say if your development machine is Windows your Drive C:// will be there
its not the same in case of Linux and most of the servers are on linux and hence you're facing paths issue try using a path library in your case
in Node js there is path ;
which will point to current directory from you're running your project and from there on the paths will work with no issues .
Check the case in the spelling of the filename ConnectQuery.php.
Is it maybe connectQuery.php (like you wrote in another question)? Or connectquery.php?
Windows ignores differences in the case of file names, Linux doesn't.
If you are using PHP <= 5.2 than you have to try as below
$dir = dirname(FILE);
include($dir.'/partial/ConnectQuery.php');
Please try this and if you using some other php version than mention it here
I used to have problems with includes in my PHP projects between localhost and the actual server. I was able to get rid of this by using dirname(__FILE__). In your case you would use the following in your add-product.php
include dirname(__FILE__)."/partial/ConnectQuery.php";
This bypasses some weird standard include path errors by providing the full path of the current files directory.
I think this is all caused by directory separator issue.
Check the case of the ConnectQuery.php filename.
Windows is case-insensitive which means that WAMP will find a file named connectquery.php even if you requested CONNECTQUERY.php
Linux won't. If you request a file named CONNECTQUERY.php, it will search for this exact filename.
I advise you to adopt a convention : only lower-case letters for filenames. This will save you a lot of headaches.
As a learning exercise I used Symfony to update an existing application for a local non-profit. Development was in a Windows environment. Now that the application has been installed on their ISP's shared host I start to learn about chroot on a FastCGI server. There are errors such as this:
PHP Fatal error: Uncaught exception 'UnexpectedValueException' with
message 'The stream or file
"/home/projectmana/www2.projectmana.org/app/logs/prod.log" could not
be opened: failed to open stream: No such file or directory' in
/www2.projectmana.org/app/cache/prod/classes.php:4823
The ISP responds with:
Bad path. PHP is chrooted in /home/projectmana/.
OK. I get it that this is the problem. Web searches so far have not provided a clue as to how to proceed. (I've gained greater appreciation for Symfony wanting to avoid shared hosting.) Is there a solution that I, a relative novice and a volunteer, can implement in my code, or does the application have to find a new home?
You've got to set the doc_root variable according to your chrooted directory:
doc_root = "/home/projectmana"
cgi.fix_pathinfo = 0
You do this in the php.ini file - which seems to be not an option for you since you're on a shared server environment. When using Apache as a webserver, you can use a .htaccess file and set the proper PHP directives there via php_value.
The solution in this instance was to override the locations of the cache and logs directories according to the cookbook. This, however, by itself causes the cache:clear command to fail. The answer to that problem will have to appear in another question if I can't find it on my own.
Update
The other solution here cannot work because any php setting in .htaccess when Apache server is running FastCGI will cause a server error. Clearing the cache was never solved so the site was moved to a non-CGI host.
I primarily use Mac OSX for programming and then test it in windows periodically. I just installed XAMPP on a Windows 7 computer and I'm getting the following errors
Warning: _cake_core_cache was unable to write 'cake_dev_en-us' to File cache in C:\Program Files\xampp\htdocs\testproj\lib\Cake\Cache\Cache.php
Warning: C:\Program Files\xampp\htdocs\testproj\lib\Cake\Cache\persistent is not writable in C:\Program Files\xampp\htdocs\testproj\lib\Cake\Cache\Engine\FileEngine.php
I opened up the testproj folder properties and unchecked Read Only and applied it to all folders/subfolders. I tried to open the Cake application again and the same error message was displaying so I checked the folder properties again and it had a square in the Read-Only box, not a check mark. Does that signify anything? I'm not sure what exactly the square means instead of a check mark.
I am signed into the administrator account on this computer. Is there some kind of command similar to chmod -R 777 for windows?
Thanks
Update - I changed the installation from Program Files to C:\xampp... and I still get the errors. I then created a partition and installed xampp to G:\xampp... and the error still exists
Using C:\ and especially the Program Files folder is a really bad idea for developing with PHP on Windows. Use another partition or at least a folder outside of system internal folders.
There is a reason WAMP and most tools by default try to install themselves in C:\wamp\ etc.
Edit: also try to avoid folder names with spaces in them like the windows-stupid "Program Files" default folder. And mind your casing, even if that is not directly visible in Windows, it will otherwise kill your app when going live with it on a unix server.
I'm experiencing some weirdness trying to setup PEAR on my development machine (Windows XP).
The process is simple enough and everything makes sense, but I'm trying to use one of the installed packages which calls on the PEAR.php file and am getting:
Failed opening required 'PEAR.php' (include_path='.;C:\Program Files\PHP\PEAR')
It's a pretty straightforward error to get assuming the file/path doesn't exist, except I've checked and double checked - it absolutely does - right down to capitalisation (which I know doesn't matter on Windows normally but still...)
What can I possibly have overlooked that means the file can't be opening?
Just to re-iterate, the file/dir DEFINITELY exists as C:\Program Files\PHP\PEAR\PEAR.php - and I have also tried:
forward slashes
short dir names (Progra~1)
all lower case (even though the files are as is) and even setting the include path to
ONLY that directory.
test.php in same directory
test.php in c:\ and with include path set to c:\ and just \
PHP (5.2.6) is NOT running in safe mode, and the web server is Apache 2.
Maybe your php configuration has open_basedir set? If so, set it's value to none.
Try one of these:
C:/Program\ Files/PHP/PEAR/PEAR.php
C:/Program Files/PHP/PEAR/PEAR.php
I have a couple files that look like this:
index.php:
<?php
include('includes/header.php');
...
includes/header.php:
<?php
include('config.php');
...
The error I get is
Warning: require(config.php) [function.require]: failed to open stream: No such file or directory in [dir]/includes/header.php on line 2
Fatal error: require() [function.require]: Failed opening required 'config.php' (include_path='.:/usr/share/pear:/usr/share/php') in [dir]/includes/header.php on line 2
I did some further debugging: when I add the call
system('pwd');
to includes/header.php, it shows [dir], where it should say [dir]/includes. Adding the 'includes/' to the include path works, but isn't desirable because that would fail on the production server.
The above code works on a production server, and worked fine on my development Fedora server, until I tried to change my development environment so that the Fedora server's document root is a mounted CIFS share.
Any ideas? Thanks.
worked fine ... until I tried to change my development environment so that the Fedora server's document root is a mounted CIFS share.
Is SELinux enabled?
Check /var/log/audit/audit.log
I'm going to wager that SELinux is enabled and in enforcing mode, and is interfering.
I hate to say it, but the behavior with pwd that you're describing is 100% expected behavior (and has been since at least PHP4... probably earlier).
PHP automatically sets the current working directory (used by pwd) ONCE. PHP does not change it. Thus, . will refer to the original current working directory unless you manually change it with chdir().
There are various solutions to this problem used; most of which you can see at PHP include file strategy needed.
If it worked before, there was probably some updating of the include_path somewhere, code that changed the the working directory no longer changes it, or the php version you used that implemented this odd (but more expected) behavior no longer does so.
Anyways, I'd check the include paths: ini files, or scripts that change the include path. I'm guessing something used to update the include_path, but no longer does so.
I'm not sure about the details of how you moved it but I've encountered some annoying scripts where an .htaccess set an auto_prepend_file to a hardcoded path to a file completely outside the website structure, that set the include path (among other things) to somewhere inside the web structure.
Mounting the CIFS share with the option 'noserverino' should resolve the issue, for example:
mount -t cifs -o noserverino //host/share /mnt
Full explanation of why this works can be found here: http://www.php.net//manual/en/function.is-dir.php#98338