@vincent15000

...unless a repository is placed on the same computer locally :)

Installer does some additional tuning for new app, such as disabling Pail on Windows installation. Since it's recommended and documented way to install Laravel it should work.

Did you try to uninstall / install laravel installer instead of updating?

It seems you just put in before logic that should be in actual create, viewAny, ...etc policies (you literally refer to them in your code), so I don't see the point here.

before is for cases that are completely out of a regular policy, for example "if a user is main admin then everything is allowed".

I'm also not sure if accessing route models directly through request() inside policies is considered good practice.

No, it's bad practice. Policies shouldn't know about your HTTP request, they just answer a question: can specific user do specific action or not?

Imagine your app is accessed other than via HTTP, let's say from console command. In that case calling request() in a policy is pointless.

Instead, you should apply a policy to a route with a middleware: https://laravel.com/docs/13.x/authorization#via-middleware

Laravel will take a user from a request and apply a policy to it.

Also I suggest comparing models using built-in method is():

if ($user->is($actualTrainer)) { ... }

Comparing integer ids is less readable and can be wrong when using multiple database connections. is() method handles it right way.

You are welcome.

Yes, something like this looks fine for me. You should agree this is clean and simple.

is it okay even if i repeat the code in most of policies?

If you extract code which defines actualTrainer to a private method (or public method of a model maybe) and refer to it in each policy - yes, it's fine. Just don't repeat complicated logic, extract it somewhere and reuse where you need it.

so, they should receive the extra information from the controller (or requests)?

Sorry I don't get what you mean.

It seems you just put in before logic that should be in actual create, viewAny, ...etc policies (you literally refer to them in your code), so I don't see the point here.

before is for cases that are completely out of a regular policy, for example "if a user is main admin then everything is allowed".

I'm also not sure if accessing route models directly through request() inside policies is considered good practice.

No, it's bad practice. Policies shouldn't know about your HTTP request, they just answer a question: can specific user do specific action or not?

Imagine your app is accessed other than via HTTP, let's say from console command. In that case calling request() in a policy is pointless.

Instead, you should apply a policy to a route with a middleware: https://laravel.com/docs/13.x/authorization#via-middleware

Laravel will take a user from a request and apply a policy to it.

Also I suggest comparing models using built-in method is():

if ($user->is($actualTrainer)) { ... }

Comparing integer ids is less readable and can be wrong when using multiple database connections. is() method handles it right way.

will have outdated Laravel 12 and packages

So what? Not all apps are required to be up to date and not all are even publicly accessed. Sometimes it's more important to have running app right now rather than playing with forking someone's packages.

What if you need a package which is not tuned for Laravel 13 yet? Then you have to use 12 or even older versions.

Packages dependency issues probably.

No, you can't be sure. The situation needs investigation, at least analyzing logs on all involved nodes.

Google for "499 nginx", it's quite common issue. I think you should ask Forge support.

I don't see why a developer wouldn't do it, properly rewarded especially.

What "this"? What do you mean by "work on it"? Web developers do web related stuff, you need to be more specific.

I think it depends on their salary.

Interesting task. I have some ideas but on deep thought they are far from true reliability. I'd listen for other opinions as well.

General idea is: you can't reliably control what is going on in user's browser. An advanced user can break through your protection.

You can't prevent a user from taking screenshots of a tab, closing it and opening new tab with screenshots opened in image viewer, after all.

What is app:build? This command is not built-in, did you write it?

No idea, sorry. Maybe you should test the same logic on recent Laravel/Livewire versions - if the problem is gone I'm afraid you don't have much options but your workaround.

By the way, the workaround you call "a hack" seems pretty clear and nice for me. Maybe it's not too bad.

even though there is no username field in the data

Are you sure username field is not present at all? It may be present but null for example.

Do dd($data) before validation to make sure.

Look here: https://docs.laravel-excel.com/3.1/imports/validation.html#validating-with-a-heading-row

If your validation rules reference other field names, ... the field name must be prefixed with *.

So try this:

