 working with the panels api panels is a pluggable rendering engine apart from its datastructure almost nothing in panels is hardcoded every level of its rendering process is controlled by plugins of the ctools variety and therefore can be overriden some of these plugins behaviors are obvious from the ui whereas others are much more underthehood most site builders and module authors will find that plugins are the only way they need to interact with panels to do what they want however if you are building whole new uis applications that are to be driven by the panels engine you ll also need the more traditional api that manages panels editing and crud panels node and mini panels are examples of applications in this sense as is og panels  this page is divided into two sections the first dealing with panels rendering system the plugins the drive it and the second with the requirements for creating a panelsdriven application ui the former is a good starting place and should be of interest to anyone wanting to begin working with the panels api the panels rendering system panels rendering system takes a fullyloaded panelsdisplay object and turns it into html it doesn t care how that object was built or where it comes from it s just a rendering engine so long as the calling code provides a wellformed panelsdisplay object the engine will spit out html exactly how that process works is determined entirely by plugins panels utilizes eight different types of plugins within its rendering system four owned by panels and four by ctools let s run through that list layout plugins owned by panels layout plugins provide the html output skeleton for any panel they define a set of regions and optionally accompanying css js very analogous to how themes define block regions while layout plugins with complex logic are possible the flexible layout for example most layouts are nothing more than a region list a tplphp skeleton and some css style plugins owned by panels style plugins control the markup that wraps both individual panes and whole panel regions a basic style plugin need not provide more than some basic css and a theme function or tplphp file style bases owned by ctools panels implements the stylebases plugin type in order to interact with the stylizer system which technically lives in ctools though true ownership is a little blurred regardless panels uses this plugin to interact with stylaizer in order to allow the creation of style plugins in the ui this plugin is probably of interest only to module developers site builders can safely skip it context plugins owned by ctools context plugins are abstracted wrappers around bits of data a node user or taxonomy term are easy examples panels uses context plugins so that it can work with all these different bits of data without caring about the details of the datastructure itself context can be a confusing concept and you can learn more in the ctools help  note that argument and relationship plugins are technically also used by panels but because they re really means for creating more context they don t get separate entries in this list content type plugins owned by ctools can utilize context at the heart of the panels rendering process content type plugins define the rendering logic for every pane offering panels a renderable chunk from your module means defining one of these for those accustomed to the block system they can be thought of as a more verbose block definition contained neatly inside a single plugin content type plugins rely on context to provide them with source data when necessary this makes content plugins nice and portable access plugins owned by ctools can utilize context access plugins are essentially portable access checking logic responsible for answering yes or no given some contextual data panels uses these to define visibility rules on individual panes the other place these are commonly seen is in defining selection rules on page manager variants if your module introduces new permissioning concepts or access logic not a basic hookperm implementation you may want to consider also encapsulating that logic in one or more of these plugins for example organic groups might implement an access plugin to allow deny based on group membership or the date module might implement allow deny logic based on request time cache plugins owned by panels should utilize context panels cache plugins define caching strategies that can be applied to individual panes or to whole displays caching plugins must deal with two basic issues the cache backend to use for reading writing and ttlmanaging strategies ttl strategies can and should integrate heavily with the context as that is where the real differential benefit of panelsbased caching is vs standard core caching display renderers owned by panels utilizes everything else in the simplest terms display renderers take a fullyloaded panelsdisplay object and render it they are very complex powerful plugins one could use them to cause panels to bypass every single other plugin in this list fortunately there is virtually no circumstance under which one would need to implement these plugins in the process of building a single site only contrib developers working on highly complex use cases are likely to ever need them in short each display renderer plugin is a selfcontained panels rendering engine if you want to grok the panels rendering system study these panelsbased applications at its core panels is a rendering engine with no ui though it does provide common elements for reuse in admin uis so if you re working with panels via the web ui it means you re working with a panels application the three that ship with this version of panels are mini panels panel nodes and the integration with ctools page manager panels also implements a taskhandler plugin which is owned by page manager in ctools task handlers aren t strictly a part of panels rendering system itself though strictly speaking they wrap it so we won t cover them here  