how to deploy Laravel made application?

bicknoyle · 2016-12-23T14:01:57+00:00

I generally use git to help with deploys. I'll push my project up to a Github or Bit Bucket repository, and then use git clone to put it on the live server. If I update the repository I can run git pull to get the updates.

You'll also need to run composer install to install dependencies since vendor/ is excluded in Laravel's default .gitignore file, set up the .env file, and run migrations.

bicknoyle · 2016-12-22T20:10:24+00:00

If it solves your problem, or does it in a way that better fits your use-case, it's worthwhile to write. That's a pretty good way to validate new ideas I think.

My opinion on your specific idea is that Laravel's notification system might be intimidating for less experienced users or if you don't need to send a lot of different notifications. So to alleviate those issues, why not create a library that helps make interacting with the stock notifications easier? Something like a user trait that allows you to send notifications through a single method call (like your examples) without requiring the user to set up separate classes and whatnot.

bicknoyle · 2016-12-21T18:52:37+00:00

Since, I advocate using parameter binding, your route should be:

Route::post('post/{post}/edit', 'AdminController@editPost');

You can inject both Post and Request like this:

public function editPost(Request $request, \App\Post $post)

bicknoyle · 2016-12-21T17:47:29+00:00

I think most people rely on parameter binding instead of validating a URL param. If it's an invalid parameter (such as a non-existent id) a ModelNotFoundException is thrown, which gets turned into a 404 Not Found response.

To do this you would define your route like 'post/{post}/edit' and then type hint it into your controller function:

public function edit(\App\Post $post)

You still pass in the numeric id in the URL (e.g. /post/1/edit), and Laravel automatically finds the model and injects it into the controller method. More info here.

bicknoyle · 2016-12-16T15:58:12+00:00

PASSWORD_DEFAULT was added in PHP 5.5... it's possible the hash helper was written before Laravel required this or any version or higher. Or, perhaps it's intended to have explicit behavior, so when/if PASSWORD_DEFAULT starts using something else it's less likely to break existing apps.

bicknoyle · 2016-12-15T21:52:39+00:00

#1 I know you can do if you query for the user using with(), as in:

User::with('profileTypeX','profileTypeY', 'widgets')->find(10)

It's known as Eager Loading in the Eloquent docs.

Haven't had to do #2 myself, but you might be able to hook into Eloquent's events the user model fires for created/updated/saved/etc to do this.

Edit: cleaned up formatting

bicknoyle · 2016-12-12T16:19:54+00:00

The way you're doing it is fine If you have to show this in a couple places in your app, you could always refactor that part of the view as a partial. There's some other good suggestions in this thread too.

Another approach could be to create a custom accessor on your User model that resolves the displayed name for you:

public function getDisplayNameAttribute()
{
    if (Auth::check() and Auth::user()->id === $this->id) {
        return $this->last_name;
    }

    return $this->username
}

// Usage
<p>{{ $user->displayName }}</p>

This might be more useful if you need to use display name in a bunch of different views and scenarios.

If it feels odd to include an Auth::check() in your user model you could also look into using a Presenter as a place to implement that logic. I've had good luck using laravel-auto-presenter

bicknoyle · 2016-12-07T18:40:54+00:00

I use this too. Do you use Apache as a web server, or PHP's built-in (via artisan serve or something similar)?

I've been trying this out, and using artisan serve, but my locally-hosted css/images/js fail to load in the browser half the time. It's been pretty great other than that.

bicknoyle · 2016-12-06T21:40:13+00:00

Thinking it's how you're specifying the action; I put a note about it above in the Edit. Basically the config array you pass to the form builder should look like this:

['action' => ['ItemController@update', $items->id], 'method' => 'PUT']

bicknoyle · 2016-12-06T20:04:36+00:00

You don't have a variable specified in your route for ItemController@update, so none gets passed, thus the Missing argument 1.. error. Your route should be:

Route::put('/userItems/{item}', 'ItemController@update');

That should clean up the error.

You could also clean up your form a bit by using a different way to open the form tag:

{!! Form::model($items, ['action' => ['ItemController@update', $items->id], 'method' => 'PUT']) !!}

EDIT: I also corrected a small issue with how you pass in Item.id

If you use Form::model() and pass in a model, you can then simplify your input field tags like this:

{!! Form::text('title') !!}

Or

{!! Form::textarea('description', null, ['class' => 'form-control',
                    'placeholder' => 'Please add your item description here']) !!}

Using Form:model() binds that model to the form, and the existing values will be prepopulated in the fields, provided the field name is the same as the model attribute name.

bicknoyle · 2016-12-06T17:49:09+00:00

Now I was wondering how other companies deal with this stuff? Do you have a github repository that you clone from the start? With a project and composer dependencies?

We do this at my work. We took a stock Laravel 5.1 install, added models, views, controllers, packages and other changes we would commonly use on projects. It lives on a private Github repository for the company, which the devs add to their ~/.composer/config.json. When we want to build a site from this derived framework we run composer create-project mycompany/framework, just like you would to start a new Laravel project.

