radbonev

@blomdahldaniel

I ended up setting a sub-domain on forge and cloned the phpmyadmin GitHub repo.

@bashy , Thank you for your help!

@fideloper and @noeldiaz there are no errors in the /var/log/nginx/default-error.log file.

I will give adminer a try. As long as it covers the phpmyadmin feature set I should be fine!

@fideloper Sorry about that!

I've followed that guide: https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-phpmyadmin-with-nginx-on-an-ubuntu-14-04-server

When, I try to open http://domain.com/phpmyadmin it goes to 404, which is understandable. I guess, nginx doesn't see that it needs to include phpmyadmin.

Hello,

I am trying to setup a phpMyAdmin to work on Forge; however, it doesn't seem to work. I've tried to set it up as a normal LEMP, but it's not working. Is there anything specific that I need to do for forge?

I've already googled, but there's no answers.

Thank you in advance!

There are couple of benefits:

• There is a common standard between all libraries; therefore, you don't have to worry how to include a specific library, thus, a composer package.
• Composer will figure out the dependencies of your dependencies and autoload them.
• If you have complex folder structure and you want to move things around that would be painful, where in PSR-4 you would just have to point to the new root folder of the namespace.
• You don't have to worry about the order of the classes (because order matters if you do it manually).
• The autoloading of composer tends to "optimize" the performance by compiling (more like concatenating) the most used classes down into one file.

@Ruffles you got my point covered - it is just better for user experience.

@dberry I don't see what was the funny thing about what I've said. I do get that back-end should be front-end agnostic (mobile, browser, etc); moreover, that is how I build my applications.

However, I believe that it is a doable thing to have a better integration between front-end and back-end.

Why did node.js become so popular (rather than performance)?

People noticed that they have been writing the same code over and over again for front-end and back-end! Developers wanted to use one language (for front-end and back-end), so, they can reuse code/modules - that's why browserify was built. It might've not solve the problem entirely, but at least it mitigates some of the related problems!

So, please instead of laughing at my opinion try to come up with better arguments!

@bestmomo

You are right - balancing between client and server side is hard.

For instance, I hate the fact that I repeat my self over and over, when using any JS framework and laravel. My business logic is spread across the 2 layers (client side and server side) and when the business rules alternate you need to apply changes on both sides (de facto, we break the DRY principle). A basic example is validation of a form. You need to check the form on the front-end, as well as, on the back-end.

I am really looking forward for a better collaboration between front-end and back-end frameworks.

@codenihal ,

I would say that you check out laracasts' videos on React.js Jeffrey is about the show us how to use it with laravel.

Alternatively, you can use angular.js. Sites like forge.laravel.com and envoyer.io are heavily based on angular.js + laravel.

Possibly.

However, I am more prone to think that a file got corrupted.

Hello @dmcglone ,

Delete the vendors folder and run composer install.

Hello guys,

I've ran into a strange situations with migrations and environments. I am pretty sure that it is something silly.

So, I have my .env.cept file. I have APP_ENV=cept in it.

However, when I run

php artisan migrate --env=cept

It returns "Nothing to migrate". Bottom line is that it didn't even touch the database.

Moreover, I've noticed that, even if I try:

php artisan migrate --env=jebrewsshshhshs

It still says "Nothing to migrate"

I know that I can use the --database flag, however, I am using two databases, and I need to run it through the --env.

Any thoughts?

Thanks!

You can check the Build an Activity Feed series, I know it's not exactly what you'd asked for, but it's pretty close:

https://laracasts.com/lessons/build-an-activity-feed-in-laravel

@emiri Well, you'd better get that server fixed.

As a temporarily solution you can can switch to another Cache drive - file for instance!

Well, null is a non-object and that's why PHP is mad.

Check your database and see if you have a row with a primary key (id) of 30.

@coolmatty - well, we should probably stick to the right terminology :)

However, I don't think that Envoyer.io should take care of those files, but in case you have to - you can achieve great results with 2 lines of bash code. I think that the default settings will get you up an running pretty fast, I don't see any reason why would we change that.

@coolmatty , I am not sure what you meant by "you're really not supposed to store your assets"; however, you are, in fact, supposed to do that!

Let's take a step back - Did you mean some sort of files that are not related with the code base of your project (e.g. users' profile pictures). If that's the case, I would agree that they should not be in your git repository; however, they are not consider assets. Anyhow, every single piece that is part of your domain logic and/or design should be in your git repository, that includes css, js, and images.

