Laravel Forge was built for this, and for my setup it's very much worth the money. Git-based deployment, multiple providers, 1-click Lets-Encrypt SSL, etc.

are you wasting bandwidth just for the hell of it?
you know that cookie is sent with every single request?

What are you attacking us for? We're Redditors just like you.

This is not a face recognition package, that's an api wrapper package for face recognition service. You got me excited there for a second...

I don't have a .env file for my elastic beanstalk environment. I just put in all the environment variables in the Software Configuration panel in the elastic beanstalk settings. So you'll have your dev environment variables for your dev elastic beanstalk environment, and the same for prod.

Elastic beanstalk is pretty easy once you get the configuration all set up. For me to deploy a new version I just commit everything to git, do an eb use <environment_name> and then eb deploy and my new version is up.

I only really use the eb cli and then the aws console whenever I need to.

Laravel is looking for a foreign id based on the name of the relation. So since it's role_id in your table, not roles_id, only the first one works.

1. Permissions / Roles

Laravel's built in authentication and authorization is very good. I wouldn't use a third party package.

2. Packages

One off the top of my head would be something like Laracogs.

3. Overriding

In PHP you can simply extend the class and write your own method with the exact same name.

For example, look at this controller: https://github.com/laravel/laravel/blob/master/app/Http/Controllers/Auth/LoginController.php

It implements the trait Illuminate\Foundation\Auth\AuthenticatesUsers which has the login logic. If you wanted to write your own you can simply override the methods by using your own in that class with the same name.

I'd highly recommend getting up to date with Composer and namespacing before diving into Laravel.

Also check out Laracasts

Sorry, but that was a pretty terrible article. You don't cite any sources for these "best practises," or even explain why you believe them to be best. Lots of English mistakes. (No space between sentences is a huge pet peeve of mine!) Much of the advice isn't Laravel-specific, and some is downright wrong. It comes across more like an introduction to Laravel than an actual best practices guide.

You should try voyager!

Typically have a big launch around laracon :) Either just before or just after.

sudo -s chmod 777 -R $path/storage

That's a big nono. I would read this discussion for a more secure approach: https://laracasts.com/discuss/channels/general-discussion/laravel-framework-file-permission-security

To answer parts of your question in detail:

queue:restart

queue:restart will signal the workers to stop. Technically, it will set a specific cache key that the worker checks after every job and if so, will simply exit. It is the task of the watcher (i.e. supervisord) to actually restart the worker.

How does one gracefully tell the daemon to shutdown without a kill -9 or a pkill?

When the worker receives a SIGTERM it will set an internal flag and, once the current job finishes (or: there is none) and the flag is seen, it will stop.

Note: supervisord is a bit weird in that regard. If the worker does not exit after default 60s, supervisord will SIGKILL the worker. It's possible to increase this timeout but in practice it didn't work properly and my workers still received SIGKILL.

This wasn't yet a real problem because none of my workers take longer then a few seconds to process but it is something to keep in my mind. This is clearly a supervisor limitation but I don't know an alternative.

I'm also using Resque (vie CakeResque) in production and it has some properties which are better: - the aforementioned stop problem does not exist in that way. The problem is reverted: worker are never SIGKILLed, only SIGTERMd and thus may run longer than expected (i.e. slow network, faulty logic, etc.). A job should always be able to be retried but in practice a job may be complex and if it is SIGKILL in the middle, this may be undesired (talking about Laravel here now). - interop is better: good luck trying to enqueue job from the outside in Laravel. Due to the way the worker information is serialized, this is annoying. Works much easier in Resque because the format is simpler.

tl;dw ?

Budum Tss

src composer.json readme.md changelog.md LICENSE.txt .gitignore

Then in your src directory have the required directories from the following:

models controllers views config migrations

Some keep the above directories outside the src dir & some inside, it depends on you.

You need to hard reload your page using CTRL+Shift+R shortuct. Above mentioned keyboard shortcut will work on both windows and mac.

Alex Garret made an amazing series for codecourse covering exactly what you asked and a lot more called Vue Laravel SPA: https://www.codecourse.com/lessons/vue-laravel-spa

It's a pro restricted course, but only costs $5. Highly recommend codecourse for Laravel, PHP, Vue, Slim and more videos and tutorials.

Looks good to me, I would like to see presented at the fair.

Also I would like to think Laraman is Taylor's alter ego.

He wooshes in wearing red spandex and a cape with the Laravel logo on his chest. Always there to quickly help programmers in distress.

There's a utility, available on npm, called forever. Give that a go.

Is it webscale?

I'll stick with the tried and true databases like MySQL or PostgreSQL

Are you registering your dependencies in your composer.json?

If you're within a custom form request, you could store the custom error as a property on the class and then hook into the protected formatErrors method to pass it back out.

