I want to use CURL in my Laravel 5.3 app but it returns error :
Call to undefined function App\Http\Controllers\curl_init()
I created info.php file to test curl contains :
<?php
var_dump(function_exists('curl_version'));
phpinfo();
?>
it returns true and shows that curl is enabled :
but when I test it inside laravel :
dd(function_exists('curl_version'));
it returns false !!
When I run php --ini in terminal it returns :
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/php_curl.dll' - /usr/lib/php/20151012/php_curl.dll: cannot open shared object file: No such file or directory in Unknown on line 0
I tried to use curl_init() in info.php outside laravel and it works!
Why does this happen and how to fix it ?
In your error message PHP tries to resolve the curl_init function within the App\Http\Controllers namespace. If the underlying issue is not related to the PHP Warning you later pasted, the curl functions should work if you prefix them with backslash, like \curl_init.
This way you're telling PHP that the function resides within the top level namespace, not within App\Http\Controllers
I was running Laravel with:
php artisan serve --host 0.0.0.0
but when I changed it to :
php artisan serve --host my_private_IP
it's working now.
Related
After upgrading php from 7.0.14 to 7.0.26 php artisan serve throws this error
Warning: Unknown: failed to open stream: No such file or directory in
Unknown on line 0
Fatal error: Unknown: Failed opening required '/Applications/XAMPP/xamppfiles/htdocs/school-dashboard/public/server.php'
(include_path='.:') in Unknown on line 0
Ok, after hours of pulling my hair out I finally found out what the issue was.
In laravel 4 php artisan serve does this under the hood
<?php
namespace Illuminate\Foundation\Console;
use Illuminate\Console\Command;
use Symfony\Component\Console\Input\InputOption;
class ServeCommand extends Command {
public function fire()
{
$this->checkPhpVersion();
chdir($this->laravel['path.base']);
$host = $this->input->getOption('host');
$port = $this->input->getOption('port');
$public = $this->laravel['path.public'];
$this->info("Laravel development server started on http://{$host}:{$port}");
passthru('"'.PHP_BINARY.'"'." -S {$host}:{$port} -t \"{$public}\" server.php");
}
}
That is essentially this in plain php:
php -S 127.0.0.1:8000 -t public serve.php - see the docs for php built in server for more info.
And this worked well and dandy before php 7.0.26, where the last parameter for the php -S built in server was changed to a flag as well, so you have to call it like this php -S 127.0.0.1:8000 -t public -f serve.php.
If you want to serve it with php artisan serve you will have to override the ServeCommand and change the last line of the fire() method to this:
passthru('"'.PHP_BINARY.'"'." -S {$host}:{$port} -t \"{$public}\" -f server.php");
Or you can change it directly in the ServeCommand, but if you do a composer update or install you will have to do it again.
That's what it happened to me today running a Laravel project. After i have tried all the possible solutions finally i got one that it's work for me . So first of all check that your anti-virus block your server.php and it also deleting it . Then check if you server.php is missing from your project, and I think that is probably yes . Just copy it (server.php) from other project (build also from laravel) but before that just turn off your anti-virus until your next restart and make you sure that you will stop it every time before running. I hope that it helps you.
When i use php in cmd Windows console i got the following error:
C:\wamp64\bin\php\php5.6.25>php
PHP Warning: PHP Startup: Unable to load dynamic library 'c:/wamp/bin/php/php5.6.25/ext/php_bz2.dll' - No se puede encontrar el m¾dulo especificado.
in Unknown on line 0
[...]
And continues whit ALL the dll libraries. I Chek the rute and its ok. And when my wamp start a page whit php i dont get this error
For example i got the error when i type:
cd C:\wamp64\www\ServicioApp\scripts
php script_notificaciones.php
I run php --ini and search in the file, and i got:
extension_dir ="c:/wamp/bin/php/php5.6.25/ext/"
My guess is that WAMP (its Apache config) looks for php.ini in different location than command line invoked script - run php --ini in console to find it. You will need to check and fix (or disable) extension paths there.
Search for line with extension_dir - it should point to ext folder with extensions (dlls). You may need to switch to backslashes there:
extension_dir = "c:\wamp\bin\php\php5.6.25\ext"
I found the problem my rute was:
c:/wamp/bin/php/php5.6.25/ext/
And must be:
c:/wamp64/bin/php/php5.6.25/ext/
I miss the 64*
I have a webapp running on Azure App Service. I am trying to test a Post deployment script in Kudu Debug CMD console.
php -d extension=php_redis.dll -f postdeploy.php
Here is my postdeploy.php file
<?php
ini_set('error_reporting', -1);
ini_set("display_errors", 1);
function exception_handler($exception) {
echo "Uncaught exception: " , $exception->getMessage(), "\n";
}
set_exception_handler('exception_handler');
$redis = new Redis();
...
?>
I get the following error
Fatal error: Class 'Redis' not found in D:\home\site\deployments\tools\PostDeploymentActions\postdeploy.php on line 13
PHP Warning: PHP Startup: Unable to load dynamic library 'D:\Program Files (x86)\PHP\v5.6\ext\php_redis.dll' - The specified module could not be found.
in Unknown on line 0
I uploaded the proper version of php_redis.dll to the PostDeploymentActions folder. This is the same binary that the webapp is using via the app setting in portal PHP_EXTENSIONS = bin\php_redis.dll. However, I am not sure how to load this for this script.
Is there a way that I can load the php_redis.dll in Kudu post deployment script?
I tried php -d extension=./php_redis.dll -f postdeploy.php, php -d extension=%~dp0php_redis.dll -f postdeploy.php and other weird combinations with no luck.
Please try to add the PHP extension via ini settings, refer to https://azure.microsoft.com/en-us/documentation/articles/web-sites-php-configure/#how-to-enable-extensions-in-the-default-php-runtime at the Configure via ini settings section.
Generally:
Add an App Setting to your Web App with the key PHP_INI_SCAN_DIR and value d:\home\site\ini
Create an configuration file in d:\home\site\ini called extensions.ini
Add configuration settings to the extensions.ini file using the same
syntax you would use in a php.ini file. For example: extension =
php_redis.dll.
Restart Web Apps service.
Via this approach, you can configure the PHP extension into Kudu console site's PHP runtime. And configure via the App Settings will only configure the extension into IIS.
Any further concern, please feel free to let me know.
We have an intranet site that has multiple PHP scripts which start using curl_init(). The other day there was an update for ArchLinux which messed with some of the dependencies of cURL (glibc). This caused the curl module to not properly load in PHP, that is, extension_loaded('curl') fails.
I get this error from Apache /var/http/error_log:
PHP Warning: PHP Startup: Unable to load dynamic library
'/usr/lib/php/modules/curl.so' - /lib/libc.so.6: version `GLIBC_2.16'
not found (required by /usr/lib/libcurl.so.4) in Unknown on line 0
The weird thing is we have another nearly identical script (on the same machine) that runs on PHP command line using curl_init() that runs via a cron job and PHP loads cURL properly during the execution of this script. That works perfectly fine.
cURL is configured to run in php.ini via extension=curl.so
If I check phpinfo(), I see '--with-curl=shared'. However it does not show the cURL info table. This tells me that the module isn't loading properly.
The curl.so file is in place at: /usr/lib/php/modules/curl.so
These cURL scripts also normally function properly, they are currently working great on another test machine.
This issue occurs on PHP 5.4.5
ldd /usr/lib/libcurl.so.4
linux-gate.so.1 (0xb7770000)
libssh2.so.1 => /lib/libssh2.so.1 (0xb76de000)
librt.so.1 => /lib/librt.so.1 (0xb76d5000)
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0xb7673000)
libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0xb74ad000)
libz.so.1 => /lib/libz.so.1 (0xb7495000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb747a000)
libc.so.6 => /lib/libc.so.6 (0xb72d4000)
libdl.so.2 => /lib/libdl.so.2 (0xb72cf000)
/lib/ld-linux.so.2 (0xb7771000)
In my distro, the change they made was that /lib is now a symlink to /usr/lib: http://www.archlinux.org/news/the-lib-directory-becomes-a-symlink/
EDIT
I tried what DaveRandom suggested here...
[root http]# php -r " echo (file_exists('/usr/lib/php/modules/curl.so')) ? 'It exists.' : 'It doesn\'t e.'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: file_exists(): open_basedir restriction in effect. File(/usr/lib/php/modules/curl.so) is not within the allowed path(s): (/srv/http/:/home/:/tmp/:/usr/share/pear/) in Command line code on line 1
Warning: file_exists(): open_basedir restriction in effect. File(/usr/lib/php/modules/curl.so) is not within the allowed path(s): (/srv/http/:/home/:/tmp/:/usr/share/pear/) in Command line code on line 1
It doesn't exist.
It failed because it didn't allow access to that path via the ini, so I reconfigured it and tried again...
[root http]# php -r " echo (file_exists('/usr/lib/php/modules/curl.so')) ? 'It exists.' : 'It doesn\'t exist.'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
It exists.
Freaky thing though is that JSON is actually working...
[root m]# php -r " echo (extension_loaded('json')) ? 'It is loaded' : 'It is not loaded'; "
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/modules/json.so' - /usr/lib/php/modules/json.so: cannot open shared object file: No such file or directory in Unknown on line 0
It is loaded
I guess the question is, what would cause cURL to work on command line, the module file to be there, but fail to load the extension via Apache PHP.
Then on the other hand what would cause JSON to give a warning, but still actually load?
Anybody know what the heck this could be?
Thanks
Alrighty, I found a work around. It's basically just to downgrade from cURL 7.27.0-1 to 7.26.0-1, which kind of sux, but it works:
I think this issue was unique to ArchLinux, but this will fix it (if you're an ArchLinux user like me).
mkdir /tmp/pacman_build
cd /tmp/pacman_build
cp /var/cache/pacman/pkg/curl-7.26.0-1-`uname -m`.pkg.tar.xz .
tar -xJf curl-7.26.0-1-`uname -m`.pkg.tar.xz
LD_PRELOAD=/tmp/pacman_build/usr/lib/libcurl.so pacman -U /var/cache/pacman/pkg/curl-7.26.0-1-`uname -m`.pkg.tar.xz
Please note, this requires you to recently have version 7.26.0-1 of curl in your package manager cache. If this fails, check /var/cache/pacman/pkg for another version of curl. If you don't have one in there, you'll have to find one.
I get this error on my production server (CentOS 5.4 and php 5.3.5) :
Warning: include_once(PharData.php): failed to open stream: No such
file or directory in /var/www/ZendFramework/library/Zend/Loader.php on
line 146
Warning: include_once(): Failed opening 'PharData.php' for inclusion
(include_path='/var/www/fw:/var/www/vmms:/var/www/ZendFw/library:.:/usr/share/pear:/usr/share/php')
in /var/www/ZendFw/library/Zend/Loader.php on line 146
Fatal error: Class 'PharData' not found in
/var/www/vm/app/Backup.php on line 40
And this is the code which fail :
$phar = new PharData($imageBackupFile);
$phar->buildFromDirectory($imageDir);
Logger::info("Image directory backed up to: $imageBackupFile");
This code is working fine on my own computer.
PharData should be included by default in php 5.3+ ...
Thanks for your help!
UPDATE :
I am using the Zend Auto loader feature to load the good php files using this code :
require_once("Zend/Loader/Autoloader.php");
$autoloader = Zend_Loader_Autoloader::getInstance()->setFallbackAutoloader(true);
Zend autoloader is doing the include_once(PharData.php).
Just because Phar is bundled by default in PHP 5.3 doesn't mean that it's necessarily included in your install. When you build PHP with ./configure, you can pass the --disable-phar to disable the Phar extension.
To confirm this, run the following script:
<?php
phpinfo();
?>
One of the first sections to appear will be the Configure Command section. Review this section to see if the --disable-phar switch is present, and if there is a Phar section to the page in general.
If it's not present, you'll need to contact your host to have it enabled. There's a decent chance, however, that they won't do it for you since it could impact other users depending on how their servers are set up. If this is on your own machine, you'll need to either rebuild PHP without that switch, or install Phar manually from PECL (no idea if this would still work in 5.3, but I don't see why it wouldn't).