If you were talking about images/documents/files.. (that are not part of your design and logic) then, you'd better use a CDN or flysystem's API to manage those files (as long as we are talking about larger project). If your project is smaller, you can easily set up a symlink that points to another folder (that has the files) that is not part of the git repository.

Anyhow, I think that the price is justified! Let's think for a second - the average hourly rate for developers in US is $30-$40 per hour. If you have to spent 3 hours a year to write deployment scripts and manage deployments manually - you're already losing money because you could've used a tool that is proven to be working.

I've noticed that people complain that the price is too much if you have 1 project. I wouldn't agree more as long as that project is your blog or another small project; however, those project don't even need a deployment tool!

I am happy that we have envoyer.io !!

@kazehaya ,

I am sorry, I think Taylor deprecated the Crypt facade, but you can still access the class, like this:

$crypt = Illuminate\Encryption\Encrypter($key) //key should be the encryption key
//or, you can set the key like this

$crypt->setKey($key);

$crypt->encrypt($value)
$crypt->decrypt($encryptedValue);

//You can change the cipher like this

$crypt->setCipher($cipherAlgorithm);

In terms of security, I've seen people run a cronjob every 24 hours and change all the passwords. Basically, they:

• Generate a new random string
• Encrypt it
• Change DB's password
• Update the lookup table (with the encrypted password)

Some go even further and change the encryption key, but I don't think that you need such security.

Hello @kazehaya ,

$encryption !== $hashing (It seemed that you used them in them as synonyms)

In short, with encryption, you can encrypt/decrypt the results from the database using a key. However, with the hash is a one-way street, you cannot dehash a hashed string and see the raw value. Importantly, hashing becomes irrelevant in your case because it's the same as storing raw-string passwords.

Therefore, encryption is more secured because if someone hacks you they will need the key to decrypt the passwords.

you can do stuff like:

$encrypted = Crypt::encrypt('password');
//persist in the database

//retrieve from database
$decrypt = Crypt:decrypt($encrypt);

I hope it helps :)

Hello @websanova ,

I guess you've noticed that Taylor deleted the models folders. You would want to group your related classes in folders, so you might have this kind of structure. (That's what I do):

app
    ProjectName
        User
            User.php
            UserObserver.php
            Repository
                EloquentUserRepository.php  
                ...
            Contracts
                UserRepository.php
                ...
            ...

Note that this is for larger projects, where you would want to decouple your application as much as possible.

For smaller applications (where your file/folder structure is not so nested) you can create an Observers folder in your app directory. (I've never gone that path though)

Try to figure out which approach feels more natural for your project.

@philthathril

You can, I think that the other way is a little bit more clean (that's what you've asked for).

@leelanarasimha

I don't know what are the configurations of your godaddy server, so, I cannot tell you.

I recommend that you read more about laravel homestead and laravel forge. Those two are great tools that will save your life on the long run. Check them out and if you have questions you can find us here :)

@leelanarasimha

The following excerpt is from laravel's documentation, however, I've never tested it:

If the .htaccess file that ships with Laravel does not work with your Apache installation, try this one:

Options +FollowSymLinks
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L] 

Link: http://laravel.com/docs/5.0/configuration#pretty-urls

Anyhow, I would strongly recommend that you use laravel homestead!!

The most beneficial thing out of homestead is the fact that it comes preconfigured, with all the goodies that you need to work with laravel. Hence, it gets you up and running extremely fast!

You can watch here how to install it: https://laracasts.com/series/laravel-5-fundamentals/episodes/2

Since, you use Win8, you would need to follow this guide from Sherri Flemings: http://sherriflemings.blogspot.ca/2015/03/laravel-homestead-on-windows-8.html

Hello @philthathril ,

Ideally, you would want to pass the User object as an argument to the command (first, it is more testable; second, it is more reusable).

Anyhow, I believe the best way to do it is if instead of using the mapping command properties option, you pass the command to the dispatch method.

Like:

$this->dispatch(
        new IdeaCommand(Auth::user(), $title, $description)
    // just a small note here: Ideally, you would want to have a command name that tells you what it does in `ubiquitous` language. PublishAnIdeaCommand for instance, or something that tells you more.
);

After that you can just have:

