Why use toast when you can make your own little popup division for this.

If it offers an update but doesn't work then there has to be an issue with the updater code.

That's my guess. Are there any issues on this already on Github?

Edit:

Found this: https://github.com/laravel/installer/issues/510

Not at all.

I would suggest code an app first following MVC and laravel conventions which is usually all that is needed. Then do any evaluations on the app. You may be jumping ahead of yourself.

I went ahead and ask AWS AI assistant this:

is AWS Well-Architected basically guidelines

The answer:

Quote

Yes, AWS Well-Architected is essentially a set of guidelines and best practices. It's a framework developed by AWS to help you build secure, high-performing, resilient, and efficient infrastructure for your applications. The framework is built around six pillars:

Operational Excellence - focuses on operational processes and continuous improvement
Security - prioritizes strong security measures and data protection
Reliability - ensures systems can recover from failures and meet demands
Performance Efficiency - optimizes resource usage for performance
Cost Optimization - manages costs effectively
Sustainability - minimizes environmental impact

AWS also provides the AWS Well-Architected Tool to help you review your workloads against these best practices and get recommendations for improvement.

Please let me know if you have any follow-up questions. I can also connect you with an AWS Sales Representative for further discussion.

Unquote

Bottom line if using AWS they can answer your AWS related questions.

Is this in a docker container?

The aws well-architected framework is just things you do and check concerning your app. Sort of a check list. But yes you can use AWS to deploy to (host) the app.

Who are the policies for? If users why an API why not a regular web application.

Follow what @tray2 mentioned and follow laravel conventions. Namely MVC.

cloud architecture and virtual infrastructure

Companies like throwing fancy names on things like "cloud".

It boils down to:

You have code on a server that runs. Cloud is a fancy name for a server.

All your Github code shouldn't be a portfolio. Have one good example site to use for an example.

It's a CSRF error, your token was probably set.

If it's working code just needing some refactoring, why wouldn't they.

Do you mean use it or fix it for you?

I know https://www.wps.com is an official site.

See:

https://en.wikipedia.org/wiki/WPS_Office

I run links through Virustotal as well. Be aware they embed characters in some links to look official.

I also check country of origin for software and stay away from some countries, but that's your choice.

I also do backups of my drive with Macrium Reflect. If you have Linux there is software for that, search.

Conventions like MVC exist because they are the most practical approach for most projects.

Of course this can be overly structured for very simple sites, and not structured enough for much larger projects.

Yes, you could write data straight from the request to the model, this might work for simple forms, but what when the request involves MULTIPLE models? What if you need to run business logic on the data; where would you put that?

You can write php any way you like, but if you write a decent amount you will wish you had been more careful about the way it was built in the first place.

@randy_johnson You could also just dispense with it all and put everything in a single index.php script.

😮😮

VC is fine in some cases. If using query builder instead of eloquent for example.

In java many time I'd use VC, meaning servlet and view.

But usually in a larger app it's best to go full MVC. I know in laravel a lot of people do as you do and store in the controller. I as well, but for queries to retrieve data I use full MVC. I make use of query scopes also when needed.

I try to keep the controller lean. I'd rather have a fatter model.

Do we have to guess your question ?

Question?

I accidentally stabbed myself in the foot. Is there any way to unstab my foot? I only have two feet and this one is used to kick the cat so I cant afford to lose it.

Funny comparison ;).

Is this a how to use maatwebsite/excel article?

Look over: https://docs.digitalocean.com/products/snapshooter/how-to/back-up-managed-databases/

But I backup at least daily depending on the app.

I regularly use AI.

When I started using AI, I was impressed about the results, but there was frequently errors, too frequently. I lost time because of using AI.

Now I'm using AI only to save time for writing code I already know how write it, but much faster to write by the AI : I say to AI exactly what I want and there are less errors, I just have to correct some mistakes.

If you don't know what you need, the AI is not the best approach to code.

You must know what you need, then you can explain the AI exactly what you need, and the AI executes.

According to me you don't need EDA for your example.

I often say to me that I should always code as easy as possible (KISS principle).

I think you should learn how to code, and then use AI as a tool, and not as a developer.

Honestly, ignore the AI on this one. What you’ve written is a solid, clean Action class. It’s readable, it handles the transaction properly, and it gets the job done.

EDA is fantastic for decoupling, but it’s absolute overkill for a simple stock adjustment. You only really need to go down that road if a stock change needs to trigger a bunch of unrelated side effects like hitting a third-party API, sending emails, or clearing remote caches and you don't want to bloat your main logic.

Be careful using AI, it gets side tracked a lot. And do not use it for authentication or authorization, write your own. Know how to do these things without AI before using it as a tool.

Also see my reply here: https://laracasts.com/discuss/channels/ai/gemini-vs-claude-with-boost?page=1&replyId=975232

But I knew what to check to ensure AI was correct.

If AI seems side tracked, start over. Otherwise it gets more side tracked.

I agree with @martinbean and I see no reason to obsfucate code.

The framework part is open source anyway. And any application done in laravel, any knowledgeable developer can duplicate anyway.

If really concerned about "hiding" code I suggest have a SaaS application, that way an end user never actually sees the code.

It's already protected if the repo is private. Besides any modern app can be duplicated anyway by a knowledgeable developer.

Take this forum, can you see all the code used, no. Not counting the fact he shares how it's done. But if it was a private repo you couldn't.

I would suggest have a private repo for the client.

Just FYI I do my own. For Windows I download the zip files for mariadb, apache, php. Setting up is a little learning curve at first, but once you do it, it becomes easy.

