 exportable objects tool exportable objects are objects that can live either in the database or in code or in both if they live in both then the object in code is considered to be overridden meaning that the version in code is ignored in favor of the version in the database the main benefit to this is that you can move objects that are intended to be structure or featurerelated into code thus removing them entirely from the database this is a very important part of the deployment path since in an ideal world the database is primarily user generated content whereas site structure and site features should be in code however many many features in drupal rely on objects being in the database and provide uis to create them using this system you can give your objects dual life they can be created in the ui exported into code and put in revision control views and panels both use this system heavily plus any object that properly implements this system can be utilized by the features module to be used as part of a bundle of objects that can be turned into feature modules typically exportable objects have two identifiers one identifier is a simple serial used for database identification it is a primary key in the database and can be used locally it also has a name which is an easy way to uniquely identify it this makes it much less likely that importing and exporting these objects across systems will have collisions they still can of course but with good name selection these problems can be worked around making your objects exportable to make your objects exportable you do have to do a medium amount of work create a chunk of code in your object s schema definition in the install file to introduce the object to ctools export system create a load function for your object that utilizes ctoolsexportloadobject create a save function for your object that utilizes drupalwriterecord or any method you desire create an import and export mechanism from the ui the export section of the schema file exportable objects are created by adding definition to the schema in an export section for example function mymoduleschema schema mymodulemyobj array description t table storing myobj definitions export array key name key name name primary key oid identifier myobj exports will be as myobj default hook defaultmymodulemyobj function hook name api array owner mymodule api defaultmymodulemyobjs base name for api include files minimumversion 1 currentversion 1 if the key is stored in a table that is joined in specify it key in table myjointable if your object s data is split up across multiple tables you can specify additional tables to join this is very useful when working with modules like exportablesmodule that has a special table for translating keys to local database ids the joined table must have its own schema definition if using joins you should implement a delete callback see below to ensure that deletes happen properly exportinc does not do this automatically join array exportables array the following parameters will be used in this way select from mymodulemyobj t0 inner join myjointable t1 on t0id t1id and extras table myjointable leftkey format rightkey id optionally you can define extra clauses to add to the inner join extras and extraclauses you must specify which fields will be loaded these fields must exist in the schema definition of the joined table load array machine and finally you can define other tables to perform inner joins otherjoins array table fields array name array type varchar length 255 description unique id for this object used to identify it programmatically oid array type serial unsigned true not null true description primary id field for the table not used for anything except internal lookups no export true do not export databaseonly keys primary key array oid unique keys array name array name return schema key this is the primary key of the exportable object and should be a string as names are more portable across systems it is possible to use numbers here but be aware that export collisions are very likely defaults to name key name human readable title of the export key defaults to name because the schema is cached do not translate this it must instead be translated when used primary key objects should contain a primary key which is a database identifier primarily used to determine if an object has been written or not this is required for the default crud save callback to work object the class the object should be created as defaults as stdclass can disable control whether or not the exportable objects can be disabled all this does is cause the disabled field on the object to always be set appropriately and a variable is kept to record the state changes made to this state must be handled by the owner of the object defaults to true status exportable objects can be enabled or disabled and this status is stored in a variable this defines what variable that is defaults to default table default hook what hook to invoke to find exportable objects that are currently defined these will all be gathered into a giant array defaults to default table identifier when exporting the object the identifier is the variable that the exported object will be placed in defaults to table bulk export declares whether or not the exportable will be available for bulk exporting list callback bulk export callback to provide a list of exportable objects to be chosen for bulk exporting defaults to module table list if the function exists if it is not a default listing function will be provided that will make a best effort to list the titles see ctoolsexportdefaultlist to hook code callback function used to generate an export for the bulk export process this is only necessary if the export is more complicated than simply listing the fields defaults to module table tohookcode create callback crud callback to use to create a new exportable item in memory if not provided the default function will be used the single argument is a boolean used to determine if defaults should be set on the object this object will not be written to the database by this callback load callback crud callback to use to load a single item if not provided the default load function will be used the callback will accept a single argument which should be an identifier of the export key load all callback crud callback to use to load all items usually for administrative purposes if not provided the default load function will be used the callback will accept a single argument to determine if the load cache should be reset or not save callback crud callback to use to save a single item if not provided the default save function will be used the callback will accept a single argument which should be the complete exportable object to save delete callback crud callback to use to delete a single item if not provided the default delete function will be used the callback will accept a single argument which can be either the object or just the export key to delete the callback must be able to accept either export callback crud callback to use for exporting if not provided the default export function will be used the callback will accept two arguments the first is the item to export the second is the indent to place on the export if any import callback crud callback to use for importing if not provided the default export function will be used this function will accept the code as a single argument and if the code evaluates return an object represented by that code in the case of failure this will return a string with human readable errors in addition each field can contain the following no export set to true to prevent that field from being exported export callback a function to override the export behavior it will receive myobject field value indent as arguments by default fields are exported through ctoolsvarexport  reserved keys on exportable objects exportable objects have several reserved keys that are used by the ctools export api each key can be found at myobj key on an object loaded through ctoolsexportloadobject implementing modules should not use these keys as they will be overwritten by the ctools export api apiversion the api version that this object implements disabled a boolean for whether the object is disabled exportmodule for objects that live in code the module which provides the default object exporttype a bitmask representation of an object current storage you can use this bitmask in combination with the exportincode and exportindatabase constants to test for an object s storage in your code incodeonly a boolean for whether the object lives only in code table the schema api table that this object belongs to type a string representing the storage type of this object can be one of the following  normal is an object that lives only in the database overridden is an object that lives in the database and is overriding the exported configuration of a corresponding object in code default is an object that lives only in code the load callback calling ctoolsexportcrudload table name will invoke your load callback and calling ctoolsexportcrudloadall table reset will invoke your load all callback the default handlers should be sufficient for most uses typically there will be two load functions a single load to load just one object and an all load to load all of the objects for use in administrating the objects or utilizing the objects when you need all of them using ctoolsexportloadobject you can easily do both as well as quite a bit in between this example duplicates the default functionality for loading one myobj load a single myobj function mymodulemyobjload name ctoolsinclude export result ctoolsexportloadobject mymodulemyobjs names array name if isset result name return result name  the save callback calling ctoolsexportcrudsave table object will invoke your save callback the default handlers should be sufficient for most uses for the default save mechanism to work you must define a primary key in the export section of your schema the following example duplicates the default functionality for the myobj save a single myobj function mymodulemyobjsave myobj update isset myobj oid isnumeric myobj oid array oid array return drupalwriterecord myobj myobj update  default hooks for your exports all exportables come with a default hook which can be used to put your exportable into code the easiest way to actually use this hook is to set up your exportable for bulk exporting enable the bulk export module and export an object  