I was asked to fix a site that was fine just days ago and now is not able to include files due to the host's upgrade of the PHP to v.5.3
There's a script that reads directory and builds a list of PDFs in it. FOr some reason the script stopped working and I get the following error messages:
failed to open dir: No such file or directory...
However I see the directory on the server and if I point to a file directly it opens.
Earliuer I had an issue when I was trying to include files and was getting somewhat similar messages. It seems the problem is caused by a deprecated php.ini setting: register_globals = on. in PHP 5.3
What are the possible solutions?
May be this dir was in old php.ini include_path directive
Related
My website currently runs on PHP 5.2 on an Apache Linux server (according to my hosting providers info). I want to upgrade to at least PHP 5.5 since there is a feature I need available from that version and above. I am open to also use higher versions like 7, but every version above 5.2 brings the following problem:
When running in PHP 5.2 I successfully added a custom include_path additionally to the default one in the php.ini
php.ini:
[PHP]
include_path = ".:/usr/local/lib/php:/custom/include/path"
register_globals = Off
In the above php.ini code the default path which was already set is
/usr/local/lib/php
and the one I added is
/custom/include/path
(I removed personal information by changing path and file names).
I should mention that the additional include_path is not in the same folder structure. In fact, it is on a different domain. Still the same server, but a different domain, so for the additional path I have to go through the root path of my providers users/... path.
(The domains share the same website content, just in different languages. That is why I want both to be able to access and process a common main include_path since they use the same scripts).
In my website I include php files commonly just like this:
website.php:
<?php
require_once 'external_script_file.php';
?>
As I said, in PHP 5.2 everything runs smoothly. The file is loaded and processed. But as soon as I switch the PHP version up to let's say 5.5 I get this error:
Error in browser:
Warning: require_once(external_script_file.php): failed to open stream: No such file or directory in /[server_path]/website.php on line 7
Fatal error: require_once(): Failed opening required 'external_script_file.php' (include_path='.:/usr/local/lib/php') in /[server_path]/website.php on line 7
(I removed personal information by changing path and file names).
As you see in the error message, he seems to only be able to see the default include path, but not the added custom one.
Do I have to manage something differently regarding the php.ini settings file when operating in a higher PHP version? Or what else could be the issue?
Thanks a lot!
You can try using set_include_path() function in your code.
set_include_path('/usr/lib/pear');
Or ini_set()
ini_set('include_path', '/usr/lib/pear');
You didn't mentioned any information about the system you are trying to run PHP on (i.e. what OS, web server, etc), so this is a shot in the dark. If you have multiple PHP versions installed, it's possible that each version has its own php.ini file.
On the page you are trying to load, stick phpinfo();die; at the top of the file. Run the site in PHP 5.2, and see what the "Loaded Configuration File" value is. Then, switch to a newer PHP version, refresh the page, and check if the "Loaded Configuration File" value is the same or not.
Just an accident!
Either the php.ini generator I used, or just me copying back and forth created a space at the beginning of the php.ini file, right before the title [PHP]. Apparently PHP versions higher than 5.2 can't handle that.
So just make sure to not create any unneccessary spaces within, or especially at the beginning of the php.ini file.
I have been a happy user of XAMPP for years,
but today I have updated to the latest Windows 32 bit version on a Windows 10 machine.
I couldn't see a 64 bit version.
Anyway, all went well,
and once I changed some settings, I was able to see all my old databases under the new phpMyAdmin.
But my PHP scripts are bombing out before they start.
Even phpinfo gives the same error message, which is...
"Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0
Fatal error: Unknown: Failed opening required 'F:/My Documents/OneDrive/Webs/htdocs/index.php'
(include_path='.;C:/xampp/php/pear/PEAR') in Unknown on line 0"
The test script of index.php is nothing more than
<?php echo "HELLO"; ?>
The statement in php.ini is
include_path = ".;C:/xampp/php/pear/PEAR"
and there are no other include_path statements.
The directory C:/xampp/php/pear/PEAR does exist.
The index.php file is there.
I don't know why there's a PEAR folder inside a pear folder - that's how Xampp installed it.
I have tried all variations of that include_path statement to no avail.
I have left out one of the pears.
Leaving out the include_path statement altogether just results in the PHP default which is a folder which is definitely not there, so that's no good.
My localhost is inside the OneDrive folder as you can see from the error message, but I have been doing it that way for years.
Now I cannot run any PHP scripts. Pure HTML is no problem.
The new installation of Xampp has totally replaced the old one, and its Control Panel v3.2.2 looks to be working perfectly.
phpMyAdmin seems to be working fine, but not phpinfo, as said.
I have scanned the web for answers to this, and there is plenty of forum Q&A's, but they all tell me to do what I have done.
The computer is Windows 10 Pro, and is fully up to date. Apache 2.4.33.
PHP 5.6.35. Database server is 10.1.31 MariaDB.
I've run out of ideas. Any help will be appreciated.
Thanks Mike.
You need to fix your include_path system variable to point to the correct location.
To fix it edit the php.ini file. In that file you will find a line that says, "include_path = ...". (You can find out what the location of php.ini by running phpinfo() on a page.) Fix the part of the line that says, "\xampplite\php\pear\PEAR" to read "C:\xampplite\php\pear". Make sure to leave the semi-colons before and/or after the line in place.
Restart PHP and you should be good to go. To restart PHP in IIS you can restart the application pool assigned to your site or, better yet, restart IIS all together.
first: check all the paths in the php. ini ( use a search or a grep to check them)
second: check that you don't have any extensions added twice (one in the beginning and one in the end of the file)
I am trying to setup a local version of a website that I can do some testing on. Currently when I open the site in my browser I get this php error:
( ! ) Exception: Facebook needs the CURL PHP extension. in
C:\wamp\www\mysie.tld\includes\facebook-graph\base_facebook.php on
line 19
So I did a bit of reading up and saw that this was most likely due to my WAMPserver not having the extension enabled for PHP. I did a phpinfo() and this output the .ini file that was being loaded.
C:\wamp\bin\apache\apache2.4.2\bin\php.ini
I opened this file up in my text editor and removed the semi colon before this line:
extension=php_curl.dll
I then restarted the WAMPServer and reloaded my site. Unfortunately, the error persisted and I do not know what I can do to fix it! Any help would be much appreciated.
Managed to figure it out with a quick scan through some similar questions on SO. If anyone is running into the same issue it was due to a bug in the curl.dllfile that came with WAMP 2.2. In order to rectify the issue I downloaded the php_curl-5.4.3-VC9x64.zip from this link:
https://code.google.com/p/justintung/downloads/detail?name=php_curl-5.4.3-VC9-x64.zip&can=2&q=
I then moved and replaced the curl.dll file in the downloaded folder with the curl.dll file located in my php ext directory.
Restarted WAMP and the problem was resolved.
I am working on deploying a Laravel app to a bluehost server and I am running into some trouble.
Currently, I uploaded all of the Laravel files to the root of the server, then uploaded the contents of the "public" folder to the "public_html" folder. From here I opened the "bootstrap/paths.php" file and changed the public path to
'public' => __DIR__.'/../public_html',
After this, I am still unable to get content to display. Am I missing something? It looks like bluehost is running PHP 5.4.24.
Any help with this would be appreciated.
Thanks!
EDIT: The error log shows
[09-Apr-2014 09:04:02] PHP Fatal error: require() [function.require]: Failed opening required 'DIR/../bootstrap/autoload.php' (include_path='.:/usr/lib64/php:/usr/share/pear') in /home1/regmuel/public_html/index.php on line 21
Could anyone help me figure this error out. I can clearly see what the problem is, I'm just not sure how to go about fixing it.
It looks like __DIR__ isn't getting parsed, are you sure your host isn't running PHP 5.2.* if you run phpinfo() on your host what version does it give?
__DIR__ is only available from PHP 5.3.0 onwards
RMcLeod's answer is perfect, just wanted to add to it something that I ran into with my web host (specifically Bluehost). Even after the version of PHP running on the server was 5.4.40 (found using php -v via an SSH terminal), I was running into the same problem where it was picking up an older version of PHP when interpreting my index.php and wouldn't recognize the DIR constant.
I had to add the line
AddHandler application/x-httpd-php54s .php
to the top of the .htaccess file which is in the same folder as my index.php
Just for context, I was trying to set up my laravel 4.2 app on bluehost and it relies heavily on this constant.
Note - this problem is resolved, but I'm posting here to find insight into what was happening because I don't understand.
My shared host's default configuration is PHP 5.2.17. When I asked them if I could upgrade to 5.3.X they said sure, and to quote:
A handler for PHP 5.3 is added to our shared and reseller servers for
those who wish to utilize it. In order to utilize this handler, you
will need to add the following code to your .htaccess file:
Action application/x-hg-php53 /cgi-sys/php53
AddType application/x-hg-php53 .php
To elaborate further on why we do not currently have this by default,
it is due to compatibility issues of older PHP scripts with the new
5.3 version. So, to prevent breaking the older scripts on our client's sites we have left the default PHP version as 5.2.X.
So I did that and quickly discovered that this killed my sites using PDO. Calling new PDO(); resulted in class not found errors in the log.
The shared host's support response was:
Our PHP 5.3 installations do have PDO enabled already. The issue here
appears to be caused by a custom php.ini based on the php.ini for PHP
5.2, so it attempts to load the PHP 5.2 modules instead of the PHP 5.3 modules.
ok seems reasonable, says I, now go ahead and fix that!
They updated the .ini file, and added the handlers to my .htaccess, and...
Your site appears to load correctly, but let us know if you find any problems.
which was true, now the main site and PDO were working fine and a phpinfo() check indeed confirmed I was on 5.3.8, but then several hours later a cron job died a fiery death:
[16-Dec-2011 03:00:01] PHP Warning: PHP Startup: Unable to load dynamic library '/opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so' - /opt/php53/lib/php/extensions/no-debug-non-zts-20090626/pdo.so: undefined symbol: gc_remove_zval_from_buffer in Unknown on line 0
and the error log from the cron job directory:
[16-Dec-2011 03:00:01] PHP Warning: require_once(../pghqClasses/PDO.php) [function.require-once]: failed to open stream: No such file or directory in /home/XXXXXX/pghqIncs/initCron.php on line 19
So once again the PDO calls were failing, but this time only for cron jobs.
The support team's final reply was:
I've seen this behavior before, where relative paths in PHP scripts don't point to the right place. According to the PHP manual, one if the differences between the CLI php and other interfaces for PHP is that CLI PHP won't change directories to that of the script. http://www.php.net/manual/en/features.commandline.differences.php
To fix this, I've added the line:
chdir( dirname ( FILE ) );
to the top of your cron script so that, when executed, it WILL change directories to that of the script, therefore making the relative path work. When run from the website, this line will essentially do nothing, but it should make your cronjob run correctly.
And it does indeed work. My cron jobs are running smoothly, and my main site is good, and everyone is happily on 5.3.8, but that last bit of trouble-shooting totally lost me and I'd like someone to explain to me how the includes can fail for a cron but NOT for a public_html script, why we're chdir(), and so on?
Thank you, and sorry about the length...
The problem is that the cron job, which uses the command-line PHP executable is running with the current directory as the location of the PHP executable, or the home folder of whichever account is running the job. Therefore, any relative paths in the script are resolved relative to that location, rather than the directory containing the script.
By adding the the chdir() call you're setting the current directory to the location expected by the script, and therefore your relative paths resolve correctly.