/ command
public function __construct($user, $title, $description)
{
    $this->user_id = $user->id;
    $this->title = $title,
    $this->description = $description;
    ...
}

// or even the handler:
public function handle($command)
{
    //do something, you can access the $user object => $command->user_id
}

If you really think that you want to pass just the $id, that's OK.

However, it is a good practice to inject your dependencies rather than calling Facades deeply from your application.

Usually, I would call facades only in my controllers and my views.

I hope that helps!

Hello @leelanarasimha ,

The multi-parameter route should work perfectly fine.

Do you you homestead? If not what do you use? I have a suspicion that you might use Apache that has bad configurations - if that's the case check out homestead, you're going to love it!

Otherwise, if you are using homestead give us more details about the version of homestead, and other details.

Thanks

@nathanrobjohn

I would suggest that you create some sort of graph that demonstrates the relationships between your main resources (users, portfolios, tickets, invoices, payments, etc).

For instance, 1 user has many tickets (that way, you can easily see the relationship between your models).

After that you could come up with feature list that you would want to include in your first iteration of the app.

Note, do not include all the features that you have in mind because that will only frustrate you!

Usually, I come up with a three column list for my features:

• Must have <-- those are vital features
• Would be great to have <-- those are more of a good to have, but their absence will not hurt
• Might have in next iteration <-- those are just cool ideas, but you're not completely sure that you need them.

After that you could start implementing your features one by one.

Usually, I would start by setting up the route, controller, and the view (it helps me visualize, how I would want the app to function). Once, I am done, I would setup the Models and start working on my business logic (the feature set).

Make sure that you work on only 1 feature at a time, otherwise, you'll mess up! (You have to make sure that your app is extensible, though).

In short:

1. UML diagram

2. Models relationships

3. 3-column feature set

4. Loop through those for any feature:

   1. Route
   2. Controller
   3. View
   4. Model
   5. Business logic

I hope it helps!

@nathanrobjohn you are on the right track.

Usually, I organize the code in a similar fashion. I use 2/3 master layouts (e.g. guest_master, admin_master, user_master). I create 4 folders guest, admin, user, and common. Usually, I fill the common with partials that would be included in multiple levels (e.g. admin and users) partials.

Consider the following file structure an example of an eCommerce website:

admin
    partials
    product
        create.blade.php
        edit.blade.php
        ...
    category
        create.blade.php
        ...
    orders
        dashboard.blade.php
        status.blade.php
        order.blade.php
        ...
users
    partials
        navbar.blade.php
        banner.blade.php
    product
        product_list.blade.php
        product.blade.php
        compare.blade.php
        ...
    cart
        recipient.blade.php
        customer.blade.php
        order_preview.blade.php
        ...
guest
    partials
        navbar.blade.php
        ...
    vendors.blade.php
    customer_support.blade.php
    contact_us.blade.php

common
    partials
        thumb.blade.php
        ...
    login.blade.php
    ... 
errors
emails

Bottom line is, you don't need to branch off so much your folder structure, when your project is fairly small.

Hello @marcelgsantos ,

I am pretty sure that you don't want to use HMVC and you don't want to create a subfolder for every company that you have. Imagine, you have 200 company's you don't want to create 200 app/Api/Company_1... and so on.

First of all, lets look at your routes file.

Route::group(['domain' => 'api.my-site.com'], function()
{

    Route::get('company/{name}', function($name)
    {
        //
    });

});

That way, your application will respond to http://api.your-site.com/company/foobar.

Note: that this is just a suggestion.

Therefore, your folder structure might be something like:

api-mycompany
    App
        Api
            Company
                Exceptions
                Repositories
                Services
                ...
        Http
            Controllers
            Middleware
            Requests
            Kernel.php
            routes.php

Note that I deleted the Models folder!

There's no right way; however, I tried to show you a better approach, if you need further help, you can ask more specific questions :)

I hope I gave you some ideas!

@cbojer ,

I see now, sorry for the misunderstanding. I like @toniperic's idea, just maybe, a separate table is better.

Hello @kaju74 ,

maybe you would need to specify charset with your response, try something like:

return Response::json(array(
            'message' => 'Vielen Dank. Sie hören von uns!'
        ), 200)->header('charset', 'utf-8');

Hello @cbojer ,

It seems that the feature itself is simple and you're right that you're over-complicating it.

I will point out an extremely obvious and simple solution.

