Top 50

@NEXXAI - Are you running those tests from the command line?
Take a look at this line in your error: "/Users/nexxai/.composer/vendor/phpunit/phpunit/phpunit:61" . It is using the phpunit globally installed in your machine for your user and not the one used by the app installation in vendor/bin/phpunit.
The configuration I showed you above is all you need to run tests in memory. Thus, make sure both your application configurations and your local machine (PHP, composer, etc) are correctly set. Also, if you are running these tests from an IDE, you need to configure it there as well to point the phpunit.xml and the composer autoload correctly.
Another thing I noticed is that your composer installation is not using the standard folder for Windows. Make sure your composer variables are correctly set for your system.

That is more than enough. You can also use the RefreshDatabase trait to avoid database persistent changes. If you are just starting a new project, undo your configuration and start again to avoid misconfigurations.

As I said, you need to set up your webserver properly to manage it. If you are using a shared hosting service and you don't have access to the webserver directives, contact the support. They need to hide your root folder, only expose your /public folder publicly and properly configure mod_rewrite, alias, etc. So, you will be able to use the http://MYSITE_REPLACED.info/back/ to access your application and the test should work by following http://MYSITE_REPLACED.info/back/api/vote, excluding the /public path. If you are unsure, do php artisan route:list to check your routes and API endpoints.

I do not recommend doing this only by changing your .htaccess. Both your main website .conf (if you are using Apache) and the .conf of the application in question need to be customized. Also, be aware that folders permissions and ownership need to be adapted to this situation.

@THREEEL - I thought this was Laravel 0.1...
Make sure there is no mistakes in the model and/or policies imports namespaces.
Double check if your getEndpoint method is returning the correct path.
Another point: your test says the "lectures" are open. So, you do not need a policy for the index. Do you?
Also, take a look if other authentications, routes with the can key in the middleware method, gates or policies are not interfering in the process.

Also, try to change the protected $policies array. Instead of using the scope resolution operator to designate the class, like ::class, use the full autoload path, for example, 'App\Model' => 'App\Policies\ModelPolicy'.

Make sure your test method does not require authentication. If so, you need to authenticate first.

This will return a response to your front-end with "url" and "success". You actually don't need to store the path in the database, since it will be stored in the body as a img tag that includes the src attribute.

I believe your controller is doing too much. I suggest you redesign your app a little bit. For example, since each user can have a single NewsProvider, you can create a Model where you can define the relationship and also set the default news channel. As you described, it looks like a simple one-to-many relationship. Then, in the front-end, you just need to fetch the "choice" made by the user.

To avoid the repetition on your "providers", you can apply the very basics principle of design patterns by separating what changes from what stays the same. To make it easier for you, you can put it in an interface or simply create a trait.

