taylorotwell
Repos
27
Followers
26701
Following
1

Laravel is a web application framework with expressive, elegant syntax. We’ve already laid the foundation for your next big idea — freeing you to create without sweating the small things.

71104
22222

The Laravel Framework.

27962
9360

Events

Update EnsureRequestsDontExceedMaxExecutionTime.php

Created at 1 minute ago

Import fix for BatchFake + tests (#44435)

Co-authored-by: Alex Skripov askripov@magaya.com

Created at 15 minutes ago
delete branch
taylorotwell delete branch fix-re-enabling-recording
Created at 20 minutes ago

Fix re-enabling recording (#1258)

Created at 20 minutes ago
pull request closed
[4.x] Fix re-enabling recording

Small adjustment for my PR at https://github.com/laravel/telescope/pull/1257. We should check if Telescope was recording to begin with. If it wasn't, we should also not re-enable recording.

Created at 20 minutes ago

Import fix for BatchFake + tests (#44435)

Co-authored-by: Alex Skripov askripov@magaya.com

Created at 20 minutes ago
pull request closed
Import fix for BatchFake + tests

Added missing import for the BatchFake and added test to proof that nothing is breaking

Created at 20 minutes ago
pull request closed
[9.x] Handle precognition requests by default

Requires a framework release for https://github.com/laravel/framework/pull/44339

This PR adds the HandlePrecognitiveRequests middleware to the default middleware stack. The goal of this is to make it even more frictionless for people to get started with implementing precognition requests.

Precognition requests are invoked with a Precognition: true header meaning apps that don't explicitly pass this aren't affected. The only thing that's left to do for users is to implement the isPrecognitive checks in their apps. Adding the middleware on a route-per-route basis isn't needed anymore.

People can still turn off this global middleware and implement on a route-per-route basis but I could not see a problem by adding this by default.

Created at 1 hour ago
issue comment
[9.x] Handle precognition requests by default

I think it's probably mostly intended that you apply this on the routes you want to be precognitive.

Created at 1 hour ago
pull request closed
[9.x] Support using primary attribute keys for custom displayable values

This PR allows using primary attribute keys (foo.*, foo.*.bar) when providing custom values for validation. The implementation is pretty much copied from the Illuminate\Validation\Concerns\FormatsMessages::getDisplayableAttribute() method.

This makes it possible to use custom values for attributes where the exact key is not known, or when using exact keys is not optimal. Consider the following example:

use Illuminate\Support\Facades\Validator;

$validator = Validator::make([
  'packages' => [
    ['country' => 'AQ'],
    ['country' => 'US'],    
  ]
], [
  'packages.*.country' => 'in:US'
], [
  'packages.*.country.in' => ':input is not a valid shipping country'
]);

How can we provide custom values for the country attribute of each package? Right now, we would have to know each package key and provide the custom value for each of them

$validator->addCustomValues([
  'packages.0.country' => ['AQ' => 'Antarctica', 'US' => 'United States'],
  'packages.1.country' => ['AQ' => 'Antarctica', 'US' => 'United States'],  
]);

// error message: "Antarctica is not a valid shipping country"

Clearly, this is not great - we can do better: this PR allows simply using the asterisk (just like for validation rules and custom attributes) to provide a single source of custom values for all the elements in the array:

$validator->addCustomValues([
  'packages.*.country' => ['AQ' => 'Antarctica', 'US' => 'United States']
]);

// error message: "Antarctica is not a valid shipping country"

It works for associative arrays as well:

// input: ['country_map' => ['foo' => 'US', 'bar' => 'AQ']]

$validator->addCustomValues([
  'country_map.*' => ['AQ' => 'Antarctica', 'US' => 'United States']
]);

It's still possible to provide values for each individual array element (specific values take precedence over primary attribute values):

// input: ['country_map' => ['foo' => 'US', 'bar' => 'AQ']]

$validator->addCustomValues([
  'country_map.*' => ['AQ' => 'Antarctica', 'US' => 'United States']
  'country_map.bar' => ['AQ' => 'Antarktis', 'US' => 'Vereinigte Staaten']
]);
Created at 1 hour ago
issue comment
[9.x] Support using primary attribute keys for custom displayable values

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Created at 1 hour ago

instantiate maintenance mode events (#44417)

Created at 1 hour ago
pull request closed
[9.x] Allow maintenance mode events to be listened to in closure based listeners

I'm not sure if this is a bug as such but I ran into this today.

I was trying to listen to MaintenanceModeDisabled::class and broadcast this (which I don't think works in maintenance mode anyway) but nonetheless, was faced with this error when registering my listener as usual, with the event type-hinted in the handler so I could then dispatch my own event to broadcast it;

class MaintenanceModeDisabledListener
{
    public function handle(\Illuminate\Foundation\Events\MaintenanceModeDisabled $event)
    {
        MyCustomMaintenanceModeDisabledEvent::dispatch();
    }
}

This was met with an error; Too few arguments to function ....\MaintenanceModeDisabledListener::handle(), 0 passed in .../vendor/laravel/framework/src/Illuminate/Events/Dispatcher.php on line 441 and exactly 1 expected

Upon further experimenting I realised that the following listener would also fail and mean you couldn't listen to these events using closures;

Event::listen(function (MaintenanceModeDisabled $event) {
    // custom logic here
});

This behaviour is confirmed with the following failing tests;

public function testDisabledEventCanBeListenedTo()
{
    file_put_contents(
        storage_path('framework/down'),
        json_encode([
            'retry' => 60,
            'refresh' => 60,
        ])
    );

    Event::listen(function (MaintenanceModeDisabled $event) {
        $this->assertTrue(true);
    });

    $this->artisan(UpCommand::class);
}

public function testEnabledEventCanBeListenedTo()
{
    Event::listen(function (MaintenanceModeEnabled $event) {
        $this->assertTrue(true);
    });

    $this->artisan(DownCommand::class);
}

By instantiating the events for dispatch, the events can be listened to using closures. I also couldn't really find anywhere else in the framework where ->dispatch($eventClassNameAsString) was used so hoped that this would be the solution. I wasn't sure if any tests were relevant or required.

Created at 1 hour ago

[9.x] Short attribute syntax for Self Closing Blade Components (#44413)

  • Short attribute syntax for Self Closing Blade Components

  • Fix test

Created at 1 hour ago
pull request closed
[9.x] Consider newlines in foreach/forelse Blade statements

A few weeks ago I submitted a PR that implements some validations in foreach/forelse statements in Blade: https://github.com/laravel/framework/pull/44134

All tests were passing, but, there was a case that didn't have any tests covering: newlines inside statement declaration. See more: https://github.com/laravel/framework/pull/44134#issuecomment-1264042847

This PR fixes this behavior, replacing to \s in the REGEX, and adjusting tests to cover this case.

Created at 1 hour ago
issue comment
[9.x] Consider newlines in foreach/forelse Blade statements

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Created at 1 hour ago

[9.x] Short attribute syntax for Self Closing Blade Components (#44413)

  • Short attribute syntax for Self Closing Blade Components

  • Fix test

Created at 1 hour ago
pull request closed
[9.x] Short attribute syntax for Self Closing Blade Components

This PR follows https://github.com/laravel/framework/pull/44217 and implements the short attribute syntax for self-closing blade components.

<!-- current short syntax -->
<x-profile :$userId></x-profile>

<!-- short syntax for self-closing component -->
<x-profile :$userId/>
Created at 1 hour ago

[9.x] Improve test for HasNameRoute in RouteCollection Class (#44419)

Created at 1 hour ago
pull request closed
[9.x] Improve test for HasNameRoute in RouteCollection Class
Created at 1 hour ago
pull request closed
[9.x] Add ext-gmp to composer suggest

Running the tests in Illuminate\Tests\Integration\Database\EloquentModelCustomCastingTest without the ext-gmp extension installed leads to multiple Call to undefined function Illuminate\Tests\Integration\Database\gmp_init() errors.

This PR adds ext-gmp to composer's suggested packages.

Created at 1 hour ago
issue comment
[9.x] Add ext-gmp to composer suggest

Feels weird to suggest to end users an extension only needed to run tests.

Created at 1 hour ago
pull request closed
Update eloquent.md

Noticed a missing return.

Created at 1 hour ago
issue comment
Update eloquent.md

Not necessary.

Created at 1 hour ago

Add forceRootUrl to URL facade doc block (#44415)

Created at 1 hour ago
pull request closed
feature: added config option to disable handling of bearer tokens

Description

This pull request adds the ability to disable the default behaviour of Sanctum to interpret bearer tokens in the request header if none of the provided guards were able to authenticate the request.

Details

Currently, if you ignore Sanctum's database migrations because you want to rely on, for example, a custom Guard which authenticates with a third party auth service instead, and this Guard fails to authenticate the user (e.g. expired/invalid tokens), then Sanctum will also attempt to validate the Bearer token by itself, which results in a table not found database error.

In order to prevent such issues, we can prevent Sanctum from handling bearer tokens via a config option.

This change is fully backwards compatible & keeps the current behaviour, unless specifically set to false in the config.

Created at 1 hour ago
issue comment
feature: added config option to disable handling of bearer tokens

Thanks for your pull request to Laravel!

Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.

If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!

If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

Created at 1 hour ago
pull request closed
Patch 1
Created at 1 hour ago

Add forceRootUrl to URL facade doc block (#44415)

Created at 1 hour ago
pull request closed
Add `forceRootUrl` to `URL` facade doc block

I find this a useful method especially when dealing with multiple sub-domains. Adding it to the doc block just so IDEs don't see it as an error.

Created at 1 hour ago