What's the difference between enabling Node View (and adding a variant) and creating a new Panel page?

Question

To learn more about Panels, I've been repeatedly traipsing through screencasts by Shane Thomas and Johann Falk. Right now I find myself confused about the distinction between: enabling a copy of node_view so one can add a variant for a content type, and, creating a new panel page for that content type.

Code Karate's screencast series is directed to learning about Panels, but #129 takes a side-step into creating a copy of node_view Page (through Page Manager) to create a variant, selecting by content type. I wonder why Page manager is being used for a tutorial about Panels.

I want a page for a specific content type, but I would like to use a Panel page to get there. How do I do this?

I'm also not clear on what invokes a Panel.

Note: I've read this question/answer by @Letharion about the difference between Page manager and Panels which is a bit too high-level for me at this stage.

Answer 1

Page Manager allows you to intercept existing paths or create new paths in the system.

As the node view path already exists, and you want to change the way it operates depending on some conditions (bundle for instance) you need to enable a copy of node view path in Page Manager, instead of creating a new one (as it already exists you cannot create a new one as it will conflict)

EXAMPLE: For all nodes of bundle type Article, when the user attempts to view such an article, you want to perform some ACTION. So you override the node view path, create a variant that filters on bundle of Article, then perform some ACTION.

The ACTION is pluggable. You can do a redirect for instance. So when the user attempts to view an Article you intercept that, look at some context on the specific article (lets say there is an Entity Reference field to a Basic Page), then redirect to that Page.

Panels has a plugin component for Page Manager. So when your condition to view an Article for instance is satisfied in Page Manager (via your variant), you can select that Panels take over the rendering of the page.

The beauty of Page Manager is that it intercepts the requested page and then makes all kinds of context on that page available, such that you can make decisions (via created variants) on what to do, and when you for instance make the decision to pass the rendering over to Panels, you have all the context available to you. You can even load more context if you wish. On a node you have limited author information available such as the Users uid, but with Page Manager you can request that it pulls in the User entity to make other fields available such as email etc. You can continue to bring in related context in this fashion: think about the case of a node that has an entity relationship to another type of node that has an author (User) that has a taxonomy reference etc. Access to more context is very helpful. Think of the difficulty with a Views Block. It only has access to the menu object's key (node id etc) and url parameters. But in Panels (via Page Manager) you can embed a View Content Pane and pass as much context to it as needed.

SO in essence, the Page Manager - Panel relationship is merely the way by which you decide what paths and what conditions on that paths must be satisfied in order for Panels to take over the rendering with access to lots of context.