The test suite will not understand that it needs to follow this long path ( http://MYSITE_REPLACED.info/back/public/ ) to hit the API endpoints. You need to correctly define your root directory and your application directory on your web server. Then, set the application variables in the correct way.

I hope you installed Composer via the official ".exe" installer as @jlrdw suggested. But besides that, you also need to include the vendors/bin folder in your user path variable if you want to run the packages .bat from PowerShell or CMD with ease.

Go to system properties -> Advanced -> Environment Variables. In the variables for you user, append to the "path" variable something like %USERPROFILE%\AppData\Roaming\Composer\vendor\bin

@UNTYMAGE - If you are working on projects that require Vagrant, run a single PHPUnit method at a time. Only run the entire suite to check if everything is okay.

Nowadays, I tend to simplify my environment as much as possible. I just use a simple and local PHP installation together with a MySQL server. I also recommend running tests on memory. Thus, when you run your tests, you never touch the MySQL service. For projects that require Unix tools, like Redis, I use it from WSL using the default ports.

If you need to make sure your app is compatible with your deployment machine, you can do that by creating a custom VM on Hyper-V (or VirtualBox) that matches your remote machine. In that case, you have an option to access your files via SSH or Samba. Even better, you can use some tools provide by big IDEs like PHPstorm to access it the same way we did in the old days by uploading via SFTP on save. Set git hooks to upload the files to the VM are also options.

I would stay with the local option. I have a long background in using Linux distributions, but I am very satisfied with Windows nowadays and, in some scenarios, it can be much faster than Linux.

Are you sharing folders between the Vagrant box and Windows?
This slowness is the case when you are sharing folders between different filesystems. There are some things you can do to optimize it, but it will never be as faster than running it on the same filesystem.
The docs for Homestead says the following:

When using NFS on Windows, you should consider installing the vagrant-winnfsd plug-in. This plug-in will maintain the correct user / group permissions for files and directories within the Homestead box.

So check the plugins available for Vagrant. It will help a little.
If speed is important to you, install PHP directly on Windows to run it locally or put your projects inside the VM and access it remotely or via SSH or Samba share. Microsoft is customizing its own Linux kernel to be used on WSL2; so it will be an option for the future.
For now, a local Windows installation or a customized VM on Hyper-V is the best options.
Let me know if it helps.

For example, there is a package in Debian based distributions called php-imagick. When you install this package on Ubuntu, the system will automatically change your PHP configuration for you. You just need to reload your servers.

In case you have limited access to the server, things start to get complicated and you need to request support as @devfrey suggested. Other companies give you access to a "user-based" php.ini. So you need to check if it is available.

Is the problem solved? Where the script is located exactly? Check the file ownership with stat -c "%U %G" *.py to see if there is something strange.

One important thing is that the shell runs based on your .profile/.bashrc settings, your application does not, even when the user is the same in this case. It also means that your "PATH" is not accessible from the application when you run a script directly from the app. What you can do in this case is to run a subprocess from your user. But it is not a good practice since you are inside a web server.

Another point is that os.environ["PATH"] works differently in Windows. Thus, make sure your text editor is not kidding you. Check for proper imports and quotes.

First, I would suggest you check your app rights to execute that script and access the directory where the script is in. For example, PHP runs as a www-data group if it is under Apache, etc. Also, make sure the script is executable by applying chmod +x *.py.

You can use a shebang like #!/usr/bin/env python on the first line of your python script to specify your python environment. But #!/usr/local/bin/python2.7 would help you to specify the exact version you want to run.

@IVANMIRANDA - I believe that Dusk will not understand that it should follow this "http://localhost/public/" to access the application. If you are using Apache locally, you need to point the DocumentRootto the public folder of your app. Also check the AllowOverride directive and the mod_rewrite module are properly set.

You have mentioned that your app runs on http://localhost/etc. So, you APP_URL variable need to reflect that and not only http://localhost.
What OS are you using? Is the app running fine? Is the problem only occurring while testing with Dusk?

Here are some steps you can follow:

If you're accessing the server with the root user, stop doing that. Create a new user, grant it sudo/admin access and add it to the www-data group.

Before SSH into the server with this new user, make sure both SSH server and Iptables are properly set.

As I don't know how your application was deployed and what it was designed for, I will give you a general approach to set the ownership of the projects folder. In general, apps are under the /var/www on Debian based distributions. I hope your project is there. Otherwise, it can be under your $HOME folder. If your user is properly configured and secured, you can use sudo chown -R $USER:$USER /var/www to set the ownership. Then, go to your project root folder and do sudo chown -R :www-data storage bootstrap/cache.

Use sudo chmod -R 775 storage bootstrap/cache to set the permissions recursively for storage and bootstrap/cache.

In general, that is it.

####Suggestions:

You also need to make sure the Apache DocumentRoot is pointing to the /public folder and the proper directives are set for the project directory. Otherwise, your configuration and environment files will be exposed and Apache will not be able to correctly follow the routes.

Do you only have access to your server via panel?
It sounds like a permission problem. Make sure you have properly set the ownership and the permissions of your application folders and files. Also check the Apache directives and indexes.

@EMFPC - Note that Laravel already comes with the header pre-configured for Axios. Visite your r `resources/js/bootstrap file. You will see the following:

/**
* We'll load the axios HTTP library which allows us to easily issue requests
* to our Laravel back-end. This library automatically handles sending the
* CSRF token as a header based on the value of the "XSRF" token cookie.
*/
window.axios = require('axios');
window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
/**
* Next we will register the CSRF Token as a common header with Axios so that
* all outgoing HTTP requests automatically have it attached. This is just
* a simple convenience so we don't have to attach every token manually.
*/
let token = document.head.querySelector('meta[name="csrf-token"]');
if (token) {
window.axios.defaults.headers.common['X-CSRF-TOKEN'] = token.content;
} else {
console.error('CSRF token not found: https://laravel.com/docs/csrf#csrf-x-csrf-token');
}

@EMFPC - I suggest you talk to the front-end developer to have a clear idea of the project architecture before implementing the API.

For example, if he or she will use Axios to communicate with the controller, I would suggest you set Laravel Passport because it will help you set the cookies for the API authentication with easy. In other words, it is easier than you probably think. ﻿