And Linux, just install what you need.

Never used a MAC.

Digital Ocean has some good how to articles.

Has it been checked for safety?

I clicked the link and after getting out of the error page it seems laracast.com looses scroll. So somewhere Jeffrey seems to still have a CSS error.

I think if you're new go for it and give a month or two of studying. I think you're lucky to have it because it wasn't around when I started and everything has changed so much especially front end.

For me Laracasts has been worth every penny, and if you are missing something you can always contact the Laracasts team and ask for a more specific course on something, and if you are lucky they will create it.

Policies is great to keep all authorizations at the same place.

A service is to handle business logic, you shouldn't write any authorization code in a service.

For example, in my code :

• the services only execute the code for the business logic : get, store, update, delete, ...

• the policies contain the authorizations

• the controllers check for authorizations via the policies and then execute an action via the services

Have you tried hasFile with the thumbnail?

The dd ends execution.

Dis you tell apache new htdocs location?

DocumentRoot "/xampp/apache/htdocs"
<Directory "/xampp/apache/htdocs">

Are you sure Livewire 4 was pulled in?

When user goes to their roles page and go to a specific role panel, I will put the hidden roleId on forms, so I can check in authorization, if this user have this role, and if this role has the permission needed for the action. How is it? Is it a bad practice?

Don't do this. Anyone could modify the hidden input in the page source and spoof a different role.

You don't need to add any hidden inputs. Your backend already knows who the user is, and you can use Laravel's built-in authorization features. I strongly recommend you read the documentation first:

https://laravel.com/docs/13.x/authorization

But I can give you a quick rundown.

Below is a simple policy class for a Post model. It has just one authorization check: can a user edit a post. Editing is allowed if the user is a super-admin or the original author of the post.

class PostPolicy {
    public function edit(User $user, Post $post): bool {
        if ($user->role === 'super-admin')
			return true;
		 
		return $user->id === $post->user_id;
    }
}

Here's how you register the policy on the model:

use Illuminate\Database\Eloquent\Attributes\UsePolicy;

#[UsePolicy(PostPolicy::class)]
class Post extends Model {
    ...
}

Once you have the policy registered, you can do authorization checks in code, middleware, and Blade templates. Some examples:

// Authorization check in middleware:
Route::patch('/posts/{post}', [PostController::class, 'update'])
	->can('edit', 'post')
	->name('posts.update');
	
// Authorization check in a controller:
if ($request->user()->can('edit', $post)) {
	...
}

// Authorization check in Blade:
@can('update', $post)
	...
@endcan

The docs have all the details.

My opinion :

• it depends on what you need, but it's not a bad pratice to have one controller for the superadmin and one controller for the users

• the same logic can be applied to views and routes

• to check if a user has the permission to do an action, it's not a good practice at all to only check the role id in the frontend, you have to check authorizations in the backend and the best way to do that is to write policies, inside policies you can check the roles and/or the permissions

What you name authority is a role.

In pratice a user can have one or several roles and each roles comes with some permissions. It's generally not recommended to assign permissions directly to users. The best way is to assign permissions to roles and to assign roles to users. But for fine permissions control, you can occasionally assign permissions to users if it's really needed in your application, I don't do so, but sure some cases can justify to do so.

If you need help to do all this, you can have a look at this Laracasts series.

https://laracasts.com/series/mastering-permissions-in-laravel

When user goes to their roles page and go to a specific role panel, I will put the hidden roleId on forms, so I can check in authorization, if this user have this role, and if this role has the permission needed for the action. How is it? Is it a bad practice?

I agree with @jussimannisto do not use hidden fields. I suggest view some video series here on authentication and authorization. And review the documentation.

These checks are best done server side.

I also suggest taking this training: https://laracasts.com/series/laravel-from-scratch-2026

Also I gave an idea here: https://laracasts.com/discuss/channels/general-discussion/how-should-i-structure-authorization-for-owner-super-admin-community-admin-and-dynamic-roles-in-a-laravel-social-network?page=1&replyId=975679

Having same controller but a separate method for user verses admin.

Can you show the fields /s you want to use?

Edit:

I suggest backing up the database first, otherwise you could loose data.

I've already done this in the past too.

Rather than upgrading, it's sometimes faster to create a new application.

Here is what I did :

• backup all data
• keep all views and actions
• create a new application
• implement all functionalities, one by one

@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.

I had tried the Spatie Roles & Permissions package, but now I write my own roles and permissions code.

Do you want more details ?

Don't get hung up on the terms. A "Super Admin" means nothing to me except:

They can or cannot do something.

Think like this:

• Authentication = Logged in
• Authorization = What they can or cannot do with their role /s

I have an app where the admin can view but not otherwise mess with bookkeeping.

Learn about query scopes also, that way in a query a user can edit only their data but an admin can view all and edit certain fields.

DO NOT let AI write Authentication and Authorization, do this yourself. Go through the (yes steep) learning curve on this stuff. It gets easier once learned.

In a large app I do use separate controller methods, like:

• index is general user
• indexAdmin for admins of course

And separate views. In a smaller app I might not have the separation. This is highly subjective.

Note that the documentation covers this well and there are entire videos on this right here on laracasts.

Also before doing anything and while converting at various times:

Backup your data

You can't multiply that by 1000. At one time a best answer was 500 not 1000.

Careful getClientOriginalExtension() is unsafe, see:

https://symfonycasts.com/screencast/symfony-uploads/file-naming#play

https://symfonycasts.com/screencast/symfony-uploads/upload-in-form#play

https://symfonycasts.com/screencast/symfony-uploads/uploader-service#play