'beans' => ['exclude_if:*.batch,SUM', ...

Look here: https://docs.laravel-excel.com/3.1/imports/validation.html#validating-with-a-heading-row

If your validation rules reference other field names, ... the field name must be prefixed with *.

So try this:

'beans' => ['exclude_if:*.batch,SUM', ...

Can it be first letter case issue? Your column is Batch while rule refers to batch. Try to change the rule:

'beans' => ['exclude_if:Batch,SUM', ...

You may more or less understand what's going on inside the function right now. But after a month or half a year you'll be totally lost, for sure.

I'm getting the error: JSON ERROR: Syntax error

Where is it exactly? In browser window, in browser console, in logs?..

How does the error look? Is it Laravel error or generic web server error?

Look into Nginx error logs.

You misunderstand what observer is. It has nothing to do with your task. You should schedule a command every N minutes (whatever frequency you prefer) which:

• takes records ready to be published (in other words, which have published_at in less than N minutes in future)
• publishes them
• applies service function you want to be applied to "scheduled" records.

Model observers are about events system, this is another topic.

If you use version control, such as Git, recovery is easy. Every developer should always use version control, even if they're working alone.

Another easy way is through an IDE. PhpStorm has a local history that shows file deletions, which you can revert. VS Code is a bit worse in this regard, but it's still possible.

Otherwise, you might be able to do it with some recovery tool. Recovering deleted files is less likely on SSDs than HDDs. Your best bet is to google "undelete tool" and try something to recover it. Recovery becomes less and less likely the longer you keep using the device.

No, recovering your local deleted files is out of Laravel responsibility. You should search in your local system for such things.

If you use version control system (most likely Git) and committed your controller then search there. But I'm afraid that's not the case otherwise you wouldn't ask.

As last chance you can use some data recovery software and most likely you'll find your file as deleted files are not actually erased from disk. I successfully used R-Studio: https://www.r-studio.com/

But I think rewriting the class is the best option for you. It is not so hard to do, you'll polish the logic at the same time. Rewriting actually helps.

@ghabriel25 There is actually: https://laravel.com/docs/13.x/database#the-sticky-option

INSERT INTO change_logs_backup SELECT * FROM change_logs;

It would take forever. For backup I'd rename change_logs to change_logs_backup and create change_logs from scratch. Same result but almost instantly.

No valid SQL request would crash a database server, you may not worry about that. It is not a matter of table size in any case.

You can dump table structure using SHOW CREATE TABLE tablename or with mysqldump (there is an option for dumping structure only). After that drop a table and recreate with previously dumped structure.

I'm not sure if TRUNCATE does exactly the same as drop/create, but the result would be the same: clean table without rows.

What I wouldn't do is DELETE FROM tablename as it would be very slow and internal counter for auto increment primary key is preserved (so new row id would be something like 167 000 001 which doesn't seem preferable).

Another issue is reclaiming free space used by InnoDB files; the occupied space isn't released automatically especially if you have innodb_file_per_table = off. There are many articles about releasing occupied space; to be short, you have to make full database backup, set innodb_file_per_table = on and restore backup. After that all tables are stored in their own dedicated files and occupy only space really needed for data.

@eskiesirius You shouldn’t be using a single column to hold the balance. You should instead of some form of ledger table, where you write individual increments and decrements as their own rows, and then derive the balance from the sum of those increments and decrements. It’s not “expensive” if you have a proper index in place.

Give your data structure (tables, columns) and actual code that "says relationship doesn't exist".

I agree scopes are good.

Isn't it your situation described? https://laravel.com/docs/8.x/eloquent-relationships#chaining-orwhere-clauses-after-relationships

How about this?

$products = Product::query()
    ->where('parent_id', '!=', 0)
    ->whereHas('flags', function ($query) use ($messages) {
        $query
            ->where('is_valid', 1)
            ->where(function ($query) use ($messages) {
                foreach ($messages as $message) {
                    $query->orWhere('message', 'LIKE', $message);
                }
            });
    })
    ->get();

You see no bootstrap.js and empty app.js because these files are absent/empty in laravel/laravel repository which is cloned to you every time you install new Laravel app.

The reason why these files were changed in the repository are described by the link I provided.

Something tells me it is related to some Axios vulnerabilities recently discovered.

Sorry maybe I don't fully understand the question...

I guess it's about @context, @type which Blade engine recognizes as directives.

See here: https://laravel.com/docs/13.x/blade#blade-and-javascript-frameworks

The @ symbol may also be used to escape Blade directives:

So I think you should either use double @ :

"@@context": "https://schema.org",
"@@type": "WebSite",

Or wrap your scripts with @verbatim ... @endverbatim which prevents it's inner content to be processed by Blade engine:

<script type="application/ld+json">
@verbatim
    {
        "@context": "https://schema.org",
        "@type": "WebSite",
        "name": "xxx",
        ...
    }
@endverbatim 
</script>

I guess it's about @context, @type which Blade engine recognizes as directives.

See here: https://laravel.com/docs/13.x/blade#blade-and-javascript-frameworks

The @ symbol may also be used to escape Blade directives:

So I think you should either use double @ :

"@@context": "https://schema.org",
"@@type": "WebSite",

Or wrap your scripts with @verbatim ... @endverbatim which prevents it's inner content to be processed by Blade engine:

<script type="application/ld+json">
@verbatim
    {
        "@context": "https://schema.org",
        "@type": "WebSite",
        "name": "xxx",
        ...
    }
@endverbatim 
</script>

You see no bootstrap.js and empty app.js because these files are absent/empty in laravel/laravel repository which is cloned to you every time you install new Laravel app.

The reason why these files were changed in the repository are described by the link I provided.

Something tells me it is related to some Axios vulnerabilities recently discovered.

Sorry maybe I don't fully understand the question...

Related to this? https://github.com/laravel/laravel/pull/6778

Why you want v4? Filament 5 was released some time ago, and several updates came already.

SECURITY PROBLEM: insecure server advertised AUTH=PLAIN (errflg=1)

This error strikes from IMAP connection which is used to access a mailbox, not for sending emails. Where this error goes from in your code? I mean specific file and line.

So the problem is definitely somewhere inside XAMPP settings. Sorry I'm not very familiar with it. Try to revert your latest changes or even reinstall it from scratch. Looking into Apache logs would be useful also.

...Or you may continue using php artisan serve instead of XAMPP web server.

Do you have the error when serving app with php artisan serve instead of XAMPP?

Use php artisan route:list, do you have all routes there?

As usual, first of all try php artisan optimize:clear and recreate vendor folder (delete it and run composer install)

A clumsy and awkward approach of recreating conventional OOP logic in functional style?

@iamyannc Hey. I’ve done a lot of these type of re-factoring and re-platforming projects in the past. The way I’d approach it would be like this:

• Get the application running on a newer version of PHP. So upgrade to 7, fix any usage of deprecated APIs and libraries, and then when possible upgrade to PHP 8 and do the same.
• Once you’ve got the vanilla PHP application running on a modern version of PHP, create a new Laravel application and dump your legacy application’s file in the public directory.
  • Rename Laravel’s index.php file to something like laravel-index.php to avoid clashing with your legacy index.php file.
  • Tweak your .htaccess or nginx config to just load a file if it exists, or fall back to Laravel’s front controller.
• You should now have a Laravel application, but with no requests actually being routed through it to start off with, and instead requests hitting your legacy application as before.
• Slowly start re-factoring your legacy application to Laravel controllers, views, etc. Do this slowly, and one discreet part at a time. Trying to re-factor too much in one go just leads to lots of files being touched, none of them 100% converted, and the dreaded feeling of, “Urgh, I need to git reset this and start over.”
• As you do the above, the number of files from the legacy application will decrease, and the number of Laravel files increase, until you’re left with nothing of the legacy application.

Happy for you to reach out if you have any questions. DM me on Twitter 𝕏 (https://x.com/martinbean) and I can share my email address.

https://github.com/laravel/envoy/issues/3 ?

@servers(['web' => "user@hostname -p 12345"])

https://github.com/laravel/envoy/issues/3 ?

@servers(['web' => "user@hostname -p 12345"])