Pest

Overview Laravel continues to refine its developer experience with the release of versions 10.37 and 10.38. These updates focus on reducing boilerplate code in Blade templates and providing more granular control within the testing suite. By introducing more intuitive syntax for session handling and job assertions, the framework empowers developers to write cleaner, more expressive code. Prerequisites To get the most out of these features, you should be comfortable with basic PHP syntax and the Laravel framework. Familiarity with Blade templating, PHPUnit or Pest testing patterns, and the Laravel Service Bus for queued jobs will help you implement these changes effectively. Key Libraries & Tools - **Laravel 10.37/10.38**: The core framework providing these new helpers. - **Blade**: Laravel's powerful templating engine. - **PHPUnit**: The testing framework used to validate route redirections and job chains. Code Walkthrough Simplified Session Display Previously, displaying a flash message required manual checks via the session helper. The new `@session` directive automates this and provides a local `$value` variable. ```php @session('status') <div class="alert alert-success"> {{ $value }} </div> @endsession ``` Improved Route Testing When testing redirects, we often need to specify where a user originated. The `fromRoute` method replaces the generic `from` method, allowing you to use route names instead of hardcoded URLs. ```php $response = $this->actingAs($user) ->fromRoute('news.edit', ['news' => $news]) ->put(route('news.update', $news), $data); $response->assertRedirect(); ``` Asserting Chained Jobs via Closures You can now inspect the specific properties of a chained job using a closure, ensuring that the correct data passes through the queue. ```php Bus::fake(); // Run the logic... Bus::assertChained([ function (ReleasePodcast $job) { return $job->podcastId === 1; } ]); ``` Syntax Notes The `@session` directive is a specialized conditional. It only renders its content if the specified key exists in the session, automatically injecting the value into a scoped `$value` variable. In testing, the `assertValidationError` method now accepts an array of strings, allowing you to verify that multiple validation rules (like `string` and `min:5`) failed simultaneously for a single input field. Tips & Gotchas When using the new closure-based job assertions, always type-hint the job class in the closure signature. This ensures Laravel can correctly match the job in the chain. For the `@session` directive, remember that it specifically looks for flashed data; it won't replace standard persistent session logic for long-term data storage.

Overview Testing logic that involves delays or waiting periods often results in slow, brittle test suites. Standard PHP `sleep()` calls force the execution to halt, meaning a test needing a five-second delay actually takes five seconds to run. The Laravel Sleep Helper Class solves this by providing a testable wrapper around PHP's native sleep function, allowing developers to fake time and verify execution flow without the performance penalty. Prerequisites To follow this guide, you should have a baseline understanding of PHP and the Laravel framework. Familiarity with Pest or PHPUnit for testing is highly recommended, as the primary benefit of this feature lies in its assertion capabilities. Key Libraries & Tools - **Laravel Framework**: The primary ecosystem providing the `Sleep` utility. - **Laravel Forge**: A server management tool that recently updated its deployment tracking logic for custom providers. - **PHP**: The underlying language providing the base `sleep()` function. Code Walkthrough To transition from standard sleep calls to the new API, first import the `Sleep` facade. Replace standard function calls with the more expressive syntax. ```php use Illuminate\Support\Sleep; // Instead of sleep(5); Sleep::for(5)->seconds(); ``` In your test suite, you can tell Laravel to intercept these calls using `fake()`. This prevents the actual delay from occurring during the test run. ```php public function test_delayed_action() { Sleep::fake(); // Trigger code that calls Sleep::for(5)->seconds(); Sleep::assertSleptTimes(1); } ``` Syntax Notes The new API favors human-readable methods like `seconds()` or `milliseconds()`. This fluent interface replaces the ambiguity of integer-based arguments in native functions. By calling `Sleep::fake()`, the framework replaces the real sleeper with a mock that records all calls for later assertion. Practical Examples Beyond simple faking, you can verify complex timing sequences. If a process must sleep for five seconds and then three seconds, use `assertSequence` to ensure the logic follows the exact required pattern. This is critical for rate-limiting logic or exponential backoff implementations. Tips & Gotchas Always remember to call `Sleep::fake()` at the beginning of your test. If you forget, your tests will revert to real-time delays, significantly slowing down your CI/CD pipeline. For those using Laravel Forge with custom Git providers, take advantage of the new automated commit inference which now tracks branch and committer data even without native GitHub integration.

