Each time I try to use the hash() function, it gives me a fatal error for undefined function hash().
First thing I do is check phpinfo() and see if hash is actually present. Phpinfo() does tell me hash() is available. Doesn't mean it's loaded, so when I check my ini file, the pgsql PDO is commented out yet the PDO is working just fine (I guess the generic PDO is always loaded by default). There is also no entry for hash and I wouldn't know the extension name anyways. But, it should have been installed.
Using PHP 7.0.1 on Mac OS X.11 and I used this website http://php-osx.liip.ch as phpbrew just doesn't want to work right for me.
UPDATE -
I decided to go look inside the directory structure where php is installed and noticed that other extensions have their own INI files in the php.d directory. How does one know if the hash extension requires it's own INI file? Or is this just an easier way to enable extensions without having to tinker with INI production and development configurations?
I figured out the problem. While my page dumps out phpinfo() saying version 7.0.2 with all the needed extensions, my CLI version is still liked to 5.6.16 and missing extensions.
As they say, an assumption is the mother of any screw-up. I assumed the installer for 7.0.2 would rename the Apple provided one and/or link to the newer binary.
Related
this is not a bug in my program but a general doubt. I've heard and read that in Windows people uncomment extension names in PHP.ini to enable them. Does this works in Ubuntu too?
Actually I've tried it in my Ubuntu and it didn't work, just want to be sure it doesn't works like this in Ubuntu or it was my fault somewhere (which doesn't matters now ).
In my case I didn't even touched the ini file but just recompiled the php from source with passing extension arguments. Why didn't I have to enable them?
Tried searching SO but didn't find any questions related to this.
With Windows, pretty much all the extensions are already compiled as DLLs. So when you uncomment the line in the ini file and restart the service, it simply loads the file.
When you compile from source in Linux, you aren't building all the extensions by default. You usually have to explicitly specify which extensions you want to enable and they are compiled along with PHP. So the extension has to be compiled successfully and be accessible to be used. The ini file is simply the instruction of whether or not to TRY loading that extension when PHP starts.
Also, there are some basic extensions that are part of the typical PHP build / configure / make process. You can consult the docs to figure out which ones are default but a good practice is to explicitly enable those that you want.
Don't build EVERY extension if you don't need them though. The more extensions that get loaded, the more memory that PHP needs/uses when starting up.
the simple answer is yes it works but if only the extension is in your ubuntu.
I have a class that makes use of the php_printer extension but I can't find it anywhere and at php.net it says it's currently unavailable. I googled it, but all I downloaded from other sites was not efficient. It seemed to me it was outdated. I copied the .dll file in the extensions folder and set the configuration in php.ini but I still couldn't use its built-in functions.I have PHP 5.3.1 installed.
Then you did not google very well. There still are repositories of precompiled binaries elsewhere:
https://github.com/maryo/php-5.5-windows-extensions
http://windows.php.net/downloads/pecl/snaps/printer/0.1.0-dev/
http://downloads.php.net/pierre/
Just saying it does not work is insufficient. I understand that compiling from source is effortful on Windows (pecl install printer given a proper compiler setup), but at the very least run the PHP interpreter on the commandline after editing the php.ini. It would give you a useful error message in case of linking errors, or none in case you edited the wrong config file. (Too few details to answer.)
See also: PHP 5.4.7 Compiling ext php_printer
download and unzip the extenssions file
http://museum.php.net/php5/pecl-5.2.6-nts-Win32.zip
http://downloads.php.net/pierre/ appears to have one that dates to 2010.
I'd consider looking for some other solution though, it doesn't look like a very widely supported extension and it's not been updated for at least a year.
I have been developing our php based site on a development box that was set up when i started my new job a few months ago. I have just got a new dev box and am having some real trouble getting my IIS server to work with the site.
I am running windows 7 64bit and IIS7.
I get this error when trying to load the site:
Fatal error: Call to undefined function imagecreatefromgif() in filepath:// line:#
I have done some searching around and found that this particular function is part of the GD library and that i needed to enable it in the php.ini file. most sites were saying that i needed to uncomment this line extension=php_gd2.dll but it wasn't there, so i added it. I took the php_gd2.dll file from the old test box and put it in the folder specified as so
extension_dir ="C:\Program Files (x86)\PHP\v5.2\ext"
I should point out that I am using php5.2 by necessity, we use a library called ezpdf to create pdfs and it contains hundreds of references to magic_quotes_runtime the old dev box was actually running php5.0 but i couldnt find anything earlier than 5.2, and as far as i can tell the magic quotes things should be an issue before php5.3.
Anyway, using the php manager in IIS7, i can see that php_gd2.dll is enabled, however if i look at phpinfo() i can see no reference to GD.
No matter what i try i get the same error, does anyone have any ideas!?
GD isn't JUST the .dll you load into php. there's a fair chunk of other code in other libraries that the php .dll references. You'll need the entire GD setup for it to work in IIS, not just the one php_gd.dll.
References to magic_quotes_runtime by themselves aren't 'bad' - a lot of libraries have to handle running under older PHP versions where magic_quotes is enabled by default, and do appropriate compensation for that fact. If ezpdf is, however, recreated magic_quotes behavior, then it's definitely time to upgrade versions or switching to something better. magic_quotes is deprecated for a reason, and re-enabling it in any way/shape/form is a bad idea.
Now I'm seeking of php_pdo_mysql.dll version 5.2.5.5,
only found this:
http://dllcentral.com/php_pdo_mysql.dll/5.2.5.5/
But my zend studio 5.5 says it's invalid!
Is there any other place I can try my luck?
Brrr, I really wouldn't download binaries (that could do anything they please on the system, and possibly even the web pages that get served) from locations like that.
Isn't PDO included in PHP by default since 5.0?
From the PDO installation manual:
PDO and all the major drivers ship with PHP as shared extensions, and simply need to be activated by editing the php.ini file:
THe pdo extentions come default with php installation as far as I know.
You should try to uncoment the package in your php.ini file and then reload apache.
Looking at this I would have thought that you wouldn't need a DLL at all. From here:
PDO ships with PHP 5.1, and is
available as a PECL extension for PHP
5.0; PDO requires the new OO features in the core of PHP 5, and so will not
run with earlier versions of PHP.
Official binaries can be found at:
http://windows.php.net/download/
However, you say you already have a Windows binary. Look at it carefully: you should already have that DLL available. Probably, you need to rerun the installer and select that extension.
I need to install or use php on a windows 2003 server that already has php 5.2.0.0 installed due (I think) to setting up symantec backup exec. I don't want to interfere with backup exec's php.ini settings - and would rather be able to control my own configuration of php.
searching for php shows that php.exe and other php files are currently installed in
c:\program files\symantec\backup exec\
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
There is no PHPRC entry in the server properties > environment variables and I'm pretty sure that the php.exe location is not included in the PATH variable. ...unless the actuall install location is different from the c:\program files\symantec\backup exec\ dir.
Any suggestions on how to proceed?
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
What makes you say that :) I've run separate PHP versions on the same machine side by side and not run into bother.
AFAIK the Symantec install should not conflict with your own installation, nor should the separate php.ini files conflict with each other.
[Response to comment]
First thing to note is that I have no experience of Backup Exec or what it uses PHP for. I'm guessing it uses it for its own internal stuff and doesn't spread itself over the OS. Test this by searching for php.ini and php DLLs on the file system. I'm betting it's all quite self contained. PHP searches for the config file as noted here: PHP Site . As you note, BE hasn't set the PHPRC variable. Check it hasn't used those Registry entries either. On a different tack, has BE installed an admin site already on IIS? If so, check the IIS Web Service Extensions to make sure it hasn't already registered the PHP ISAPI dll or PHP CGI exe. IF not, I think you should be okay for your new install.
To be on the safe side, do a manual PHP install as illustrated here: PHP Site. That way, you know exactly what you have installed, and can easily remove the files again if they cause a problem. I can't imagine a problem here that would require you to reinstall BE.