So I came up against something really strange today.
I've updated my PHP APC to the latest version and restarted apache. And then suddenly all scripts in apache starting complaining about not being able to find required files.
I would usually have:
require_once 'Abstract.php'
considering that Abstract.php is on the same directory as the other script.
The errors where:
PHP Warning:
require_once(Abstract.php) [function.require-once]:
failed to open stream: No such file or
directory in data.php on line 411 PHP
Fatal error: require_once() [function.require]:
Failed opening required 'Abstract.php'
(include_path='/var/www/application/../library:/var/www/library:.:/usr/share/php:/usr/share/pear')
in data.php on line 411
As you can see the current directory (.) is included in the include_path of the execution. Why did this happen? Has anyone seen it before?
AFAIK, the . denotes the directory where the PHP binary resides. require* and include* functions take into account the current working directory, which can be modified via chdir().
As was suggested by cwallenpoole, try using the __DIR__ constant:
require_once __DIR__ . '/Abstract.php';
If that also fails, it means there's a misconfiguration elsewhere. If it works, it probably means the current executing PHP thread has its working directory set to a different and you need to either change the current working directory or modify the require statements to use absolute paths.
Also, have you considered using an autoload callback? That way you have a single point of entry for searching for classes.
Ok, I figured it out eventually and though I should share in case anyone else gets in the same trouble as me.
I used to have APC 3.0.x and upgraded to 3.1.8. As it seems APC on 3.1.8 has a bug that breaks include/requires of PHP.
See relative link here: http://pecl.php.net/bugs/bug.php?id=22687
Thanks everyone for the quick feedback :)
Related
My website used to work perfectly fine a few months ago. However, since changing host last month some parts of my website no longer work.
I am very sure the issue is related to GeoIP. My website requires the GeoIP php extension for it to work correctly. Both the old and new server have this extension enabled.
I get the following errors on my new server. Please note that the file "pdf_after_checkout_generator" is a custom made plugin.
PHP Warning: include(/usr/share/GeoIP/geoip.inc): failed to open stream: No such file or directory in /home/jksastrology/public_html/wp-content/plugins/pdf-after-checkout-generator/pdf_after_checkout_generator.php on line 18
PHP Warning: include(): Failed opening '/usr/share/GeoIP/geoip.inc' for inclusion (include_path='.:/opt/alt/php56/usr/share/pear:/opt/alt/php56/usr/share/php') in /home/jksastrology/public_html/wp-content/plugins/pdf-after-checkout-generator/pdf_after_checkout_generator.php on line 18
PHP Fatal error: Call to undefined function geoip_open() in /home/jksastrology/public_html/wp-content/plugins/pdf-after-checkout-generator/pdf_after_checkout_generator.php on line 20
I contacted my current host about this issue. I asked them what the file path is for the GeoIP extension on their server. They provided the following response (see bottom of post).
I would appreciate answers to the following questions:
I am not sure how to implement a solution. They are saying the file my website requires is not in their GeoIP extension file. Does this mean I need to install files (within the link they supplied) to my main wordpress site? then point my broken include code to the newly downloaded geoip.inc file?
I have no idea what this particular error is about. It is referencing PEAR, and I am not sure why.
PHP Warning: include(): Failed opening '/usr/share/GeoIP/geoip.inc' for inclusion (include_path='.:/opt/alt/php56/usr/share/pear:/opt/alt/php56/usr/share/php') in /home/jksastrology/public_html/wp-content/plugins/pdf-after-checkout-generator/pdf_after_checkout_generator.php on line 18
Hi there,
This would vary depending on what package you have I suspect, the
server I checked has the dat file (/usr/share/GeoIP/GeoIP.dat) present
but there is no PHP include file there.
The simplest fix would be to move the PHP dependency into the code
base of the application rather than relying on a globally shared
version. We don't as a rule install things like this globally as if it
was then updated and the API changed it would break everyone that
depended on its code.
You would need to check the .inc file on the old server to confirm but
this code is probably the code in this GIT repo so it would be simple
enough to move in to the base application -
https://github.com/maxmind/geoip-api-php
This has nothing to do with pear. The PEAR Net_GeoIP package has no geoip.inc file.
I guess that you have to put the source code of https://github.com/maxmind/geoip-api-php/ into /usr/share/GeoIP/ directory.
I generally work with WAMP but for some reason had to switch over to XAMPP.
Ran into this really weird problem. When i try to read a file using file_get_contents i get an error saying that the file/dir does not exist EVEN THOUGH IT DOES.
Even if something as simple as
file_get_contents('x.txt');
throws an error
Warning: file_get_contents(x.txt): failed to open stream: No such file or directory in C:\xampp\htdocs\cryy\index.php on line 3
And yes, i've tried using the magic constant
__DIR__
to no avail.
I'm using XAMPP 3.2.2 and PHP 7.0.18, running on Windows 10.
I hope someone can help me figure this out.
Try providing full path of the you want to get content. If you want to access file from root of the folder, then you can use
file_get_contents($_SERVER['DOCUMENT_ROOT'].DIRECTORY_SEPARATOR."project_folder".DIRECTORY_SEPARATOR."filename.txt");
OR
file_get_contents(__DIR__.DIRECTORY_SEPARATOR."filename.txt");
I am in the process of moving a PHP website from a shared hosting server to a DigitalOcean server. I have come across an issue that I'm not sure how to debug.
There is a page that has a log-in form with action=2/login.php. This form is located in /var/www/html/calendar.php (it is a Ubuntu 14.04 DO droplet). When submitting the form, there is a 500 Internal Server Error. I've found the error in question but I am not sure how to debug it (because it runs fine on the other server).
/var/www/html/2/login.php
<?php
require_once('../db_connect.php');
...
db_connect.php is located at /var/www/html/db_connect.php
When I $php 2/login.php I get the following error:
login_error.txt
PHP Warning: require_once(../db_connect.php): failed to open stream: No such file or directory in /var/www/html/2/login.php on line 4
PHP Fatal error: require_once(): Failed opening required '../db_connect.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/html/2/login.php on line 4
When I run $php login.php when in directory /var/www/html/2 it works fine (which I guess makes sense, as ../db_connect.php is a relative path).
I want to know why it is working on the other server and not the DO server?
The php.ini is the same (which could be a problem), but on Server #1 (Verve), it is shared hosting, so our root is /home/[username]/public_html and on the new server is is /var/www/html.
I can link to the live sites in question if necessary (but would prefer not to). The /var/www/html/2/login.php and the /var/www/html/calendar.php scripts are exactly the same, and while I understand this will definitely cause issues later as the absolute path to the root of the web application is different, I don't know what would be causing this specific issue.
I have also looked at this question which is very similar: PHP require_once resetting to current working directory. However, this code works on the other server, and not here, so I think there is something more than just a lack of a relative file path, and I would prefer to find the solution that explains why the script isn't working rather than patching the script, as I'm pretty sure I'd have to change every single other script that uses require_once('../db_connect.php') as well.
Thanks for any help!
Did you try using __DIR__?
require_once(__DIR__ . '../db_connect.php');
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.
I've got some functions in my file that require taxonomy.php to execute. I'm attempting to include the file like so...(this is called from functions.php, which is located in wp_content/themes/mytheme/
include($_SERVER['DOCUMENT_ROOT'] .'/wp-admin/includes/taxonomy.php');
However, depending on the particular server setup, its hit or miss (mostly hit) whether the include will be found. In the case its not found, I get this error...
Warning: include(/home/user/domainname.com/wp-admin/includes/taxonomy.php) [function.include]: failed to open stream: No such file or directory in /home/user/domainname.com/testing123/wp-content/themes/mytheme/functions.php on line 10
UPDATE: Assuming I'm already doing about as much as I can by using DOCUMENT_ROOT, is there a means of avoiding the error that occurs when the file is not found? And I will be checking for function_exists in any functions that require taxonomy.php so as to suppress errors...
Well, the only way to bulletproof this is to actually configure it on each server you deploy it on. If you can't assume document_root is a reliable factor, I can't imagine any other variable that could give you a better result.
You could start searching for taxonomy.php but that is expensive, and horribly prone to failure or picking the wrong file (what happens if my neighbor has wordpress installed in /home/user/domainname2.com?
If your application depends on a particular file, you should be using require/require_once to ensure your application does not partially load despite missing the required file.
As for making sure that file always exists and is in a place you need it, you could move that to a configuration file and allow the user running the software to set it, along with auto-attempting to find the find in the event the user is clueless.