 how views plugins work in views a plugin is a bit like a handler but plugins are not directly responsible for building the query instead they are objects that are used to display the view or make other modifications there are 6 types of plugins in views display display plugins are responsible for controlling where a view lives page and block are the most common displays as well as the ubiquitous default display which is likely what will be embedded style style plugins control how a view is displayed for the most part they are object wrappers around theme templates row style row styles handle each individual record from a node argument default argument default plugins allow pluggable ways of providing arguments for blocks views includes plugins to extract node and user ids from the url additional plugins could be used for a wide variety of tasks argument validator validator plugins can ensure arguments are valid and even do transformations on the arguments access access plugins are responsible for controlling access to the view plugins are registered by implementing hookviewsplugins  in your modulenameviewsinc file and returning an array of data the array will look something like this return array display array list of display plugins style array list of style plugins row array list of row style plugins argument default array list of argument default plugins argument validator array list of argument validator plugins access array list of access plugins each plugin will be registered with an identifier for the plugin plus a fairly lengthy list of items that can define how and where the plugin is used here is an example from views core node array title t node help t display the node with standard node view handler viewspluginrownodeview path drupalgetpath module views modules node not necessary for most modules theme viewsviewrownode base array node only works with node as base uses options true type normal of particular interest is the path directive which works a little differently from handler registration each plugin must define its own path rather than relying on a global info for the paths also there is an optional parent directive which is automatically filled in to be the base parent for the plugin type usually this is enough but if your plugin derives from something other than the base it must be filled in for example feed array title t feed help t display the view as a feed such as an rss feed handler viewsplugindisplayfeed parent page so it knows to load the page plugin inc file uses hook menu true use ajax false use pager false accept attachments false admin t feed help topic displayfeed note that unlike handler registration where parentage is referred to by object name with plugins it is referred to by the unique plugin identifier please be sure to prefix your plugin identifiers with your module name to ensure namespace safety after all two different modules could try to implement the grid2 plugin and that would cause one plugin to completely fail todo finish this document  