//on first step
Session::put('steps.personal_info', true);
//on second step
Session::put('steps.credit_card', true);

After that, you can use the same middleware and check and match the step with the URL. You can validate that they can proceed with the next step, or redirect them back.

I hope that helps. If it doesn't give us more details about the nature of the project, so we can be more helpful!

@spaceemotion , you can do things like:

Route::group(['prefix' => 'user', 
              'middleware' => ['auth', 'acl'],
              'is' => 'administrator',
              'protect_alias' => 'user'], 
function () {
    Route::resource('user', 'UsersController');
});

It's still a good way of doing it, you just need to wrap them in a Route::group()

Hello @ryanmortier ,

I am using the JSONView extension for Chrome and I believe that Jeffrey is using the same.

https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=en

Hey @spaceemotion , there's a great package by kodeine:

https://github.com/kodeine/laravel-acl

that would do the job!

I'll include a snippet:

Route::get('/dashboard', [
    'uses'        => 'DashboardController@index',
    'middleware'   => ['auth', 'acl'],
    'is'           => 'administrator',
    'can'          => 'view.dashboard'
]);

I find it extremely readable and understandable!

@yayuj Keep it simple, do not try to over-complicate. I believe that the key factor in your situation is the communication between you and your client. MVC should do the work. The other architecture styles are for huge applications, most of the e-commerce websites do not require that much of abstraction.

Honestly, I can't think of a nicer way of doing sometimes:

public function store(Request $request)
{
    $v = Validator::make($request->all(), [
        'title' => 'required',
    ]);

    $v->sometimes('leader', 'required', function($input){
        return ($input->groupSize >= 10);
    });

    if ($v->fails())
    {
        // DO Something...
    }

}

I know it's not that good of a practice to have it in your controller, but it's a trade-off that you might want to consider.

I would be glad if someone else give a little bit of advice here.

@yayuj, Sure, you can start pure MVC project and have it up and running. Eventually, by struggling, you'll find that there are solutions that would help them. If you don't struggle with your code, that means that you're probably fine and you don't need any sort of design paradigms -- and that's alright.

Engineers have a simple rule called KISS: Keep It Simple Stupid.

We as software engineers don't follow that rule, we always tend to show how smart we are, how many paradigms and patterns we know. That is WRONG!

Keep It Simple Stupid!!

I think that MVC is a good starting point for an inexperienced developers because MVC (in its pure nature) has only 3 levels Models, Views, and Controllers. By the time that developer gain some knowledge, s/he will be able to pick up on more advanced topics, patterns, and paradigms. @yayuj , your completely right that MVC does not solve all the problems. Today, we have wide-range of problems that are interrelated with performance, security, scalability, couple/decoupling external services, testability (I like that word), and so on.

Still, I believe that most of the application architecture styles derive from MVC. Therefore, everyone should know MVC and later fit the projects requirements into the right architecture.

I am watching a presentation on Flux right now; however, as I see Flux is beneficial, when you have hundreds of Models.

@JoshWegener , in that case, you should try something like:

public function validate(array $formData)
{
    $this->validation = $this->validator->make($formData, $this->getValidationRules());

    $this->validator->sometimes('ipaddress', 'ssh', function($formData)
    {
        return $formData->enabled;
    });

    if ($this->validation->fails()) {
        throw new FormValidationException('Validation failed', $this->getValidationErrors());
    }

    return true;
}

Anyhow, I recommend that you transfer over to L5

@Ruffles , I don't think that there's a right way to measure how big an app is. I am sure that if there was a formula, we would've know about that. Every application could be looked in two dimensions quantitative and qualitative, when it comes to application size. Bottom line is, that neither of them is exact.

By quantitative I mean things that we can measure:

• lines of code
• #of tables and databases
• people working on it
• hours spent on it
• #servers
• frequency of changing business logic
• people using it

On the other hand we have things that we cannot just measure:

• Complexity of features
• Business rules and business logic
• frequency of changing business logic
• people using it

As you can see, the last two are the same in both because I've had applications that were used by thousands of people daily and still had half-dozen of features. However, there are apps that support hundreds of features and are used by 100 people. Anyhow, I believe that was way too off-topic.

Instead, we should focus on the architectural and design problems and how should we divide our code (that was the main topic).

@JoshWegener , I just noticed that you watched an old video for form validation. In L5, we use Form Requests classes, that would simplify your work a lot, and they come working out of the box.

