I loaded up Laravel/Lumen on the new Homestead php7 box and encountered this error:
FatalThrowableError in MemcachedConnector.php line 51:
Fatal error: Class 'Memcached' not found
Doing a phpinfo(); shows there is no memcached extension, but sudo service memcached status says memcached is running. It seems there is a php7 branch for memcached here: https://github.com/php-memcached-dev/php-memcached/tree/php7
Can anyone guide me on how to get it working in the new php7 Homestead VM?
EDIT: I just saw on the homestead install documentation that it says "Memcached (PHP 5.x Only)". Question still remains on how to get it working.
The work on php-memcached for PHP7 is not yet complete, not all tests pass; You can use everything but JSON serialization, I think.
There is no pecl support for PHP7, so right now you need to install extensions manually, like this:
git clone https://github.com/php-memcached-dev/php-memcached
cd php-memcached
git checkout php7
phpize
./configure
make
sudo make install
You must make sure that phpize is the PHP7 version. Additionally, if the php in your PATH is not PHP7, then the php-config in your PATH is not either, in this case you must pass --with-php-config=/absolute/path/to/php7-config to ./configure.
I have the same problem, but on Windows when using XAMPP. It seems memcached works for now with PHP 5+ only.
The problem for Windows users is to find the right .dll file named
php_memcache.dll (x86/x64 platforms).
I've spent hours looking for a solution, but nothing found. The very fresh description how to use memcached is here:
HOW TO: Install Memcache on XAMPP (Windows 7/8/10)
We still have to wait for PHP7+ implementation.
Related
Using Laravel with DDEV/Docker on a Mac, I am stuck getting PhpStorm to run directly PHPUnit with coverage. I am following these instructions: https://ddev.readthedocs.io/en/stable/users/topics/phpstorm/
I started the setup with
curl -s "https://laravel.build/myproject?with=mysql,redis,memcached" | bash
Everything's is working fine, including debugging with Xdebug after I turned on Xdebug with
ddev xdebug on
PHPUnit works fine via console as well:
ddev exec phpunit
Composer version is 2.1.4.
Following the instructions named above, I am stuck at point 6.
What am I missing out? PHPUnit is located within the directory and it is composer-installed as well:
With composer version 2.2 the phpunit executable in vendor/bin is not a symlink anymore. It‘s a PHP file which includes the original executable with help of stream-wrapper, but including phpunit is not allowed: https://github.com/sebastianbergmann/phpunit/issues/4096#issuecomment-585900398
The bug is solved in composer:
https://github.com/composer/composer/issues/10387#issuecomment-1000246631
Use the following to get the latest dev version until this fix was official released:
composer self-update --snapshot
Further you can configure PhpStorm to use the original file instead:
vendor/phpunit/phpunit/phpunit
Thanks to all of you guys, I really appreciate your help.
Here is how I solved it:
I installed ddev-edge to avoid composer 2.1.x. I could not change it to 2.2 in config.yaml without failing ddev to restart when using stable version of ddev. It only worked on an active docker instance.
Then configurated ddev to use latest PHP-version 8.1 (for a new project from scratch, it makes sense anyway).
Then the error with PHPUnit changed to an error telling me that the PHP version is too old for the PHPUnit version. That was because PHPStorm automatically picked PHP 7.4 as default when connecting to Docker and checking the CLI remote interpreter.
So I changed the PHP executable from "php" to "php8.1"
See screenshots.
Now running PHPUnit from PHPStorm works fine, even with coverage.
My client is running Laravel 5.2 and PHP version 5.6 (all obviously several years old).
I tried to clone the git into Valet with relative success in that the application ran but a bunch of pages threw errors which I am certain is due to me running the latest version of PHP.
So, my question is it better to directly clone the project on Homestead?
Does Homestead offer a more "native environment" for a situation like I am in?
you should try to use an environment that is the closest possible to production.
If your customer uses apache, try xampp. Else adapt to his environment and PHP version, so you can concentrate on code production instead of keep the solution working on more than one environment.
One year later, I came across with the exact same problem; php 5.6.31 and Laravel 5.2.
I managed to simulate the environment with homestead 6, following these steps:
copy the project files to a new folder
Unzip php 5.6 to my local pc (remove php7)
run: composer update (must run with php 5.6 on local pc)
run: composer require laravel/homestead:~6.6.0
run: vendor\\bin\\homestead make
edit Homestead.yml as needed (.ssh path, add php: "5.6" one line below the site sync)
run: vagrant up
run: vagrant ssh
make appropriate changes (google them) according to problems faced on homestead.test (edit xdebug for 502 BAD GATEWAY, edit my.cnf for adding utf8, etc)
I am trying to get an old Laravel 4.1.x app up and running again so that it can be modernized. This requires an environment with PHP 5.6 and the Mcrypt extension. I have installed Homestead 9.0.3 (the latest stable version). Within the VM, I have set the PHP version to 5.6
sudo update-alternatives --config php
I have then installed the php-mcrypt extension
sudo apt-get install php5.6-mcrypt
I am now able to create a new Laravel 4.1.x project, which is a process that requires Mcrypt to complete, so we're certainly getting somewhere:
composer create-project laravel/laravel="4.1.*" myAppName
However, when I browse to the webpage for myAppName, I see the message:
Mcrypt PHP extension required.
I have also tried steps that are usually recommended for this problem, ie:
sudo ln -s /etc/php/5.6/conf.d/mcrypt.ini /etc/php/5.6/mods-available/mcrypt.ini
sudo phpenmod mcrypt
sudo service php5.6-fpm restart
But I still get the same message in the browser.
What step have I missed?
With homestead v9 you should be up and running with php5.6 out of the box as stated in
here, but unfortunately it is not your case, and I understand that...
Old packages were not installed by default (php5.6-mcrypt), as you mentioned and they should be added by hand via:
sudo apt-get install php5.6-mcrypt
After that all packages are ready, up and working, especially php5.6-mcrypt.
The root of your problem is in multiple site definitions under your homestead.yaml.
Most probably some of them are overlapping and your nginx is referring to the wrong resource/site_definition, and wrong paths.
Therefore you might think some strange php versions or routes are run/executed.
You can verify that, by deleting some/all of them, leaving the only one important for you - in (/etc/nginx/sites-enabled/...).
Of course please do that inside the container and issue sudo service nginx restart, afterwards...
All of your problems should be gone after that.
If something goes wrong. You could easily recover your current installation to current state using vagrant destroy and vagrant up afterwards, cause all is saved in Homestead.yaml.
In my installation Homestead v9 is running with php5.6 on laravel 4.1 without any problems...
Hope it helps #jsm...
Because all the PHP versions installed on homestead you need to set the PHP version for a site in the Homestead.yaml.
First check what version the server is running with phpinfo();
Check the file /etc/nginx/sites-enabled/homestead.test and look for this line:
fastcgi_pass unix:/var/run/php/php5.6-fpm.sock;
If you didn't set the php version on the sites list, this file will be pointing to the php7.3.sock.
In this case the version 5.6 has mcrypt installed, but 7.3 don't.
You can just replace the line
fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
for
fastcgi_pass unix:/var/run/php/php5.6-fpm.sock;
and then reload nginx with sudo nginx -s reload.
Or set the php version on Homestead.yaml:
sites:
- map: homestead.test
to: /home/vagrant/code/public
php: "5.6"
And then run vagrant provision, it will change the nginx configuration for PHP 5.6.
Short version
I'm getting this error, when I run php artisan serve and visit my home page:
ReflectionException (-1)
Class setEventDispatcher does not exist
Details
Laravel version: 5.6.39
Environment: local
OS: macOS Mojave 10.14.2
It started, when I got an error using npm (in another project), so I reinstalled Node (this way).
After doing that, then this project (in question) couldn't be started. I was getting this error, when running php artisan serve:
dyld: Library not loaded: /usr/local/lib/libpng16.16.dylib with anything php related
Referenced from: /usr/local/bin/php
Reason: image not found
That error was resolved by updating and upgrading brew.
Then I was capable of starting the project (php artisan serve). But when I visit the home page, this error was shown:
ReflectionException (-1)
Class setEventDispatcher does not exist
If I follow the stack trace, then I can see that it was this line (from my homeController) that triggered the error:
if( ! Auth::check() ){
return view( 'pages.home' );
}
If I commented that out, then the same error occured from another place, where the Auth-module was being used.
Here's the stack trace:
Does anyone know how to resolve this? I can't find any promising results on Google, - and I have no idea why this happens... :-/
Addition1
I tried composer clear-cache and deleting the vendor-folder, and then doing a composer install and the problem still occured.
I also checked my Service Providers, as Marcus suggested, - but I don't really know what to look for in there. It all looks pretty regular (no fancy if-statements or anything).
Addition2
I realized, that I couldn't connect to my database using Sequel Pro. And it was because Brew had updated my MySQL-version from 5.5 to 8.0.
That was resolved by doing something along these lines (I did a bunch of stuff, so I might be missing a coulple of steps):
brew unlink mysql
brew install mysql#5.7
brew switch mysql 5.7.21
brew link mysql
and I could then verify the version with mysql --version. I also had some permission issues with that MySQL-version-change, but I'm emitting that, so this doesn't get too long.
Addition3
I tried disabling the Laravel Debugbar (by deleting it from composer.json, deleting composer.lock and vendor and then running composer install). And that fixed it!! ... But!
When I later tried to install Barryvdh's IDE Helper, then the exact same error came back!?
I performed these three steps, to install the IDE Helper (and re-introduce the error):
Run this command from the root of my directory: curl https://gist.githubusercontent.com/barryvdh/5227822/raw/4be028a27c4ec782965bb8f2fdcb4c08c71a441d/_ide_helper.php -o _ide_helper.php
Add these lines to app/Provider/AppServiceProvider.php:
...
if ($this->app->environment() !== 'production') {
$this->app->register(\Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class);
}
Run this command: composer require --dev barryvdh/laravel-ide-helper
So I'm back at this error:
ReflectionException (-1)
Class setEventDispatcher does not exist
... The stack trace is identical to the one shown previously (sprung from Container.php).
Tried every solution, none of them worked.
Finally, i realised that when trying to upgrade php to 7.3.3 it was infact a network error that caused the fail. Read the logs, tried again, restarted valet and tried again.
It works now.
Upgrading to 7.3.3 was the solution indeed.
Thank you!
So this is what usually fixes it for me
Reinstall composer dependencies by removing vendor folder and composer.lock. Then run composer clear-cache and then composer install (this is usually the problem)
Check that all service providers are imported correctly in app.php under directory config
Make sure that your service providers are not importing something that does not exist, for example if you register a service provider in production but is only installed as dev:
if (env('APP_DEBUG')) {
$app->register(Barryvdh\Debugbar\LumenServiceProvider::class);
}
If you use valet, I solved it running
valet restart and all works fine.
cheers!
The fix for me was to update PHP to 7.3.3 and then restart valet. Apparently this was a bug with php 7.3
https://github.com/laravel/framework/issues/27052
Hope this helps
I got some idea... I've just run into this problem after reconfiguring my apache virtual host ports, so I restarted apache/httpd again, and the problem went away. Might it be related with the server environment?
I am facing the same issue in mac book pro. My system configuration is PHP 7.3, MySQl and I use SQL Pro. I have implemented all the above methods but nothing gets worked.
The issue is still a mystery for me but for temporary I have solved this issue using
artisan command as bellow.
php artisan serve
Its Allow me to run the project on http://localhost:8000
Hope this can help to solve this issue.
Try to restart PHP. When I reboot my Mac, then this happens. After restarting PHP everything starts to work.
sudo brew services restart nginx
I've been following this tutorial to try to install the PHP MongoDB extension but unfortunately haven't been able to get it working.
http://www.marcwitteveen.com/tech/mac/installing-mongodb-on-a-mac-so-you-can-access-it-with-php/
I can access the collections in the terminal, the database is properly installed but I didn't manage to get the extension working.
I have the following problem:
Sinan-MBP:mongo-php-driver-master Sinan$ cd
Sinan-MBP:~ Sinan$ sudo pecl install mongo
pecl/mongo is already installed and is the same as the released version 1.4.1
install failed
I've been trying several times so that's probably why I get this message. However, even after adding "extension=mongo.so" to the php.ini, I can't use MongoDB in my PHP code.
Thank you for your help.
This is likely a case of modifying the wrong php.ini for the environment, or PHP not being able to find the mongo.so in its directory. If you have separate php.ini files for CLI and web environments, PECL might have installed the compiled extension to a different directory.
If you run through the installation docs, there are instructions for grepping extension_dir from php -i and ensuring that mongo.so is present in that directory. If your web environment has a separate php.ini file, then grepping output from php -i likely won't help. You may need to view phpinfo(); output through your web server and check for the extension directory there.
One additional test that PECL installation succeeded would be attempting to view reflection information for one of the driver classes from the CLI environment. You can do so with php --rc MongoClient, which should print info on the methods of the MongoClient class.
I don't know why it was not working but I found a workaround late last night.
I uninstalled the php extension and then installed it again and made sure the extension was loaded in the php.ini
sudo pecl uninstall mongo
sudo pecl install mongo