The Laravel Framework.

This issue was created to get community feedback.

It would be awesome if we could have the query builder return a collection:

$collection = DB::table('posts')->get();

Given that PHP in some situations infamously does not treat ArrayAccess objects as arrays, this would be breaking BC. This will obviously be targeted for the next release of Laravel.

Pros

1. Makes it consistent with Eloquent. You'll find countless questions on StackOverflow asking why some collection method can't be called on a query builder result.
2. It's just much cleaner than this: collect(DB::table('posts')->get()). Laravel prides itself on making all these tiny interactions more enjoyable. This should not be any different.
3. Native PHP arrays are just useless :smile:

Cons

1. It's a breaking change. Some people's tests might fail because they're using array_* or typehinting for an array. If their code can't be updated to use a collection, they'll have to append ->all() to their results.

If people don't have good test coverage, they'll have to search their codebase for ->get( and manually tack on ->all() wherever necessary. Not the end of the world, but definitely a breaking change.

Overall I think this change is well worth it and would love some feedback from the community. If you use the query builder directly, please leave a comment below with your thoughts either way, or if I missed any pros/cons.

Thank you :heart:

This has been floating around for a long time, so let's put this in writing here.

I propose Laravel does one of the 3 following things:

1. Moves totally to symfony's coding style (possibility without yoda comparisons).

2. Moves to PSR-2 with symfony style (PSR-5) docblocks.

~~3. Moves to PSR-2 with allman style braces.~~ Rejected

NB, I vote for number 1. NB, we could still do number 1 without yoda style comparisons if needed.

EDIT:

Reading through the comments, it's 100% certain that we should at least move to full PSR-2, and a lot of people seem to like the idea of moving to symfony in the interest of consistency, but without yoda comparisons. Moving without yoda conditions is the only way at the moment anyway since we currently have no automated way to enforce them.

I use fresh installation of Laravel 5.3. I did the following steps in my Homestead:

laravel new blog php artisan make:auth entered proper database configuration in .env php artisan migrate

That's all I did. Everything wen smoothly but when I submit register form I get: TokenMismatchException in VerifyCsrfToken.php line 67:

I tried to clean cache and cookies, use different browsers and install Laravel again (also via composer). Some people from Laravel's IRC Chat also confirm that bug too.

Hello. When working with Elokuent that it updates column created_at, updated_at both when creating and updating.

When creating this is true, but why update created_at column every time I do something it updated? In this case, it makes use of a useless $tablet->timestamps(); because you can not fix the field of creating records

Say it is a bug or by design?

or tell me how to leave the field after creating created_at intact?

I discovered a bug in PHPUnit (https://github.com/sebastianbergmann/phpunit/issues/1935) while working on a Laravel 5.1 project:

$ composer create-project laravel/laravel --prefer-dist

$ cd laravel

$ ./vendor/bin/phpunit --coverage-html /does-not-exist
PHPUnit 4.8.16 by Sebastian Bergmann and contributors.

.

Time: 429 ms, Memory: 18.75Mb

OK (1 test, 2 assertions)

Generating code coverage report in HTML format ...PHP Fatal error:  Uncaught exception 'Illuminate\Contracts\Container\BindingResolutionException' with message 'Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.' in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:745
Stack trace:
#0 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php(627): Illuminate\Container\Container->build('Illuminate\\Cont...', Array)
#1 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#2 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(154): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#3 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(79): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 [internal function]: Illuminate\Foundation\Bootstrap\Handle in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 745
PHP Fatal error:  Uncaught exception 'Illuminate\Contracts\Container\BindingResolutionException' with message 'Target [Illuminate\Contracts\Debug\ExceptionHandler] is not instantiable.' in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php:745
Stack trace:
#0 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php(627): Illuminate\Container\Container->build('Illuminate\\Cont...', Array)
#1 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Application.php(674): Illuminate\Container\Container->make('Illuminate\\Cont...', Array)
#2 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(154): Illuminate\Foundation\Application->make('Illuminate\\Cont...')
#3 /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Bootstrap/HandleExceptions.php(79): Illuminate\Foundation\Bootstrap\HandleExceptions->getExceptionHandler()
#4 /home/sb/test/laravel/vendor/laravel/framework/src/Illumina in /home/sb/test/laravel/vendor/laravel/framework/src/Illuminate/Container/Container.php on line 745

The reason why I am opening this ticket is because nowhere in the stacktrace do I see PHPUnit and/or PHP_CodeCoverage. The fact that PHPUnit was not handling an exception raised by PHP_CodeCoverage was not apparent at all from looking at the error I got. Maybe the error handler is too eager?

• Laravel Version: 5.4.0
• PHP Version: 7.0.12
• Database Driver & Version: MySQL 5.6.33

Description:

When I create a new 5.4 project and try to migrate the database tables, I get this SQL error :

[Illuminate\Database\QueryException] SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes (SQL: alter table users add unique users_email_unique(email))

I get this error when running php artisan migrate on a fresh install on a Macbook, on my Windows computer I get the same error except it says that the max length is 1000 bytes instead of 767 bytes.

Steps To Reproduce:

• Create a new project (laravel new project, with installer 1.3.3)
• cd into the project
• Fill in the database information in the .env file
• Run php artisan migrate

Eloquent assumes heavily that you are using surrogate keys on your tables (the id field in every table). However in real world usage, particularly older database systems not designed with web frameworks in mind, there are often tables with composite keys. That is, the primary key is over two or more columns. Often, you can't just add autoincremented id's. This is definitely a game stopper for a lot of use-cases, where you are forced to access existing RDBMS (e.g. building a frontend for an existing db). See also this reddit post about this issue.

The schema builder has already support for composite keys, however eloquent doesn't seem to support it yet.

I request the feature to use composite keys in your eloquent models and queries. The default configuration for surrogate keys is fine, just add the option.

This backwards-compatible change removes the word "Facade" in class names and comments in favor of the word "Surrogate." All current tests pass.

The word "Facade" implies the facade pattern, but the implementation is closer to a proxy pattern. The word "Surrogate", on the other hand, implies something closer to the existing behavior (i.e., a static proxy call to a container instance).

The method names (get|set)Facade(Accessor|Application) remain in place. Changing them requires changing the related abstract class (Surrogate, née Facade). Because userland code may be extending the abstract class, that would require the userland code to be changed as well. That is not a backwards-compatible approach. Thus, the method names remain as a historical artifact. Future versions should deprecate and/or rename these methods to remove the word Facade.

Per https://github.com/laravel/framework#contributing: Since this is a rename/replace of an existing behavior, and not a new component, this pull request is against the latest stable release. Please provide specific instructions if another approach is preferable.

Example code:

Schema::create('presentations', function($table)
{
...
    $table->enum('repeat_unit', array('DAY', 'WEEK', 'MONTH', 'YEAR'))->default('DAY');
...
});

Schema::table('presentations', function($table)
{
    $table->renameColumn('created', 'created_at');
});

Result:

[Doctrine\DBAL\DBALException] Unknown database type enum requested, Doctrine\DBAL\Platforms\MySqlPlatform may not support it.

This PR allows gates and policies to allow "guest users" (null) to be passed to them instead of automatically returning false. They can allow this by marking their user type-hint as optional or providing a null default value for the incoming user:

$gate->define('foo', function (?User $user) {
    return true;
});

The same convention can be used for policy methods as well as before and after callbacks.

The whereHas() method for querying a polymorphic relationship doesn't seem to be working.

Here are the relationships:

Transaction.php

public function transactionable()
    {
        return $this->morphTo('transactionable');
    }

Reservation.php

public function transactions()
    {
        return $this->morphMany('Transaction', 'transactionable');
    }

Project.php

public function transactions()
    {
        return $this->morphMany('Transaction', 'transactionable');
    }

And here is what I am trying to do:

return Transaction::whereHas('transactionable', function($q){
        return $q->where('id', '=', '1');
    })->get();

Result:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'transactions.' in 'where clause' (SQL: select * from `transactions` where (select count(*) from `transactions` where `transactions`.`transactionable_id` = `transactions`.`` and `id` = 1) >= 1)

Is this possible?

• Laravel Version: 9.44.0
• PHP Version: 8.1.12
• Database Driver & Version: phpredis (5.3.7 installed by pecl)

Description: configure native redis clustering results in error message

Steps To Reproduce:

Make sure to config database.php like this:

` 'redis' => [

    'client' => env('REDIS_CLIENT', 'phpredis'),

    'options' => [
        'cluster' => env('REDIS_CLUSTER', 'redis'),
    ],

    'clusters' => [
        'default' => [
            'url' => env('REDIS_URL'),
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'username' => env('REDIS_USERNAME'),
            'password' => env('REDIS_PASSWORD'),
            'port' => env('REDIS_PORT', '6379'),
            'database' => env('REDIS_DB', '0'),
        ],

        'cache' => [
            'url' => env('REDIS_URL'),
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'username' => env('REDIS_USERNAME'),
            'password' => env('REDIS_PASSWORD'),
            'port' => env('REDIS_PORT', '6379'),
            'database' => env('REDIS_CACHE_DB', '0'),
        ],
        'session' => [
            'url' => env('REDIS_URL'),
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'username' => env('REDIS_USERNAME'),
            'password' => env('REDIS_PASSWORD'),
            'port' => env('REDIS_PORT', '6379'),
            'database' => env('REDIS_CACHE_DB', '0'),
            'prefix'    => 's:'
        ],

    ],
],`

Env values (only relevant, skipped queue details f.e.):

  - REDIS_HOST=redis-node-5
  - SESSION_DRIVER=redis
  - SESSION_CONNECTION=session

I'm revceiving the following error message when trying to call default laravel mainpage

array_key_exists(): Argument #2 ($array) must be of type array, null given

Same goes for queue worker (on startup), including more readable details:

`root@36f9e34e9915:/var/www/html# php artisan queue:Work

INFO Processing jobs from the [{default}] queue.

[2023-01-09 10:18:34] local.ERROR: array_key_exists(): Argument #2 ($array) must be of type array, null given {"exception":"[object] (TypeError(code: 0): array_key_exists(): Argument #2 ($array) must be of type array, null given at /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php:177) [stacktrace] #0 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php(177): array_key_exists('url', NULL) #1 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php(275): Illuminate\Support\Arr::exists(NULL, 'url') #2 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php(599): Illuminate\Support\Arr::forget(NULL, Array) #3 /var/www/html/vendor/laravel/framework/src/Illuminate/Support/ConfigurationUrlParser.php(36): Illuminate\Support\Arr::pull(NULL, 'url') #4 /var/www/html/vendor/laravel/framework/src/Illuminate/Redis/RedisManager.php(186): Illuminate\Support\ConfigurationUrlParser->parseConfiguration(NULL) #5 /var/www/html/vendor/laravel/framework/src/Illuminate/Redis/RedisManager.php(133): Illuminate\Redis\RedisManager->parseConnectionConfiguration(NULL) #6 [internal function]: Illuminate\Redis\RedisManager->Illuminate\Redis\{closure}(NULL) [...redacted] "}

TypeError

array_key_exists(): Argument #2 ($array) must be of type array, null given

at vendor/laravel/framework/src/Illuminate/Collections/Arr.php:177 173▕ if (is_float($key)) { 174▕ $key = (string) $key; 175▕ } 176▕ ➜ 177▕ return array_key_exists($key, $array); 178▕ } 179▕ 180▕ /** 181▕ * Return the first element in an array passing a given truth test.

  +6 vendor frames 

7 [internal]:0 Illuminate\Redis\RedisManager::Illuminate\Redis{closure}()

  +23 vendor frames 

31 artisan:37 Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))`

Please let me know if more information is required. -Thanks for help and all of the work on laravel.

• Laravel Version: 9.43.0
• PHP Version: 8.1.8
• Database Driver & Version: MySQL 8

Description:

Laravel has the options of withDefault on a relation eg:

public function settlement(): HasOne
    {
        return $this->hasOne(Contact::class)->where('type', ContactTypeEnum::Settlement)->withDefault([
            'type' => ContactTypeEnum::Settlement
        ]);
    }

Would be nice to have the defaults run through when calling for example in a magic helper we currently have:

 protected function processHasOneRelation(HasOne $relation, array $collection,  void
   {

       $relatedRecord = $relation->firstOrNew();

       if( $relatedRecord->exists() === false){
           $defaults = $relation->getResults();
           if($defaults){
               $relatedRecord->fill($defaults->toArray());
           }
       }
       $relatedRecord->fill($collection)->save();
   }

due to the getDefaultFor method being protected, it is not accessible in our helper.

Steps To Reproduce:

This PR adds setVisible and setHidden methods to Eloquent Collections.

We already have the makeVisible and makeHidden methods, but makeVisible is only useful when a property is usually hidden or when the model has a non-empty $visible property, and makeHidden is only useful when you want to be explicit about what is excluded, not what is included.

Example:

I want to return an array of users with just the ID and name, hiding other attributes such as email and any future attributes that may be added.

// This is effectively a no-op because these fields are not typically hidden.
$users->makeVisible(['id', 'name'])->toArray(); ❌
/*
[
    [
        'id' => 1,
        'name' => 'Test User',
        'email' => '[email protected]'
    ]
]
*/

// This only gives us the desired result until a new non-hidden attribute is added to the model.
$users->makeHidden(['email'])->toArray(); 😐️
/*
[
    [
        'id' => 1,
        'name' => 'Test User',
    ]
]
*/

// This allows us to be explicit about the data we want, and it won't leak as new attributes are added to the model.
$users->setVisible(['id', 'name'])->toArray(); ✅
/*
[
    [
        'id' => 1,
        'name' => 'Test User',
    ]
]
*/

This is especially useful when passing collections to Inertia.

That PR allows to customize maintenance exception by implementing public function abort(array $data): void; in PreventRequestsDuringMaintenance.php.

Like this, the exception could mastered by developper and if customized the response could be too (add headers, choose view etc..) without risk to break the complete middleware logic.

My exception implementation to illustrate

<?php

namespace Exceptions;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Log;
use Inertia\Inertia;
use Symfony\Component\HttpKernel\Exception\ServiceUnavailableHttpException as ParentHttpException;

final class ServiceUnavailableHttpException extends ParentHttpException
{
    public function __construct(
        private Request $request,
        array $headers,
        string $message = 'Service Unavailable',
        \Throwable $previous = null
    ) {
        parent::__construct($headers['Retry-After'], $message, $previous, 503, $headers);
    }

    public function report()
    {
        Log::channel('info')->log($this->getMessage(), $this->context());
    }

    public function render()
    {
        $seconds = $this->getHeaders()['Retry-After'];

        return Inertia::render('Errors/503', [
            'message' => trans('exception.service_unavailable', [
                'seconds' => $seconds,
                'minutes' => ceil($seconds / 60),
            ]),
        ])
            ->toResponse($this->request)
            ->setStatusCode($this->getStatusCode())
            ->withHeaders($this->getHeaders());
    }

    public function context()
    {
        return [
            'sessions.id' => $this->request->session()->getId(),
        ];
    }
}

Fixes #29685

This PR adds an option to collection's chunk method to reindex the chunks numerically or preserve the keys, just like PHP array_chunk method.

Before this PR:

collect([1, 2, 3, 4, 5, 6, 7])->chunk(3)->toArray();
// [[1, 2, 3], [3 => 4, 4 => 5, 5 => 6], [6 => 7]]

After this PR:

collect([1, 2, 3, 4, 5, 6, 7])->chunk(3, false)->toArray();
// [[1, 2, 3], [4, 5, 6], [7]]

collect([1, 2, 3, 4, 5, 6, 7])->chunk(3)->toArray();
// [[1, 2, 3], [3 => 4, 4 => 5, 5 => 6], [6 => 7]]