Check the video here:

https://laracasts.com/series/laravel-5-fundamentals/episodes/12

@Ruffles ,

You are completely right, however, it is still hard to put a line that defines whether an application is consider large or not. In fact, \we do not usually count the #of features and we don't measure their complexity, but we would rather count the lines of code (and it most case, the lines of code are not that relevant, but they give us an idea of the application size) of that app.

Since, I could not come up with better example, I would use the following.

Imagine that you have a form that registers a group of people for an event. However, if the group has more than 10 people, they will have to provide a leader.

So, the way you could tackle that would be something like:

$v->sometimes('leader', 'required', function($input){
    return ($input->groupSize >= 10);
});

That way, you'll ensure that the leader field will be required if and only if the group has of 10 or more people.

I hope that helps!

Although, we (the people) are intelligent and we have large capacity of memory, we encounter difficulties, when it comes to absorbing large amounts of poorly structured information. For instance, if I give you a phone number like this 1724555692 your brain will have difficulty to parse that information. It will find it even difficult to recognize that this is a phone number, not some random digits. Eventually, some psychologists found out that people’s brain has a fascinating ability to remember information that is structured and chunked into small pieces; importantly, this is why we use the following notation (xxx-xxx-xxxx), when it comes to phone numbers. By a glance or two, you can analyze and remember then phone number. You would easily notice that it is a phone number, you'll recognize the area code and other details.

Back to MVC.

Why do we use MVC?

MVC is a “notation”, a way to structure and organize our code, so it’s easier to read, analyze, and learn. If you have an application that is sort of well-structured, by a glance at your root directory, the controllers’ directory, and the models’ directory, a person should be able to tell the most basic stuff about your application and its business logic. That is similar to the way we can tell the area code right away, when the phone number is notated properly.

Why there's still frameworks that uses MVC?

Honestly, there’s nothing wrong with MVC; however, if we have larger applications just MVC is not enough. What do I mean by “it’s not enough”? People are asking questions like – “Where should I put my business logic” or “Where should I put my form validation” and so on. In fact, if you have a small app you would be fine to put it all in your model, or even in your controller. However, when we have to build large robust applications and our models and controllers are cluttered with all sorts of functionalities and responsibilities, we break one of the most important software-architecture rules – separation of concerns (I am not even mentioning the SOLID principles). However, that is not the problem. The problem is that our code is not readable anymore. A new guy would have to spend days to figure out all the responsibilities of a singular controller. I will use myself as an example, I’d inherited a project that had over a dozen of controllers that were more than 2000+ of code. Anyhow, the developers as some sort of intelligent people noticed that there are some patterns that seem to reoccur in their code. They decided to extract those logical units into their own things. Today, we can talk about a couple of design patterns, e.g. Repository Pattern, Command Bus Pattern, Event Pattern, and others. Luckily, we can easily use those three in our laravel applications.

Do we have to use those patterns? Depends how large your application is.

However, I find it difficult to define large application. Some people consider 2,000 lines of code as a large application. On the other hand, some people consider 100,000+ lines of code large application. I believe that the best way to see whether you’ll need something more than MVC is to screw up few projects. Than you can reevaluate yourself. Then and only then, you would know where you would’ve used a shortcut, a pattern, or something else.

That is the best way to learn.

Many people try to use all these goodies (like command bus and so on), however, instead of benefiting from them, they experience bad time. Why? They will chunk their 1000-lines of code application into thousands of commands, repositories, and so on.

Some people talk about the MOVE (model operation view event) architecture-paradigm; however, I see MOVE paradigm as MVC with commands and events; there’s nothing more special about it.

I know, I haven’t answered all the questions; however, I believe that the unanswered ones are easy to google.I will share some links, however, keep in mind that most of the information is covered on Laracasts.

(Note that the first two, are not things I recommend to beginners, because it will harm them more then it will help them).

If you’re interested in MOVE check this link out: https://cirw.in/blog/time-to-move-on

Another paradigm that became popular is the hexagonal-architecture: http://fideloper.com/hexagonal-architecture

Great articles about command bus from Shawn McCool and Matt Stauffer: http://shawnmc.cool/command-bus https://mattstauffer.co/blog/laravel-5.0-commands-and-handlers

Repository Pattern:

http://shawnmc.cool/the-repository-pattern

http://stackoverflow.com/questions/16176990/proper-repository-pattern-design-in-php

