fix: add middleware to maintain locale across livewire requests (resolves #3037)

[rvs1212]

When searching or filtering on a page in a non-default locale, Livewire update requests fail with an error for pages that use translatable slugs. This middleware stores the locale in the session on page requests and restores it on Livewire requests.
Resolves #3037

Changes

• Added ResolveRequestLocale middleware.

Prerequisites

If this PR changes PHP code or dependencies:

• I've run composer format and fixed any code formatting issues.
• I've run composer analyze and addressed any static analysis issues.
• I've run php artisan test and ensured that all tests pass.
• I've run composer localize to update localization source files and committed any changes.

If this PR changes CSS or JavaScript code or dependencies:

• I've run npm run lint and fixed any linting issues.
• I've run npm run build and ensured that CSS and JavaScript assets can be compiled.

[codecov]

Codecov Report

❌ Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.97%. Comparing base (bf76f37) to head (e1bc064).

Files with missing lines	Patch %	Lines
app/Http/Middleware/ResolveRequestLocale.php	57.14%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##                dev    #3038      +/-   ##
============================================
- Coverage     96.99%   96.97%   -0.03%     
- Complexity     2472     2476       +4     
============================================
  Files           379      380       +1     
  Lines         11287    11294       +7     
============================================
+ Hits          10948    10952       +4     
- Misses          339      342       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jobara]

I'm not sure this is the best approach as the middleware will be touched by many if not all of the requests made, whether using livewire or not. There may be unintended side effects.

In looking at this more, I wonder if it's related to https://livewire.laravel.com/docs/3.x/upgrading#localization The docs there say that Livewire 3 doesn't respect the locale prefix anymore. You will need to change the update route. However, some people are reporting some other issues with this. livewire/livewire#8233

In Livewire 4 it seems you update this in a service provider and also allow for a hash value. https://livewire.laravel.com/docs/4.x/installation

This makes me think you should do the Livewire update and see if the issue still persists and if so, if you can change the update endpoint based on the Livewire 4 docs.

[rvs1212]

I checked the Livewire docs and also looked into similar discussions around this. The project uses chinleung/laravel-multilingual-routes, which registers separate routes for each locale instead of using a route group prefix approach. I also tried the setUpdateRoute() option, but even if I follow the approach mentioned in the Livewire docs (https://livewire.laravel.com/docs/3.x/upgrading#localization), it still requires middleware to store and restore the locale. In our case, the locale is dynamic per user, so customizing the update route alone does not fully solve the issue. I believe this would be the same situation even if we upgrade to a newer Livewire version. That is why I thought handling this through middleware might be a safer approach.

[jobara]

Why is the else condition necessary? Is there another similar issue with a different request?

[rvs1212]

The else case saves the locale to the session on page requests, so it can be restored on Livewire requests.

[jobara]

I checked the Livewire docs and also looked into similar discussions around this. The project uses chinleung/laravel-multilingual-routes, which registers separate routes for each locale instead of using a route group prefix approach. I also tried the setUpdateRoute() option, but even if I follow the approach mentioned in the Livewire docs (https://livewire.laravel.com/docs/3.x/upgrading#localization), it still requires middleware to store and restore the locale. In our case, the locale is dynamic per user, so customizing the update route alone does not fully solve the issue. I believe this would be the same situation even if we upgrade to a newer Livewire version. That is why I thought handling this through middleware might be a safer approach.

Ideally you' probably want to be working with the latest versions to make sure that they haven't addressed the issue. There is also a new release of Laravel out now. If you don't do the update before hand, you'll need to leave a tasks to revisit the issue when you do the upgrades.

[rvs1212]

I checked the Livewire docs and also looked into similar discussions around this. The project uses chinleung/laravel-multilingual-routes, which registers separate routes for each locale instead of using a route group prefix approach. I also tried the setUpdateRoute() option, but even if I follow the approach mentioned in the Livewire docs (https://livewire.laravel.com/docs/3.x/upgrading#localization), it still requires middleware to store and restore the locale. In our case, the locale is dynamic per user, so customizing the update route alone does not fully solve the issue. I believe this would be the same situation even if we upgrade to a newer Livewire version. That is why I thought handling this through middleware might be a safer approach.

Ideally you' probably want to be working with the latest versions to make sure that they haven't addressed the issue. There is also a new release of Laravel out now. If you don't do the update before hand, you'll need to leave a tasks to revisit the issue when you do the upgrades.

Right, I'm also thinking to upgrade and check if it can be resolved.