I am currently using an image manipulation script to do some work on uploaded images and I'm running into a problem in my dev environment. This same code works on my production server.
The error is:
PHP Warning: imagecreatefromjpeg(): php_network_getaddresses:
getaddrinfo failed: Name or service not known in /path/to/script.php
on line 75
The line of code on 75 is:
$this->img = imagecreatefromjpeg(PHPTHUMB."?src=/".$this->image_path);
which creates an image that is loaded from another made by phpThumb, which is used for further manipulation.
Any ideas on how to solve this? Can anyone shed some light on what the error means?
Thank you,
Edit:
Just as a further bit of insight, if i visit PHPTHUMB . "?src=/" . $this->image_path in my browser, the image loads fine
User agent in php.ini did not solve the problem as indicated here
EDIT (SOLUTION): I had to add the INTERNAL 192.168.204.XXX IP into the hosts file, so that http://dev.mysite.com resolved correctly. Trying both 127.0.0.1 and the external IP yielded no result, but the internal works perfectly. Thanks for everyone's efforts,
I'm totally not sure about the cause of that error, but this is my best guess.
There is a particular PHP Setting which enables you to treat URLs as files. Normally imagecreatefromjpeg accepts a filename, I think. Since you are passing a URL, you need to make sure the particular setting is enabled. I believe you can find more info about it here: http://us2.php.net/file
filename
Path to the file.
Tip
A URL can be used as a filename with this function if the fopen
wrappers have been enabled. See
fopen() for more details on how to
specify the filename and List of
Supported Protocols/Wrappers for a
list of supported URL protocols.
Fopen wrappers: http://us2.php.net/manual/en/filesystem.configuration.php#ini.allow-url-fopen
Your dev environment may not be setup with this, but your production environment could be.
Edit
This page lists your error:
http://bugs.php.net/bug.php?id=11058
and mentions that a possible fix is by modifying your hosts file to explicitly include the ip/dns of the server you're accessing.
i tryed to reconfigure my named
configuration, without any result, to
fix this. the problem was solved by
adding the following line to my
/etc/hosts:
194.97.55.147 mx.freenet.de
Maybe you can try this?
did you also check that allow_url_fopen is set to On in php.ini?
I saw that they did mention that in the article you referred to in your post.
EDIT: Also, what OS and what PHP version are you running?
Just read this on php.net: "On Windows versions prior to PHP 4.3.0, the following functions do not support remote file accessing: include(), include_once(), require(), require_once() and the imagecreatefromXXX functions in the GD Functions extension."
EDIT2:
I just read what was written in the comments, your allow_url_fopen is set to On, sorry about that.
But OS, PHP version and phpinfo() would help in finding the problem.
The error message suggests something is wrong at a networking level. Thus, if possible, bypass that. Try using the path to the thumbnail generator, instead of a network address.
If that's not an option, try something that will give you more granular error messages. I suggest CURL. At the very least, it should yield a more informative error message.
The simple fact that this is failing is because on your webserver, your DNS resolution is broken.
If you have SSH access to your server, try the following command
dig hostname
where hostname is the host name from PHPTHUMB
This will probably fail.
Assuming that you're using Linux, my suggestion would be to edit your /etc/resolv.conf (as root)
and add the following line before any other lines beginning with "nameserver"
nameserver 4.2.2.2
This should hopefully fix things, though you may have to restart apache (or whatever webserver you're using)!
The issue here is that php fails to resolve the url that you provide as PHPTHUMB as stated in this bug report on php.net. This possibly means that it's the fault of the operating system/web server, in which case you can enter the ip address of the server you are connecting to into your hosts file manually.
Related
I was given a task of fixing an app after the update.
Presumably, the person who updated it said they updated it to 'Oracle 12c' - whatever that means, thought the path is: 'C:/oracle/product/11.2.0/' which sounds like it's still 11.2.0 or whatever.. not important.
Whenever I'm trying to run oci_connect(); with verified and tested credentials, the error pops:
Warning: oci_connect(): ORA-28040: No matching authentication protocol
I've searched around the internet, found 2 solutions:
download and add 'ojdbc8.jar' to 'C:\oracle\product\11.2.0\client_1\jdbc\lib' (hope the path is correct).
add the lines below to 'sqlnet' which I found in:
'C:\oracle\product...\network\admin\' and
'C:\oracle\ora92\newtork\ADMIN'
**I've changed in both to be
sure**.
The lines:
SQLNET.ALLOWED_LOGON_VERSION=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
Same result, neither worked.
Edit:
I've also noticed, there's no oradmin.exe nor oracle.exe in the bin folder, is this normal?
It sounds like the server is updated and now the client fails to connect. In this case the server needs to configured to allow older client to connect. Add the SQLNET parameters to the server sqlnet.ora file and restart the server.
So I have a website built in php and it was working perfectly on one server, I then moved the website to a server I have on Digital Ocean and am running into several errors, they seem to be based around http request failures while using the imagick library...
I was hoping to not to have to start debugging this from a code point of view as it was already working perfectly and would prefer to change server settings.
Fatal error: Uncaught exception 'ImagickException' with message 'Imagick::__construct(): HTTP request failed! HTTP/1.1 404 Not Found .
I cannot figure out what differences there, on both server allow_url_fopen is set to on.
The php version is different, 5.520 on the original server, 5.5.9 on the new server.
The versions of imagick are the same. I am also getting some other errors using the mpdf library but I will try deal with these later (Im hoping if I can resolved the first ones these ones will also get resolved).
My question is , is there possibly any other setting on the server I should be looking out for that may be causing these php errors?
EDIT:
Just to add more information, i can get rid of some of the errors by changing the file path https://www.example.com/myimage.jpg to /var/www/example/myimage.jpg . This solves some of the errors but I would rather get the root of the issue thats causing it not to work in the first place, because I feel that its the same problem thats causing other errors.
The error code says it: 404, file not found. You are probably using the wrong URL.
Are you able to fetch https://www.example.com/myimage.jpg using a webbrowser?
On several popular linux distros, /var/www/example/myimage.jpg would be served at https://www.example.com/example/myimage.jpg instead of https://www.example.com/myimage.jpg with the default configuration.
[edit]
It just came to my attention that the URL is HTTPS, there is a possibility that the script is rejecting the server certificate. Try with regular HTTP - no point in using SSL if the file is on the same machine.
I have problems after updating Zend FR to 1.11
Mimetype file checking generates:
Warning: string extension `B' invalid
It looks like cause of problems the string in the Zend_Validate_File_MimeType
$finfo = finfo_open(FILEINFO_MIME_TYPE, $file);
I have created simple test case
$finfo = finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic');
echo finfo_file($finfo, PUBLIC_HTML_PATH . '/images/missing.png');
finfo_close($finfo);
And i got same error :(
finfo_open(FILEINFO_MIME_TYPE, '/usr/share/misc/magic'); //generates: Warning: string extension `B' invalid.
My OS: Kbuntu 10.10
Where am i wrong?
Ran into the same error message ("Warning: string extension w' invalid in Command") as Mike Purcell, but the fix for it was different.
On our servers we had a /usr/share/misc/magic and a /usr/share/misc/magic.mgc file. The magic.mgc file had been compiled from the magic file, but PHP still wasn't happy talking directly to the /usr/share/misc/magic file (we'd shifted to that file as part of debugging that the magic.mgc file needed updating).
The fix for us was changing our putenv line back to the magic.mgc file:
putenv('MAGIC=/usr/share/misc/magic.mgc');
Then, magic-ally :-) , the whole mime-type detection system started working again.
This may not pertain to your EXACT issue, but it did resolve the issue I was having which resulted in a very similar error message: "Warning: string extension w' invalid in Command".
For us, we have a heterogenous setup where some servers are still running php 5.2 and others running php 5.3. On the 5.2 boxes the magic file resides in /usr/share/file/magic, but on the 5.3 boxes the file resides in the default path of /usr/share/misc/magic. Apparently someone tried to reconcile these path differences by symlinking the 5.2 path so the codebase could be php version agnostic. But according to some comments posted on PHP site regarding symlinks to the magic file, it will result in unexpected behavior, which of course was resulting in the aforementioned error message.
So be sure the path you are passing is to the actual magic file, and not a symlink, and see if that resolves your issue.
Depending on your PHP version the magic format may be updated. This is documented in a note at http://php.net/manual/en/function.finfo-open.php
run php -v to see your version
I got the same error when pointing to an older magic file in our source tree, and resolved it when pointing to a newer magic file from my current linux distro
I had this error in Laravel (minus Zend FR, of course). Running PHP 5.3.21 on a Windows box with IIS.
Finding very little info online I was close to giving up. It worked initially when I followed instructions in the comments on PHP.net, which were basically to add fileinfo.dll to your PHP installation, and to also download the relevant magic files and point an environment variable to them.
There was some initial confusion until I realised I didn't actually have php_fileinfo.dll, so as well as adding it to the php.ini file, I had to download the file itself and add it to my ext directory.
Now what really had me stuck, was that it worked initially. The next day it didn't. To cut a long story short, it didn't need the environment variable, MAGIC. The reason this had me stuck, is because I had tried every possible scenario, but once the environment variable had been set, it had been set. And I had to restart the Windows server after removing it, to unset it. Once I did this it worked perfectly.
I am currently moving my web app to amazon ec2. Since it's only for testing, I use the free version called ec2 free tier with windows server 2008 instance. However, Although I have done all I know and read this thread ( How to enable cURL in PHP / XAMPP ). I just couldn't use curl on my php script. it always creates the error
Call to undefined function curl_init() in C:\xampp\htdocs\index.php on line 2
Here are all thing I have tried
Install Wamp ( I tried it on XAMPP to)
Uncomment out php_curl in php.ini file ( and restart apache)
Copy two dll files to both system32 and syswow64
Could it have to do with the fact that I am using free vps?
Update:
Also, when I started the apache server in XAMPP , this error appeared
'PHP Startup: unable to load dynamic library curl.dll'
However, I have double checked the ext directory and the php_curl.dll was in there.
i think curl need to access remote sever from our web server. so i opened all traffic in my server outbound rule and it works. i think this is not good solution. still look for better way.
nope.
be sure, that you have the files in the right place, usually its in the plugins folder for php! maybe you cann add a absolute path to your php.ini!
be sure, you edit the correct ini file!
php completly independent to your operatingsystem!
just be sure to doublecheck everything. because its not saying, it has trouble loading your extention, its just saying, the function your trying to call, is not there. so i assume your extention ist not loading at all! :)
One reason I did notice for this cURL plugin to malfunction was the availability of copies of libeay32.dll and ssleay32.dll files. Please check whether your system32 folder has such copies and if so, please rename them to some other names and copy the ones found with the php installation. Sometimes you may need to restart your machine. This was documented here some time ago.
I had a similar problem, but it occours just with requests under https. I tried to create a curl request directly from the ec2 machine and got a error: "curl: (77) error setting certificate verify locations".
It looks like some kind of ssl validation fail because of a certificate not found. So I used a parameter -k (or --insicure) in my curl command, to ignore this validation and after that my curls request did directly from ec2 machine worked.
So I tried to apply a similar ideia in my curl command in php, (I suppoused that the curl php extension forward this requests to the operation system) and I found this curl opt:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
After that it works to me.
Probably this isn't the best way to solve the problem, but solved my problem temporarelly.
I have my online shop, created with WP Ecommerce getting broken after I moved it to another server. I could be sure that the problem comes from WP Ecommerce because when I disable that plugin. Everything run as expected. This is the exact error message
Warning: session_start() [function.session-start]: SAFE MODE Restriction in effect. The script whose uid is 515 is not allowed to access /tmp owned by uid 0 in /home/mikalu/public_html/wp-content/plugins/wp-e-commerce/wpsc-core/wpsc-constants.php on line 17
Fatal error: session_start() [<a href='function.session-start'>function.session-start</a>]: Failed to initialize storage module: files (path: ) in /home/mikalu/public_html/wp-content/plugins/wp-e-commerce/wpsc-core/wpsc-constants.php on line 17
I've tried to turn off safe mode on my php configuration. nothing happens. the error's still there.
I thought it was some kind of permission issue, so I tried to change /tmp permission to 777. Nothing happens. I googled it some more and suspect it might have something to do with fastCGI configuration and stuff. Which I totally don't understand.
My googling result mostly suggest me to consult the web hosting provider or even to move to another host. But in this case, I am the owner of the server (VPS with cPanel/WHM). And I don't have any idea how to solve this kind of problem
Any help would be very much appreciated :)
edit: I'm not so sure of this is really a server issue. Because if it really server configuration issue on session save path. Then the whole wordpress shouldn't be working coz it obviously use some session too. The session problem only come from that particular wp-ecommerce script. That's why I post it here on stackoverflow too.
After your edit, it's more clear why you ask that question. Wordpress itself does not uses PHP session, so it's not causing the issue but those component you're using is using PHP sessions.
The PHP manual normally is a good start to understand safemode and how to disable it: http://php.net/manual/features.safe-mode.php
Additionally you should review your server configuration that it is safe instead. Safe-mode is unsafe. Hopefully your server ain't.