Hello @Codeskills ,

For how many connections (users) are we talking about?

If it is only 4-5 then you can go with (config/database.php) and add them manually.

However, I don't think that's your case. Therefore, you can have something like:

Config::set('database.connections', [
    'mysql' => [
        'driver'    => 'mysql',
        'host'      => env('DB_HOST', 'localhost'),
        'database'  => env('DB_DATABASE', 'forge'),
        'username'  => env('DB_USERNAME', 'forge'),
        'password'  => env('DB_PASSWORD', ''),
        'charset'   => 'utf8',
        'collation' => 'utf8_unicode_ci',
        'prefix'    => '',
        'strict'    => false,
    ],
    'dynamic' => [
        'driver'    => 'mysql',
        'host'      => Dynamic::getHost(),
        'database'  => Dynamic::getDB(),
        'username'  => Dynamic::getUsername(),
        'password'  => Dynamic::getPassword(),
        'charset'   => 'utf8',
        'collation' => 'utf8_unicode_ci',
        'prefix'    => '',
        'strict'    => false,
    ]
]);

Where Dynamic might be a Eloquent model that will return the database details.

Later, you can have your eloquent models use the new connection like this:

class User extends Eloquent {
    protected $connection = 'dynamic';
}

Note, that I've persisted the initial database.

Anyway, I hope this works for you!

It does totally make sense and that's what you need - implicit controller.

Try the example I showed you and you will see it works! If it doesn't I will help you!

{one?}/{two?} and so on, are are just not-required parameters.

Thanks :)

@elimantara in that case, you can go with implicit controllers.

Route::controller('\', 'PagesController');

Now, every request that comes to your server will go to PagesController and it will look for the method associated with it. For instance:

/about => will look up for PagesController@getAbout

Anyhow, It is my personal belief that the routes file should have more code than the controller itself.

What do you mean by: "But, I'm not sure how to handle hard coded pages."?

@Ozan , one more thing if you have to do multiple requests, you might need to pass the csrf_token back to the client (browser) along with the json response (for instance). That way, you can send a second/third request.

$.ajax({
    type: "POST",
    url: "/url",
    data: {
        'argument': some_val,
        '_token': csrf_token
    },
    success: function(json){
        csrf_token = json.csrf_token
    }
});

or something similar.

I hope it makes sense to you.

@Ozan , you might want to checkout Jeffrey Way's PHP vars to JavaScript vars package. You can easily pass the CSRF token as a JavaScript variable and reuse it.

I believe that is one of the most efficient ways because you don't want to generate JS with PHP (it is bad practice).

Anyhow, you can check the package here: https://github.com/laracasts/PHP-Vars-To-Js-Transformer

In terms of code, you can have something like..., in your controller;

JavaScript::put(['csrf_token' => csrf_token()];

Later, you can access the csrf_token variable as a variable in your JavaScript.

It will look like this:

$.ajax({
    type: "POST",
    url: "/url",
    data: {
        'argument': some_val,
        '_token': csrf_token
    }
});

I hope it works for you!

Hi @elimantara , this approach that you've chosen is not that good. You would want to wrap certain resource (unit) in the same controller. Therefore, your blog cannot be in the same controller as your feedback is.

So, you can wrap all your static pages in the same controller. For instance,

Route::get('/home', 'PagesController@home');
Route::get('/tour', 'PagesController@tour');
Route::get('/about', 'PagesController@about');

You might want to have one controller for your feedback mainly because it differs in terms of responsibilities. Therefore, your routes would look like:

Route::get('/feedback', 'FeedbackController@create');
Route::post('/feedback', 'FeedbackController@store');

Your blog is completely different story because you might have posts, comments, and so on. However, to keep it simple you might go with something like:

Route::get('/blog/{post}', 'PostController@show');

To wrap up, your way is not completely wrong and it will work, however, the whole purpose of having different controllers is to keep everything organized and clean. The examples above are just jump-off ideas. If your website is extremely small and it has only a few pages then you can go with one controller.

Give us more insight about what you're trying to accomplish and how large the application should be (we don't want to over-complicate things).

I will play with that later today. If you are sure that this is some sort of bug you can open a issue on github.

@sachinagarwal , do you use the same database (for testing and local), would you paste both .env files?

If you happen to use the same database for "local" and "testing" it will result in "Nothing to Migrate"