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.
Related
So I was updating our web servers (Windows 2012 R2/IIS) with the newest version of PHP this morning (version 7.4.8 from 7.4.6, because I was slacking 2 weeks ago).
In our setup, we include the dll from Microsoft (php_pdo_sqlsrv_74_nts.dll) in the ext folder as we have some sites running some PDO lookups to some backend SQL servers. After I registered the new version, I started getting errors in those PDO calls (PDO is loading), but I'm getting cannot find driver. As soon as I switch back over to 7.4.6, everything loads.
I didn't see a newer file provided from Microsoft yet. Is anyone else seeing this behavior or have a fix for it yet?
Thanks,
Since I had more then one php version installation.I had to specify the specific extension folder in my php7.4.8 ini file. i.e.extension_dir = "C:/php7.4/ext"
Everything worked fine after that
Since there could be multiple PHP version side-by-side.
1.Please ensure your IIS PHP-CGI handler is pointing to the right version.
2.Please ensure you have copy the dll to the right ext folder
3.Please ensure you have set the correct extension_dir
4.Please ensure you have registered the extension=..... correctly.
5.Please do an IISRESET when you finish updating the configuration.
You can try to double click php-cgi.exe to check the real exception. If everything is set correctly, there might be some compatibility issue.
Have you tried to double click php-cgi.exe to check the real
exception? If there is a issue, there should be an error message. Have
you encountered any error message?
No error after double clicking php-cgi.exe
So this was eventually fixed in the release of 7.4.10. It was a little known error it seems, but they got it fixed.
Another one for this error that is driving me nuts.
I've read literally 50 posts in stackoverflow and tried all different solutions:
Checking php.ini to see if the extensions are enabled and the folder to check if the dll's are present
Also tried extracting a php_pdo_mysql.dll file from the latest php version, checking if maybe the xampp original file was broken or corrupted with no luck.
Setting the path in environment variables
This is what I'm using for my local environment:
Xampp 7.2.4
PHP 7.2.4
Apache 2.4.33
And this is my code:
return new PDO('
mysql:host='.Env::getInstance()->env('dbhost').';
dbname='.Env::getInstance()->env('dbname'),
Env::getInstance()->env('dbusername'),
Env::getInstance()->env('dbpassword')
);
Is there something I haven't tried? please I want to fix this issue for once and for all.
Thanks in advance.
The arguments passed to the PDO constructor must be like $dsn in the example of the php manual below.
<?php
/* Connect to a MySQL database using driver invocation */
$dsn = 'mysql:dbname=testdb;host=127.0.0.1';
$user = 'dbuser';
$password = 'dbpass';
try {
$dbh = new PDO($dsn, $user, $password);
} catch (PDOException $e) {
echo 'Connection failed: ' . $e->getMessage();
}
?>
It looks like your first argument has the wrong content.
I posted the solution as an answer
I'm running into an odd issue while migrating some PHP code to a new server. The old server is running PHP 5.3 (x86) and the new server is running PHP 7.0 (x64). Both are running on IIS 7.5.
The code causing the issue has been in production without issues for almost three years. It runs fine on the current production server as well as two development systems. All three are running PHP 5.3 (x86).
These errors do not occur when I use PHP 5.3 (x86) on the new server.
A shared file (named _common_funcs.php) contains common functions that are called from many scripts. Since some of these scripts can interact I use require_once('_common_funcs.php') to include the file. This is approach pretty basic.
On the new server the first time a the script runs it generates a 'Cannot redeclare' error. Refreshing the page does not display the error - it displays the page as expected. For example:
//localhost/app/display_account.html?account=123456 generates the error.
//localhost/app/display_account.html?account=123456 again does not display the error.
Restarting the IIS server causes the error to be generated again on the first run.
Now for the odd part. Note the capitalization of the drive letters in the error below:
Cannot redeclare acct_has_graduated() (previously declared in D:\app_directory\includes\_common_funcs.php:2061) in d:\app_directory\includes\_common_funcs.php on line 2061
If I hardcode the full path in one require_once() line, and use a lowercase 'd', then the error in the log will swap the capitalization. This results is 'd:\app ...' and 'D:\app ...'.
If I hardcode both calls that happen to get called when this script runs with the error is not generated no matter what mix of capitalization I use.
And to make this just a little more interesting, the acct_has_graduated() function is the last function in the _common_funcs.php file. But if I disable OpCache in php.ini I get the following error:
Cannot redeclare update_ledger() (previously declared in D:\app_directory\includes\_common_funcs.php:7) in d:\app_directory\includes\_common_funcs.php on line 42
Two things of note: update_ledger() is the first function in the _common_funcs.php file, and "line 42" is the closing bracket of the update_ledger() function (line 7 is the declaration).
If anyone can point me in the right direction on this I would greatly appreciate it.
Solution
I found the issue and the file is absolutely being included twice. This happens under a specific set of circumstances. It affects PHP 7.0 but does not affect PHP 5.3. I did not test any other versions of PHP.
This scenario is certainly an outlier, but here it is:
I have a directory symlink from c:\inetpub\wwwroot\app_location to d:\app_location.
The IIS configuration for this site points to c:\inetpub\wwwroot\app_location.
The application's configuration file defines the include_path using c:\inetpub\wwwroot\app_location as the base.
All the files for this site are located in d:\app_location.
Using the configuration above all entries in the application's log files (tracking, audit, error and backtrace) show D:\app_location as the base location of all files.
Calling require_once() on a file more than once, while allowing the include_path to resolve the location of the file in one or both of the calls, generates the 'Cannot redeclare' error. The error reports the opposite capitalization of the 'D:' drive letter (see error text in the post above).
Changing the base of the include_path (#3 above) to d:\app_location resolved this issue.
The question is very simple.
require_once('D:\file.php');
require_once('file.php');
will run twice, because you included the absolute path!
Solution
Use relative path
require_once('../core/file.php');
I migrated to godaddy for a perma-host. Now much of my code is not working.
For years I have used the following code in my gaming site. but now I want to move it to a more permanent host. I've been using php v5 with no issues, never had a reason to change. However I did finally migrate to PDO. With that said, here is the .ini file I use:(keep in mind, it is a giagantic ini file, but the following are what is important that is NOT working..
SQL_TYPE=mysql
HOST=localhost
USER=incognito
PASS=topsecret
DATABASE=mycooldb
to pull it for defines:
$defines = parse_ini_file('defines.ini');
foreach($defines as $field=>$data)
define($field, $data);
Now there is an error when I use godaddy (which i believe is up to v7 php).
If I run
die('host = '.HOST) // gives HOST
On my local server
die('host = '.HOST) // gives localhost - as it should
Why is this happening? I supposed I could line by line the defines, but they have worked for years the way I have it.
Thanks for any input.
Since it appears I have 2 problems, I will answer what addresses my first issue for this topic and close it:
There was not a problem with the DEFINES, but instead, my .ini files that stored the information for the variables that create the DEFINES.
In this ini file, I originally had "#" for comments as was accepted at the time, (which was what I was used to see: https://en.wikipedia.org/wiki/INI_file#Format)
However, not catching some of the "depreciation errors" I got over the years from PHP v5.3 - as I was stubborn changing - "#" was among those warnings. When PHP 7 finally came, the "#" no longer worked as comments, and thus my DEFINES variable ceased to work, as the script was stuck at the first commented line.
Conclusion: As far as my error, there is NO difference in the defines between PHP: v7 and v5, however the use of "#" as comments caused the error.
Thank you #Magnus Eriksson and #Calimero for the tip to display errors to catch it.
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.