Overview Laravel continues to evolve by prioritizing developer experience and code readability. The framework is moving away from cryptic string-based configurations toward a more robust **typed API** for first-party middlewares. Simultaneously, the testing suite is expanding with new semantic assertion methods. These updates eliminate the need to memorize HTTP status codes, making your test suites more expressive and your route definitions self-documenting. Prerequisites To implement these patterns, you should be comfortable with PHP 8.x and the Laravel framework fundamentals. Familiarity with HTTP middleware logic and writing functional tests using **PHPUnit** or **Pest** is essential. Key Libraries & Tools * **Laravel Framework**: The core PHP ecosystem receiving these updates. * **ThrottleRequests Middleware**: A first-party middleware used to limit request frequency. * **TestResponse Class**: The underlying class providing assertion methods for HTTP tests. Code Walkthrough: Typed Middleware Previously, defining middleware arguments felt like guessing. Passing arbitrary numbers into a string was prone to error. The new typed API allows you to use static methods for configuration. ```php // The old, confusing way Route::middleware('throttle:10,1')->group(function () { // What do 10 and 1 mean? }); // The new, readable Typed API use Illuminate\Routing\Middleware\ThrottleRequests; Route::middleware([ ThrottleRequests::with(maxAttempts: 10, decayMinutes: 1) ])->group(function () { // Explicitly defined parameters }); ``` By using named arguments within the `with` method, you immediately communicate the intent of the throttle—10 attempts every 1 minute—without checking the documentation. Syntax Notes: Semantic Test Assertions Testing status codes is common, but `assertStatus(500)` is less descriptive than its name. Laravel now offers three specific methods to replace generic status checks: * `assertGone()`: Replaces `assertStatus(410)`. * `assertInternalServerError()`: Replaces `assertStatus(500)`. * `assertServiceUnavailable()`: Replaces `assertStatus(503)`. These follow the pattern of existing helpers like `assertOk()` (200) and `assertNotFound()` (404), ensuring your test assertions read like English sentences. Tips & Gotchas Transitioning to the typed API is an incremental rollout. While **ThrottleRequests** is ready, check the official documentation as more first-party middlewares adopt this pattern. For testing, always prefer the semantic method (e.g., `assertInternalServerError`) over the status code version to keep your tests resilient and readable during code reviews.

