I uploaded laravel app to shared hosting into a domain folder, and made .htaccess so that it redirects requests to laravel's /public folder.
I now want to execute artisan commands through ssh. I tried just typing php artisan list in laravel's root folder on the shared host, but it gives me this output (it prints it in html, but I just copied the exeption for readability):
ErrorException thrown with message "Undefined index: argv"
Stacktrace:
#3 ErrorException in /home5/petophob/public_html/ees-aleksandarnikolic/vendor/symfony/console/Symfony/Component/Console/Input/ArgvInput.php:57
#2 Illuminate\Exception\Handler:handleError in /home5/petophob/public_html/ees-aleksandarnikolic/vendor/symfony/console/Symfony/Component/Console/Input/ArgvInput.php:57
#1 Symfony\Component\Console\Input\ArgvInput:__construct in /home5/petophob/public_html/ees-aleksandarnikolic/vendor/symfony/console/Symfony/Component/Console/Application.php:114
#0 Symfony\Component\Console\Application:run in /home5/petophob/public_html/ees-aleksandarnikolic/artisan:58
What can I do to make it work? I'm on Bluehost, if that's relevant.
Thanks,
Petar
You can try call it: php-cli artisan list
If it will not be working you should probably contact bluehost support it is about server settings.
if artisan commands are not working inside your server, you can execute the PHP scripts via PHP's command-line interface (CLI). inside a server, the server pilot installs various versions of the PHP version. to determine what version of PHP you are using, you can simply render a php_info() page.
to execute artisan command you can run CLI base commands based on your version. if you use php version 7.3 you can use
php7.3-cli artisan list
php7.3-cli artisan migrate
php7.3-cli artisan db:seed
PHP syntax will be changed based on your current version what you have to do is just change the version of your command phpVERSION-cli example php8.0-cli
Related
Once our Laravel app is deployed to hosting (AWS Elastic Beanstalk) it's impossible to run php artisan from the ssh command prompt. Every time results in the following error:
In Container.php line 879:
Target class [request] does not exist.
In Container.php line 877:
Class "request" does not exist
Even just running php artisan without any parameters results in the same error. Locally everything is fine.
Strangely AWS runs certain bash php artisan commands as part of postdeploy hooks which work fine during deployment (eg. artisan config:cache). They work fine, but even if I disable that bash script and try to run those commands manually via ssh after deploy, I get the same error. Very confusing.
It's as if there's something happening after deployment that's breaking php artisan.
We're running PHP 8.0.18 and Laravel 9.0.1. I've tried composer dump-autoload, but I still get the same error while that's running.
Where would be the right place to start looking for the cause of this error message?
I posted a question about clearing the cache here
the problem was I can't clear cache after editing the .env file. That is still my real problem. (I can't reset the server and I cant use artisan cmds)
But this problem needs to be solved before I can solve that one:
I cannot run artisan commands. I have a shared hosting account where my environment PHP version is 7.14 the PHP artisan CLI is using the default PHP 5.4 so I cannot do: php artisan cache:clear etc
I have tried things like
$exitCode = Artisan::call('config:cache');
And...
$process = new Process('/opt/php71/lib artisan config:cache');
$process->run();
Keep in mind that my application works fine, and PHP version is 7.14 according to PHPINFO.
So how can I either get Laravel to clear its cache another way or get artisan to run using a specific PHP version?
where my environment PHP version is 7.14 the PHP artisan CLI is using the default PHP 5.4
No, artisan will use whatever version your environment is set to run – the shebang looks like this:
#!/usr/bin/env php
And if you're calling it like php artisan ... then the shebang isn't even used. In either case, you should adjust your path so that PHP 7.1 is called when you run php (i.e. the directory containing PHP 7.1 should come before the one containing 5.4) and it will work fine.
I am using laravel 5.6 and have the problem, when I use the command "php artisan vendor:publish" in the console, I get the following error:
[ERROR] Use of undefined constant STDIN - assumed 'STDIN'
Which provider or tag's files would you like to publish?
[0] Publish files from all providers and tags listed below
[1] Provider: Intervention\Image\ImageServiceProviderLaravel5
The problem is, that these messages appear infinite, until I close the console or after a long time it kills the process.
I looked for this issue on google, but only found the problem with stdin and the difference is, that the people who had that problem, didn't call artisan in the command line interface, but directly in a php script.
The same problem appears when I use "php artisan migrate"
I was getting the issue mentioned above while running artisan command to seed the db tables: Artisan::call('db:seed', [...]) while in production.
Adding the --force flag fixed my issue
Artisan::call('db:seed', [
'--force' => true
])
Make sure you use --force flag if you are in production.
I have found a solution for the problem:
I had to add the following line to the artisan file (in the laravel directory).
define('STDIN',fopen("php://stdin","r"));
Now it works.
It's still strange, because normally artisan should work out-of-the-box, without the need to change anything.
Add
if(! defined('STDIN')) define('STDIN', fopen("php://stdin","r"));
to your index.php file. I tried adding this to artisan file but didn't work but placing it in index.php did the trick.
My PHP version is v. 7.4 on Ubuntu 18.04
This problem is caused by application environment.
Change application env to local or add --force parameter after artisan command.
One thing to check is to ensure you are running the correct version of PHP for the version of Laravel.
php -v will show the php version
I was surprised to see that for me, the CLI version of PHP (which is what artisan uses) was really old.
I didn't realize my shared host had many different versions of PHP installed.
I was able to run artisan commands by using the command corresponding to the PHP version I needed to use: php7.1 artisan migrate
I want to test some Laravel applications on my basic shared host.
Currently I just upload my complete application including the vendor files, however this takes quite long.
Since I do not have ssh access to my host I'd like to know whether there's an option to run composer / artisan commands without this.
I found this link: Use Composer without ssh access to server (Second Answer) which describes how to run composer using http://phpshell.sourceforge.net/
However, I can change folders in the console etc. But I cannot run php commands - I always get internal server error.
Check if your shared hosting provider has console feature in their CP which allows to run shell commands. Maybe you'll be able to run commands from there.
As alternative, you could right your own artisan runner and call artisan commands from the code:
Artisan::call('migrate');
To run composer command from PHP code, use shell_exec:
shell_exec('composer update');
Recently I started working with Symfony2. Unfortunately the php app/console commands doesn't work at both my MAMP server as Vagrant server (MAC OSX). I tried to make a bundle with the following command
php app/console generate:bundle --namespace=Vendor/NameBundle
and also tried to fix a problem with
php app/console assets:install web
And both commands returned the following in my terminal:
Could not open input file: app/console
Does someone know how to fix this problem? I AM working at my project directory like: mac/applications/mamp/htdocs/project but it is still not working. I also tried to reinstall a new symfony project but that was not a fix.
I guess my php isn't working at all in my terminal...
So the problem was the version number. Symfony version 3.0 is available now so if you're do not selecting a version number at your project install it will automaticly install version 3.0 instead of 2.7. The new command is:
$ php bin/console generate:bundle --namespace=Vendor/NameBundle
instead of
$ php app/console generate:bundle --namespace=Vendor/NameBundle
Add php to your Path Environment Variable so that you can execute php from the command line
(You may need to restart your computer after step 1) From the command line type: php -version to test whether php has successfully been added to your pathenvironment variable
Depending on the version of Symfony you have, you will need to execute either php app/console or php bin/console where console is a php file inside the app or bin directories in your project root. To check which command to use, look into your project directories, if bin/ directory is present then execute php bin/console as console.php is located in that directory.
From the command line, cd into your project root directory and run the appropriate command as mentioned above. To check whether you are in the correct directory, run the dir command, if all your Symfony project directories: app/, bin/, src/, vendors/ etc. are displayed, then the php app/console (bin/console) ... command should run successfully.
or just create a new 2.8.x symfony project using:
symfony new yourAppName 2.8
instead of:
symfony new yourAppName
(which would create a new 3.x symfony project)
in this way you will be able to use:
php app/console