 how views handlers work in views a handler is an object that is part of the view and is part of the query building flow handlers are objects much of the time the base handlers will work but often you ll need to override the handler for something one typical handler override will be viewshandlerfilteroperatorin which allows you to have a filter select from a list of options you ll need to override this to provide your list handlers have two distint code flows the ui flow and the view building flow for the query flow handler construct create the initial handler at this time it is not yet attached to a view it is here that you can set basic defaults if needed but there will be no knowledge of the environment yet handler setdefinition set the data from hookviewsdata relevant to the handler handler init attach the handler to a view and usually provides the options from the display handler prequery run prior to the query stage to do early processing handler query do the bulk of the work this handler needs to do to add itself to the query fields being the only handlers concerned with output also have an extended piece of the flow handler prerender called prior to the actual rendering this allows handlers to query for extra data the entire resultset is available here and this is where items that have multiple values per record can do their extra query for all of the records available there are several examples of this at work in the code handler render this does the actual work of rendering the field most handlers are just extensions of existing classes with a few tweaks that are specific to the field in question for example filter by node type class viewshandlerfilternodetype extends viewshandlerfilterinoperator function getvalueoptions if isset this valueoptions this valuetitle t node type types nodegettypes foreach types as type info options type info name this valueoptions options  viewshandlerfilterinoperator provides a simple mechanism to set the list used and the rest of the handler is perfectly fine for this handlers are stored in their own files for these files to be loaded by views on demand they must first be registered since views core handlers are also loaded this way it s imperative that your module also implement this pattern in order to prevent code crashes when your handler s parent class is not yet available to register handlers you must implement hookviewshandlers   this hook returns an array with two keys the first key is info which contains the modulename which is only necessary if you re registering handlers on behalf of another module such as what views does and path  which is the search path to find the files this path is only necessary if your files will not be stored in the same directory as the module file the other key is handlers which contains a full array of handlers and the information for each handler the key to each handler array is the name of the handler class it can contain  parent the class that this handler extends this is important to make sure that the parent class is included before your handler class without this you may cause people s sites to crash in a difficult to recover state be sure you get this right  file the filename the handler is in by default this will be classnameinc however you can have multiple similar handlers together in one file however because there is only one parent please be sure that the parentage on these handlers matches otherwise you will run into whitescreens as not all parents will be loaded you can see examples of this function in any of the various moduleviewsinc files in the views modules directory the best place to learn more about handlers and how they work is to explore the views api site and use existing handlers as a guide and a model understanding how viewshandler and its child classes work is handy but you can do a lot just following these models you can also explore the views module directory particularly nodeviewsinc please note that while all handler names in views are prefixed with views you should use your own module s name to prefix your handler names in order to ensure namespace safety note that the basic pattern for handler naming goes like this module handler type tablename fieldname sometimes table and fieldname are not appropriate but something that resembles what the table field would be can be used 