Return to Answer

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*/view'] = TRUE;
}

If you notice that this implementation doesn't work when the users are viewing, for example,example.com/node/1, but only when they are viewing example.com/node/1/view, then I would implement the hook using the following code. The first implementation I provided should work, as the "View" tab is the default one, and when users are viewing example.com/node/1, Drupal is really showing example.com/node/1/view.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
  $path['node/*/backlinks'] = FALSE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, if there is a module that does that.
• The node module defines the node editing pages as administrative page only when a checkbox in an administrative page is selected; those pages are already handled.

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $paths['node/*/view'] = TRUE;
}

If you notice that this implementation doesn't work when the users are viewing, for example,example.com/node/1, but only when they are viewing example.com/node/1/view, then I would implement the hook using the following code. The first implementation I provided should work, as the "View" tab is the default one, and when users are viewing example.com/node/1, Drupal is really showing example.com/node/1/view.

function mymodule_admin_paths_alter(&$paths) {
  $paths['node/*'] = TRUE;
  $paths['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $paths['node/*'] = TRUE;
  $paths['node/*/view'] = TRUE;
  $paths['node/*/backlinks'] = FALSE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, if there is a module that does that.
• The node module defines the node editing pages as administrative page only when a checkbox in an administrative page is selected; those pages are already handled.

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*/view'] = TRUE;
}

If you notice that this implementation doesn't work when the users are viewing, for example,example.com/node/1, but only when they are viewing example.com/node/1/view, then I would implement the hook using the following code. The first implementation I provided should work, as the "View" tab is the default one, and when users are viewing example.com/node/1, Drupal is really showing example.com/node/1/view.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
  $path['node/*/backlinks'] = FALSE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, and defining a page as administrative page when its module didn't define that as administrative page doesn't interfere with the permissions applied to that page.
• The node module defines the node editing pages as administrative page only when a checkbox in an administrative page is selected; those pages are already handled.

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*/view'] = TRUE;
}

If you notice that this implementation doesn't work when the users are viewing, for example,example.com/node/1, but only when they are viewing example.com/node/1/view, then I would implement the hook using the following code. The first implementation I provided should work, as the "View" tab is the default one, and when users are viewing example.com/node/1, Drupal is really showing example.com/node/1/view.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
  $path['node/*/backlinks'] = FALSE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, if there is a module that does that.
• The node module defines the node editing pages as administrative page only when a checkbox in an administrative page is selected; those pages are already handled.

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
  $path['node/*/backlinks'] = FALSE;
}

Before implementing the hook in these ways, I would first check if the following one works also when a user is viewing, for example, example.com/node/1; as the View tab is the default one, when a user is viewing example.com/node/1, Drupal is really showing example.com/node/1/view. If a module change the default tab for nodes, then the users are not anymore seeing the view content while viewing, for example, example.com/node/1; the implementation allows not to shows in an overlay a page that should not be shown as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*/view'] = TRUE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, and defining a page as administrative page when its module didn't define that as administrative doesn't interfere with the permissions applied to that page.
• The node module defines the node editing pages as administrative page only when a checkbox in a administrative page is selected; those pages are already handled.

The faster way is to implement hook_admin_paths_alter() in a module to redefine which of the menu items defined in hook_menu() by other modules are administrative paths. The value returned from the implementations of hook_admin_paths(), which are then altered from the implementations of hook_admin_paths_alter(), are used from the Overlay module to decide which pages are rendered as overlay. As other modules could use the same information to render the pages using a different theme, the module should require the Overlay module as dependency, to be sure the additional pages are effectively rendered as overlay.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*/view'] = TRUE;
}

If you notice that this implementation doesn't work when the users are viewing, for example,example.com/node/1, but only when they are viewing example.com/node/1/view, then I would implement the hook using the following code. The first implementation I provided should work, as the "View" tab is the default one, and when users are viewing example.com/node/1, Drupal is really showing example.com/node/1/view.

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
}

As the first line could catch all the node pages (I didn't verify that), I would verify if there are other pages under that path that should not be rendered; in that case the implementation can be changed as the following one ("node/*/backlinks" is only an example):

function mymodule_admin_paths_alter(&$paths) {
  $path['node/*'] = TRUE;
  $path['node/*/view'] = TRUE;
  $path['node/*/backlinks'] = FALSE;
}

• Normally, modules implement hook_admin_paths() to report which of their menu items are administrative pages; this means that if a page is not an administrative page, an entry for that page is not added to the returned array.
• hook_admin_paths() is implemented for the menu items defined in your own module; to redefine when menu items defined from other modules are administrative pages, you need to implement hook_admin_paths_alter().
• To the pages that are defined as administrative pages is not automatically applied an access control; this means that the module defining those menu items that are reported to be administrative pages still need to use "access callback" and "access arguments" to define which users can access those menu items associated with administrative pages. Pages defined as administrative pages are only rendered differently, and defining a page as administrative page when its module didn't define that as administrative page doesn't interfere with the permissions applied to that page.
• The node module defines the node editing pages as administrative page only when a checkbox in an administrative page is selected; those pages are already handled.