Overview Implementing a robust image management system in a Laravel application requires more than just moving a file from a request to a disk. It involves managing database relationships, ensuring administrative oversight, and maintaining a secure environment where users only interact with data they own. In this tutorial, we will walk through the implementation of an 'Airbnb-like' office rental platform. You will learn how to handle polymorphic image uploads, designate specific images as 'featured' without creating redundant database queries, and implement strict validation rules that prevent orphaned files and unauthorized deletions. This guide moves beyond basic CRUD operations to explore the architectural decisions that keep an application scalable and its data integrity intact. Prerequisites To follow this walkthrough, you should have a solid grasp of the following concepts and tools: - **PHP 8.x**: Familiarity with modern PHP syntax, including return types and arrow functions. - **Laravel Framework**: Understanding of Eloquent models, migrations, and basic routing. - **Testing Culture**: Baseline knowledge of PHPUnit or Pest and why we use traits like `RefreshDatabase`. - **RESTful APIs**: Knowledge of HTTP methods (POST, PUT, DELETE) and JSON response structures. Key Libraries & Tools - **Laravel Eloquent**: The ORM used for handling polymorphic relationships between images and various resources like offices or reviews. - **Laravel Storage**: A powerful abstraction layer for the file system, allowing us to swap local storage for Amazon S3 with zero code changes. - **Insomnia/Postman**: API clients used for manual verification of multi-part form data uploads. - **Laravel Sanctum/Passport**: (Assumed) for handling authentication and token-based scope checks. Section 1: Administrative Housekeeping and Scoped Queries Before we can allow users to upload photos, we must establish who has the authority to approve these listings. We start by modifying the `users` table to include an `is_admin` boolean. This simple flag is the backbone of our notification system, ensuring that whenever a host creates or updates an office, the right people are alerted for approval. However, a common hurdle in marketplaces is the visibility of unapproved listings. Usually, an API hides 'pending' or 'hidden' records from the public. But a host needs to see their own drafts. We solve this by implementing a conditional query using the `when` method in our `OfficeController`. ```python $offices = Office::query() ->when($request->user_id && auth()->id() == $request->user_id, fn($query) => $query, fn($query) => $query->where('approval_status', 'approved')->where('hidden', false) ) ->get(); ``` This logic ensures that if a user is viewing their own profile, they see the full picture, while the public remains restricted to curated, approved content. Section 2: Implementing Polymorphic Image Uploads In a complex application, images aren't just for offices; they might be for user profiles, reviews, or messages. Instead of creating an `office_images` table, we use a polymorphic `images` table. This allows one model to belong to multiple other models on a single association. In the `OfficeImageController`, the `store` method handles the heavy lifting. We validate the incoming request to ensure it is actually an image and stays under a 5MB threshold. ```python public function store(Request $request, Office $office) { $this->authorize('update', $office); $request->validate([ 'image' => ['required', 'image', 'max:5120', 'mimes:jpeg,png'] ]); $path = $request->file('image')->storePublicly('/', ['disk' => 'public']); $image = $office->images()->create([ 'path' => $path ]); return ImageResource::make($image); } ``` Using `storePublicly` is a best practice here because it ensures the file is accessible to the web server immediately. By returning an `ImageResource`, we provide the front-end with a consistent JSON structure containing the new image's ID and URL. Section 3: The Featured Image Architectural Dilemma There are several ways to track which image is the 'main' photo for a listing. You could add a `is_featured` boolean to the `images` table. However, this is inefficient. To change a featured image, you would have to run a query to 'un-feature' the old one and another to 'feature' the new one. Furthermore, if the `images` table is polymorphic, adding an `is_featured` column might not make sense for other types of resources that don't need a primary photo. The cleaner solution is adding a `featured_image_id` to the `offices` table. This creates a direct `belongsTo` relationship from the Office to a specific Image. This approach is highly performant; when you want to change the featured photo, you simply update one ID on the office record. We must protect this with a custom validation rule. We need to ensure that the image being promoted actually belongs to that specific office. We don't want User A to be able to set an image belonging to User B's office as their own featured photo. Section 4: Secure Deletion and File System Integrity Deleting an image is more than just removing a row from a database. If you don't delete the physical file from the disk, you end up with 'zombie files' that consume storage costs without being used. In our `delete` method, we implement several safety checks: 1. **Ownership**: Does this image belong to this office? 2. **Minimum Requirement**: Is this the only image? We might want to prevent users from having an office listing with zero photos. 3. **Featured Protection**: Is this the currently featured image? Deleting it would break the UI's primary display. ```python public function delete(Office $office, Image $image) { throw_if($office->images()->count() === 1, ValidationException::withMessages(['image' => 'Cannot delete the only image.']) ); throw_if($office->featured_image_id === $image->id, ValidationException::withMessages(['image' => 'Cannot delete the featured image.']) ); Storage::disk('public')->delete($image->path); $image->delete(); return response()->noContent(); } ``` Syntax Notes & Best Practices - **Arrow Functions**: We use `fn($query) => ...` for short, readable callbacks in Eloquent queries. - **Testing with Fakes**: Using `Storage::fake('public')` is essential. It prevents your test suite from actually writing files to your local machine, which keeps your development environment clean and your tests fast. - **Route Model Binding**: By type-hinting `Office $office` in the controller, Laravel automatically finds the record in the database. If it doesn't exist, it throws a 404, saving us from writing manual 'if-not-found' checks. Practical Examples This logic is the standard for any platform where users manage their own content. Beyond 'Airbnb' clones, this pattern applies to: - **E-commerce**: Selecting the primary product photo while allowing multiple gallery images. - **Social Media**: Setting a profile 'cover photo' from an existing album. - **Real Estate**: Managing property walkthrough photos where the 'front view' must be specifically designated. Tips & Gotchas - **The ID Conflict**: Always verify that the `image_id` passed in an update request belongs to the `resource_id` being updated. Failing to do this is a common security vulnerability known as Insecure Direct Object Reference (IDOR). - **RefreshDatabase**: When testing file uploads, ensure you use the `RefreshDatabase` trait. If you don't, your database will quickly fill up with test records that might cause unique constraint collisions in future test runs. - **Manual Verification**: While automated tests are great, always test multi-part form data manually at least once using a tool like Insomnia. Automated fakes can sometimes miss issues related to server-side `upload_max_filesize` settings in your `php.ini`.