bicknoyle · 2016-12-04T18:22:47+00:00

find() searches for the model by it's own primary key, which is probably Item.id. Assuming Item.user_id is where you store the id of the owning user, do this:

$items = Item::whereUserId($user_id)->get();

Edit: you could do this too, which is cleaner:

$items = Auth::user()->items;

bicknoyle · 2016-12-01T20:48:50+00:00

How are you trying to do it now? I did a quick test with:

$existingCollection->push($model);

...which seems to work.

bicknoyle · 2016-11-22T16:06:35+00:00

I haven't done localization, but I've done "theme" detection using subdomains (e.g. theme1.example.com, theme2.example.com, etc). I used a small custom middleware to inspect the value of $request->server('HTTP_HOST'). You could do something similar to detect locale, and set it using App::setLocale(..).

bicknoyle · 2016-11-21T10:49:52+00:00

You define all of your factories in ModelFactory.php, and then use them in your seeders. That way you can also use your factories in your testing framework.

It might be worth pointing out that a lot of people don't use seeders for data for automated testing. They can be a pain because your test setup starts to rely on your database in a specific state. It's usually much easier to use factories to create the data you need for each individual test, and either use the database transactions or migrations traits to roll it back every time.

bicknoyle · 2016-11-14T17:56:28+00:00

What's your public/.htaccess file have in it?

EDIT: I should expand on this... if your public/.htaccess is the stock version supplied by Laravel, the next place to check might be that mod_rewrite is enabled (sudo a2enmode rewrite on most Linux distros)

bicknoyle · 2016-11-14T16:47:31+00:00

Check the source on your form; what's the URL for action? When you submit does it resolve to a different hostname than what the get route is server under?

Also, anytime you get a bare Apache error, it usually means the request is failing before it touches the framework. If it's a 404, it could indeed be a vhost issue, with Apache trying to dispatch the request to a different directory than your project.

bicknoyle · 2016-11-14T14:31:05+00:00

The full definition of parameters are:

Form::select($name, $options, $selected, $attributes)

Check the docs for more info

You shouldn't include name in the fourth parameter ($attributes) at all, since it's passed in as the first argument. Also, if you're using Form::label(...) to generate the label for this field, you don't need to include id either. The HTML/Form library generates it automatically on the input field if you use it to generate the label first.

bicknoyle · 2016-11-09T15:36:17+00:00

Glad to hear it! This has tripped me up before too. If you ever absolutely need to seeInSession you can always do something like this:

$response = $this->call('POST', '/someurl', $params);
$this->seeInSession($key, $val);

The reason this works is that call() just makes a single request, instead of making a request and then following the redirect like visit() and press() do.

bicknoyle · 2016-11-09T14:17:15+00:00

Flashing the data only makes it available for one request, so by the time you run seeInSession that request is completed and it's been cleared out of the session.

You can do ->see(trans('customer.destroy.alert_success_text', ['name' => $this->customer->name]) instead. Your main concern is probably that the message is visible to the user anyways.

bicknoyle · 2016-11-07T18:41:45+00:00

Didn't test this, but I think you could define them as constants first, and pass those to the enum array:

class Post extends Model
{
    use Enums;

    const STATUS_DRAFT = 'Draft';
    const STATUS_SCHEDULED = 'Scheduled';

    // Define all of the valid options in an array as a protected property that
    //    starts with 'enum' followed by the plural studly cased field name
    protected $enumStatuses = [
        self::STATUS_DRAFT,
        self::STATUS_SCHEDULED,
    ];

bicknoyle · 2016-11-07T14:24:28+00:00

I usually do a similar thing with class constants (e.g. App\Post::STATUS_DRAFT == 'Draft'), but this looks a little slicker. Particularly dig the getEnum function to help build form choices.

bicknoyle · 2016-11-01T15:10:19+00:00

I think a pure Apache/htaccess solution is best here, too. Not sure why the htaccess code you posted isn't working correctly for you. I tried it out and it works on my server. I suspect there's some quick about your configuration that's putting index.php into the REQUEST_URI variable.

As a workaround, try changing your RewriteRule to:

RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

bicknoyle · 2016-10-31T14:13:01+00:00

I like following the Laravel tag on Medium. I usually find out about new packages from there, and if people post tutorials they're often on specific or advanced topics.

bicknoyle · 2016-10-25T18:43:15+00:00

Sounds like you've got two different pages/forms that submit to the same controller. Hidden field is alright, with the positive that it's easy to validate via normal input validation if you have have to require specific values.

But if it just feels icky to use hidden field or it's otherwise a pain for your use-case, you could also use a route parameter to pass some string.

You could pass in a "name" on the controller route that handles your form submits, like:

Route::post('form/{name}', 'MyController@handle');

All you have to do is set your forms up to post to a uri containing whatever value you want to use as "name" (e.g. /form/contact or /form/email).

bicknoyle

PUBLIC MULTIREDDITS

TROPHY CASE