Any of the other questions are for Ubuntu only.
What I did:
In the php ini I uncommented this line: extension=sqlite3
as well as the one defining the extension_dir as ext
In PATH I added the PHP installation folder, which includes the libsqlite3.dll
"php -m" in a shell still does not show up sqlite3 (or anything similar) and any PHP file using SQLite3 results in the classic: "Fatal error: Uncaught Error: Class "SQLite3" not found in [php file]"
All the tutorials online (the two for windows that google can find) just say it's working after these steps (or even after the first).
TL;DR: You have the php_sqlite3.dll, right?
https://www.php.net/manual/en/sqlite3.installation.php
They state:
The SQLite3 extension is enabled by default.
and (this is the important part):
Windows users must enable php_sqlite3.dll in order to use this extension. This DLL is included with Windows distributions of PHP.
and (you followed that already I guess)
Note: Additional setup on Windows as of PHP 7.4.0
In order for this extension to work, there are DLL files that must be
available to the Windows system PATH. For information on how to do
this, see the FAQ entitled "How do I add my PHP directory to the PATH
on Windows". Although copying DLL files from the PHP folder into the
Windows system directory also works (because the system directory is
by default in the system's PATH), this is not recommended. This
extension requires the following files to be in the PATH:
libsqlite3.dll.
Other idea:
Did you edit the correct php.ini? There might be several. Where is php.ini?
The problem is in how the default windows .ini files are named
By default, the .ini files provided are named "php.ini-production" and "php.ini-development". Since they don't end with ".ini" they are not picked up and any edits ignored.
After renaming one to php.ini (and restarting) it finally worked.
In hindsight completely obvious but it just did not register with me for quite a while
Related
I am using PHP 5.5.25 with Apache 2.4 on Windows 7 x64 and I am unable to activate the cURL module. I have looked around and tried all I could think of. Please assist:
In php.ini, the line extension=php_curl.dll is active and the file php_curl.dll is present in the extensions directory C:\php\ext
In php.ini when I set extension_dir = ext, none of the extensions load. I get several messages when Apache starts, similar to Unable to load dynamic libraryext\php_openssl.dll- The specified module could not be found.
When I use the full path and set extension_dir = C:\php\ext, all the extensions load fine, except for cURL. I get the error: Unable to load dynamic libraryC:\php\ext\php_curl.dll- The specified module could not be found.
I have tried renaming the extension to php_curl.new.dll and adjusting php.ini but I get an error message about the new filename. I have also downloaded a fresh new copy of the DLL from windows.php.net, but that made no difference.
I have checked the file permissions for php_curl.dll (Right-click on the file >> Properties >> Security tab) and they are the same as the permissions for extensions that load successfully
I have copied and pasted libeay32.dll and ssleay32.dll from the PHP bin directory to the System32 and SysWOW64 directories as instructed by a response to this question
I am certain that I am editing the right php.ini since the PHP startup error messages changed when I changed the extension_dir value from ext to C:\php\ext as I explained above.
I have made sure to restart the Apache server between php.ini configuration changes.
If in a PHP script I execute var_dump(file_exists('C:\php\ext\php_curl.dll'));, I get boolean True so PHP can see the file!
What else could explain why the cURL module is not enabled?
I think you'll need libssh2.dll in your PATH too.
Credit goes to #Steven Hilder for pointing me in the right direction.
The problem was that Windows could not see libssh2.dll, another DLL that was in PHP's directory. Copying this file to C:\Windows\SysWOW64 and C:\Windows\System32, along with the other two DLL files from my OP (libeay32.dll and ssleay32.dll) worked.
I am uncomfortable with this solution though because when the time comes to update to a new PHP version I will have a harder time remembering to overwrite these DLLs with the new version.
Therefore, I decided to remove all 3 DLLs from the System32 and SysWOW64 directories. Instead, I just added the PHP bin directory to the Windows' PATH variable, so that the next time the OS is looking for a missing file, it will also look in that directory. This has the added bonus that if a similar problem with another DLL occurs, it will be resolved automatically.
To add the PHP bin to Windows' PATH:
From the Start Menu search bar, search for and select Advanced system settings
Click Environment Variables. Scroll down the list of System variables to select Path and click Edit... to open the current PATH setting
Append ;C:\php or whatever directory has php.exe to the current setting (semi-colon is used to separate paths).
on windows the cURL execution wants SSL certificate. may be because of that others error is showing.
Put the below code before curl_exec(curlHandle) to ignore checking for SSL certificate
//to ignore the SSL certificate in windows
curl_setopt($curlHandle, CURLOPT_SSL_VERIFYPEER,false);
I'm getting a fatal error on my require_once('directory/file.php'), "failed opening required...". I know the required file is in my php includes folder at c:\PHP_Includes\directory\file.php. When I look at phpinfo() I see the correct include_path: ".;c:\PHP_Includes"
But in the command line error it says include_path='.;C:\php\pear;C\Projects\project1\classes'
Any idea why the path seems to be different when running command line script?
The problem is related to the fact that WampServer has a multitude of php ini files. Make sure to keep them all in sync with the correct settings to avoid problems when one is used instead of the other.
Very useful info from http://forum.wampserver.com/read.php?2,72804:
There is actually 3 php.ini files in WampServer
This is how they are used...
C:\Wamp\bin\php\phpX.X.X\php.ini This is only used by wampserver and php cli exe. WampServer's menu is built using php and this is the
config file that is used. It is also used if you are using php through
the command line interface. You generally never need to edit this
file.
C:\Wamp\bin\php\phpX.X.X\phpforapache.ini This is a copy of the php.ini file used for your websites. When this version of php is being
used this file is copied into the apache bin folder. If you change
version of php the apache\bin\php.ini is then emptied and the
phpforapache.ini of the new version of php is loaded into whichever
version of apache is loaded.
C:\Wamp\bin\apache\apacheX.X.X\bin\php.ini This is the actual php.ini that is loaded for your websites. provided that this is the
version of apache being used. This is copied from the relevant active
php folder( phpforapache.ini).
This may seem a little confusing but it is nessecary for WampServer's
ability to change version of apache and php easily. The best thing to
remember is..
If you want to manually edit your php.ini file for websites then
always use the wampserver menu to open it . >> left click the
WampServer icon > php > php.ini
If you want to manually edit your php.ini file for command line then
open php.ini in the current php folder.
I'm having a weird situation here.
I'm trying create a PDO object, like this:
$dbh = new PDO('mysql:host='.$hostname.';dbname='.$dbname,$username, $password);
I have rewriting ON in my .htaccess file. when I try to run the script using a URL that will trigger a rewrite rule, it shows me the following error:
Fatal error: Class 'PDO' not found
I have a exception rewrite rule for a directory where the script is, named PHP, like this:
RewriteRule ^(php)($|/) - [L]
if I run the scripting directly from the directory, it runs normally with no erros.
I don't know why this is happening. any clues?
Thank you
Edit: Ok, I saw I've misinterpreted your question a bit, but I still think there is something wrong about the php.ini path. Could you check the phpinfo() output of both web calls. The basic idea of the answer keeps the same as stated below (replace CLI with the second web call ;))
OLD ANSWER
Assuming, that you have one of the more common linux distributions (ubuntu, debian, suse, etc), you might have two (or more) php.ini files. One that is pulled when using the webserver module (which seems to be an apache) and one that is used for the cli env. php supports up to one php.ini per SAPI.
In newer debian and ubuntu systems php extensions are linked in the same manner as the sites-available/enabled in the apache config.
If you have a self compiled php look for a php-cli.ini at the common location for the php.ini (which is /usr/local/share/php by default). If a php-cli.ini is present it will be used instead of the php.ini for cli commands.
(Manual Reference: http://de2.php.net/manual/en/configuration.file.php)
How to find out:
Get the phpinfo() output for the INFO_GENERAL section from you webserver. To achieve this, create a simple php file in a web-accessible directory (e.g. the DocumentRoot). Remember to delete it after you got the information you need! Please adjust the '/var/www' to something that matches your config.
$> echo '<?php phpinfo(INFO_GENERAL);' > /var/www/info.php
Now go to your browser and open http://your.host.name/info.php and look for the config property "Configuration File (php.ini) Path". Note this somewhere or just leave the page open for later reference.
On your cli this is also quite easy. The example below is a snip from my shell.
mmueller#bsd ~$ php -i | grep ini
Configuration File (php.ini) Path => /usr/local/etc/php/5.5
Loaded Configuration File => /usr/local/etc/php/5.5/php.ini
[... omitted the tail]
Compare the two paths and see if they are different.
To see why this happens, please take a look at the 'Configure Command' section. You mighty find three important configure arguments. Those three influence where php looks for it's configuration.
'--sysconfdir=/usr/local/etc/php/5.5'
'--with-config-file-path=/usr/local/etc/php/5.5'
'--with-config-file-scan-dir=/usr/local/etc/php/5.5/conf.d'
If you want to ensure the same configuration, you can do one of the following things:
Just add extension=pdo_mysql to the webserver version and see if that is enough
Remove the additional CLI config (if present), this will make php use the php.ini for all SAPIs (make a backup of the file before you do that!). Then you need to merge the rules into the php.ini that you need. (In your case there seems to be an extension=pdo_mysql missing)
Check the webserver php.ini for anything that you do not want to have in the cli version, then copy the webserver php.ini over the CLI php.ini (Do a backup first).
Delete the cli or webserver php.ini, symlink the other php.ini to the place of the deleted one. (not the best way, but I've seen that a lot on customer servers).
Solve it.
There was a empty php.ini in the public_html, I deleted it, and it worked.
thank u all
I resolved the problem of loading php_intl.dll library in PHP by copying files as explained in the Athlan's answer:
https://stackoverflow.com/a/16372984/99256
I don't think that copying the files is particularly nice. There should be a directive in Apache to say "load DLL libraries from folder XY". How can I do that?
My setup:
Windows
Apache2
PHP 5.4
Windows uses the PATH to search for shared libraries / DLLs that are loaded without an explicit path (dependencies of explicitly loaded DLLs).
Apache isn't doing anything with these DLLs, so there's no directive relating to them.
I'm trying to make my PHP installation to work with PostgreSQL, so I need php_pgsql.dll
A very dumb question, but where do I get one for my PHP5.3?
I have read here: http://php.net/manual/en/install.windows.extensions.php, but it is said that, yes, you need this dll, but no download link. What am I missing?
dll is not present by default in my installation:
extension is in ext subdirectory, to activate it you have to edit php.ini, set ext dir and uncomment php_pgsql