EDIT: On second thoughts, if you're using the after hook, could you not just do $validator->errors()->add('duplicate', $otherEmailOrWhatever);

https://laravel.com/docs/5.4/validation#after-validation-hook

You can use the pluck method

Have a watch here - https://www.youtube.com/watch?v=oZAVt5ITTWo. The guy sets up the same thing from start to finish. Disclaimer: he talks a lot.

I'll install spark tomorrow and reply with any caveats you need to be aware of for setting up spark for use with laragon.

The debugbar has helped me figure errors out a little faster. Might be a good addition to your dev environment. Only current caveat for me is BrowserSync seems to break it.

https://github.com/barryvdh/laravel-debugbar

Why not just correct all the urls to point to the original images from compiled css?

The resources directory (where I assume you're storing your images) is not publicly accessible. Or at least it shouldn't be if you've configured your server correctly. The images must be copied to the public directory so they can be served properly.

There's also the opportunity to do some processing on images like resizing, optimizing, etc. before they are copied over.

Models

The first thing is to shake off the idea that MVC means three different class types. "M" in MVC doesn't mean data models like User or Post or Article. "M" in MVC means "The Model" - aka the entire domain layer of your application. It's unfortunate that ORM entity data models are named what they are, because it leads to confusion. They are categorically NOT what "M" in "MVC" means. At all.

The "Model" in MVC can be made up of any number of different classes necessary to model the behavior and state of your domain. That Model can include specific entity/data models like a Post class or an Article class, services, validators, or anything else you might need, but the idea is that it's a layer, not a type of class. So in reality, almost everything should go into "The Model".

If you're asking what should go into your more specific data models that represent entities like Post or Article or what have you, the answer is typically whatever is most relevant to them. Those objects should tell you about themselves, validate their state, and control how their own data & state gets mutated, but nothing else. They should not manage or manipulate other entities, and should not be dumping grounds for functions/methods that have nothing to do with their own data and state.

Any operation that involves updating multiple entities/data models, should be done via another class with a well defined responsibility. You will want to avoid to creating generic service classes (like UserService) that become dumping grounds for functions and methods. That's not what good object-oriented programming is. It's good practice to deliberately avoid using generic catch-all words like Service and Manager in your class names. You want classes to have specific responsibilities.

Controllers

Unlike "M" in MVC, Controllers aren't just a layer - they are indeed a specific type of class with a specific responsibility:

1. Accept the request object
2. Call the appropriate part(s) of the Model to do heavy lifting (fetch data, store data, manipulate data, validate data etc...)
3. Return a response to the browser with the results of that model call

That is literally all they should. The challenge comes in deciding how much they should utilize the Model. A given controller action might need to perform several steps. Take registration for example: validate the request / form, create a new user, send a welcome email, and return a redirect to /welcome or /profile or what have you. Different parts of the Model can do each of those individual actions, but do you let the controller glue those individual pieces together, or do you just put that stuff into a dedicated class inside of the Model and just call that from the controller? Honestly, it really depends. If the whole operation happens in a lot of places and needs to be re-used, then encapsulated it somewhere in the Model. If it doesn't, then just create that procedure right there in the controller, calling various bits of the Model as needed. Controllers and controller actions are easy to test, so it's fine if you want to "glue" bits of the Model together right there in the controller. This isn't very "pure", but it's practical, and practical is what ships software so....

Your Specific Examples

I know you know your forums "model" is doing far too much, but I just want to go through a quick exercise with one of the methods:

Take your mainPage() method for example. What you're really doing there is fetching the data that would be describe a board index - a listing of forums, grouped by category. But all you're doing is returning an unstructured array of that data. Later on, something is going to take that data, and actually assemble it into a view. So if we were following OO principles, you might want to consider that function an entire class unto itself - a BoardIndexData, which can have various methods like ->getCategories(), ->getForums(), and ->getTopicData(). But you also probably want a way of assembling the individual bits of that data into a useful structure that a template can just do some dumb rendering of. So in addition, you probably want something like aBoardIndex` class that doesn't do any data fetching, but rather, assembles forum index data into a useful nested structure. So you could do something like:

$boardIndex = new BoardIndex($categories, $forums, $topicData);

Then in a view template, just do something like:

@foreach($boardIndex->buildTree() as $category)
     <h2>{{ $category->name }}</h2>
      @foreach($category->forums as $forum)
            <a href="...">{{ $forum->name }}</a> {{ $forum->total_topics }} {{ $forum->last_post_author->name }} // etc....
      @endforeach
@endforeach

Why do something like this? Because now BoardIndex contains the logic necessary for assembling formerly unrelated bits of data that can be fetched anywhere. You can create N-number of different board indexes just by passing in different categories/forums/topicData. But maybe this split isn't necessarily the right way to go - it really depends a lot on your application. However, the general idea is that you don't want to treat that Forums class as a dumping ground. Concepts like board index, forums, topics, threads, pings, posts, marking topics as read etc.. all of those are distinct things that should each have their own classes or sets of classes modeling them.

Your Specific Questions

processThread question

So the first issue is the name. What does "processThread" mean? From looking at the function, you're actually creating a new thread. Along the way, you're doing authorization checks, validation of input, the actual database insertion, sending out a notification, flashing session errors, and creating a redirect which you then return. But generally, the domain action you're performing is the creation of a new thread. So I would rename the method to be more clear and explicit: createNewThread(...)

You probably do want this to encapsulate data fetching that it needs, as well as do appropriate validation. So yes, it should be grabbing the topic, and the controller should only pass in the data it gets from the request object. However, notions like sessions and redirects are typically NOT part of the Model's responsibility, so that should not be here. What you should be doing is returning a kind of ServiceResponse object that includes the newly created object (or at least it's ID), a status code, and any error messages. You'd then let the controller decide what to do with this response object. So it might be something like this in the controller

 $serviceResponse = $this->forums->createNewThread(...data from request...)

 if ($serviceResponse->ok()) {
    return redirect('/forums/thread/'.$serviceResponse->data->id);
 } else {
    Session::flash('errors', $serviceResponse->errors);
    Request::flash();
    return redirect('/forums/create/'.$topicId);
 }

If you find yourself doing that pattern a lot, you can wrap all of the session/flashing stuff in its own utility class or even just stick it in a method in the parent controller and call this->redirectWithErrors('/url/to/go/to', $serviceResponse->errors)

validation question

I think the validation should live closest to where it is most relevant, which is in the method itself. You can delegate out to a dedicated validation class if there is a lot of complex validation to be done, but you definitely want to at least call that validation from within that method. The method itself should protect itself from bad data, which means validation should either be done in that method, or called from that method. Otherwise, you could accidentally call that method without doing validation beforehand, and now your Model is in a bad state.

redirect

Definitely do redirect in the controller. Controllers manage user flow, and redirection is user flow.

bonus question

Why not pass that data into the view directly? You shouldn't have to do static calls from a view ever, because you can always just pass that data into the view itself.

Hire a guy.

You can always use service providers for this, then simply inject them in the code you need them in. People keep forgetting that this is one of the most powerful "features" of Laravel.

Another option, assuming this is something generic and de-coupled from the project, would be to create your own package and then installing it.

This is what I do:

$params = Request::all();
//unset some that shouldn't go on
$model = Model::findOrNew($primKey);
$model->fill($params);
$model->save();

My guess is that with each new requests the CSRF is refreshed because the driver is an array. So it's not persistent per new flow of request... not sure when that array is refreshed in the unittest flow under the laravel hood though

I did something like this not that long ago. We allow users to enter anything they want to search such as "This One Guy".

The search would instead of "weight" results, it would score the results depending on various items. Such as a full word search ("this one guy") or single word searches ("one","guy"). I omitted common words in the single search as we didn't want them being scored in.

In the end I just sorted by the score, and since I was dealing with multiple tables I stored everything into a collection and in the end I took my results (id's, points) and used a whereIn() to quickly query the information I needed from my collection.

might not be the best but took what was our original search from 10s down to 3s on the same search query.

What does the user model look like? Is it extending the default user class (aliased as Authorizable by default). If not have you made sure to include the 'Illuminate\Foundation\Auth\Access\Authorizable' trait?

I use Laravel Passport to return a bearer token to the front end upon successful auth. Then save it into local storage for subsequent use.

Just use the /oauth/token endpoint to pass the proper credentials, which can be found in the docs.

From here.

mix.sass('resources/assets/sass/app.scss', 'css', {
    includePaths: ['node_modules']
});

As is typical in database access with frameworks, Laravel makes use of the Adapter pattern to streamline a single API for all database access. So calling $table->dropColumn() works across all database providers you might want (myqsl, pgsql, sqlite), but the actual implementation on the backend may differ.

You won't have issues with the supported APIs, but sometimes you may run into an issue where the Adapter doesn't support a specific database feature. As an example, Laravel doesn't have great support for all pgsql features that are nonstandard. (As example, I believe SchemaBuilder doesn't support geometry columns)

Why use pgsql? It has a lot of extra features, but honestly, the only time I would definitely use it over mysql is if I needed to do spatial/geometry queries. It really excels at that through its Postgis extension.

I also really enjoy some of the extras in pgsql, like working with time formats and functions available for generating time series. I've had issues with pgsql GUIs not working or being outdated, which sucks: you won't find a phpmyadmin clone. I now only use PHPStorm's database layer, as pgadmin isn't amazing, and phppgadmin gives me a white screen of death (and maintainers seemed to have stopped supporting it, will not respond over Github)

I'd recommend reading some articles on the neater features of postgrseql, and doing a project in both for fun. The project you do with pgsql, try to implement features that mysql doesn't have so you can form your own opinions :-)

Why are you caching 95% of your queries? Surely that's an over optimization - focus on proper indexes first. And if your db really is that slow, look into ElasticSearch for faster db lookups.

Note: I never developed with React so my knowledge of it is minimal.

Job-wise: Are you aiming for a job-hop? Or a promotion/change at your current company?

If the later then learning the tech used by your company could help you become more valuable to your existent employer.

If the former, then I'd suggest to research the job market around the area you wish you work at, and go for something that's asked for a lot. In my country for example dev agencies have started a somewhat rapid migration from WordPress to Laravel, so being a Laravel dev is making me more valuable atm when there aren't that many around.

Knowledge-wise: Understanding more from what's happening behind the scenes makes you better and quicker at spotting and avoiding problems, and is very beneficial in the long run.

In this case, learning vanilla PHP (there's a course on Laracasts) and how servers work might be a lot more useful than learning a framework.

But I'll give a slightly diff advise. Learning UI/UX design, at least basics, would make you a better front end dev. Having insight into user behaviors and design best practices would enable you to improve user experience.

I hope that helps you a bit, good luck with your career ☺ .

I don't know why you think it feels "awkward". In a normal setup you are sending to the "phone_number" field, not the User. It simply lives on the User model, but it could live on any model you want.

I haven't used the facade like this before, didn't realize it would work like that. I would just get a collection of PhoneNumbers and ->map them to $phone->notify(....)

The version of phpunit required by Laravel is 5.7, so I would start by not using your separate phpunit, instead use laravels already required package. Your install should have this in require-dev: "phpunit/phpunit": "~5.7"

So simply use vendor/phpunit/phpunit or where the bin would be

First off I recommend that you work on locally on your computer. Not over FTP.

Git has nothing to do with saving your files and nothing to do with incorporating your changes on the server.

All that git does is keeps a parallel history of the changes that you make. You decide when to take the "snapshots" (commits).

The basic workflow goes something like this:

1. Edit a file or group of files to get the desired result. Saving changes as you normally would.

2. Add only the files you need for a particular feature to the staging area using git add.

3. Commit those changes

A few tips:

A big goal of git is to keep an organized history of your changes. This is why you want to keep commits separated. That way you going back to an old change won't break new features that you've added since.

For example, if you're finishing coding awesome-slider feature but you also make some other changes for photo-gallery feature. Only add and commit the completed awesome-slider feature. Then once photo gallery is complete add and commit that separately.

What you don't want to do is add both features as one commit. Or worse, add a completed awesome-slider feature with a half completed photo-gallery. Otherwise if you screw something up later building responsive-menu and have to go back you don't end up with a complete awesome-slider and a half complete photo-gallery.

My limited understanding of APIs led me to believe that they should be "stateless" which means they don't have sessions associated with them, and tokens are instead used to authorize the user. API keys could also be used to load/persist per user settings, but that's not the same as using a session.

Why do you need to use the session in your API? If it's just for storing some customer browsing data, like a shopping cart, then I would put that in the web middleware routes. If it's needed for an actual API function, then there might be something about the way you're trying to write the API that could be improved to avoid using the session at all?

Environemnt: I've used Vagrant, but most recently I've started serving my dev projects locally from php (php artisan serve) until I have a reason to do otherwise (and usually don't).

IDE: I was an a Sublime2 fan until I went 4k and the lack of scaling tabs killed me. I tried a few editors and absolutely fell in love with an unlikely candidate: MS Visual Code. I've been using it for months now and it just keeps getting better and better. I recommend giving it a test drive.

For anybody that reads this, here's a solution I came up with:

Using the same approach as SymfonyConsoleLogger, I created a console logger of my own.

I created a base Logger class within App\Console, this has a bind() method, which accepts the current $cmd being ran. I have registered this class into Laravel's resolver under 'console_logger'. It just does a __call map on $cmd if it's set.

I then created a ConsoleLogHandler which is stacked into the Monolog Stack. I use a slight modified SymfonyConsoleLogger verbosity and level mapper. When write() is called, I resolve 'console_logger' and call the passed a ->$level map to the to the object.

To handle info() verbosity: I pass in an array with 'verbosity'. My console_logger will resolve that to the proper verbosity:

Log::info(sprintf('[%s] SQL Query: %s - params: %s', $service->serviceName(), $sql->sql,
                json_encode($sql->bindings)), ['verbosity' => OutputInterface::VERBOSITY_DEBUG]);

This will call ->info() on command with verbosity of DEBUG. verbosity is safely ignored by other log handlers in the stack.

Concrete itself is built using a large number of Laravel's classes. Some of them are referenced directly and some of them are customized. Here is a good start:

https://github.com/concrete5/concrete5/search?utf8=%E2%9C%93&q=Illuminate